Every time a major provider has a bad day (AWS, Cloudflare, pick your favorite), the internet lights up. Hot takes, memes, and a wave of “we would never.” Most conveniently forget their own outages buried in old postmortems and support messages. People all shout for decentralization. Everybody ignores a universal truth: everything is centralized somewhere. 

Some rent that centralization from a cloud provider. Others build it in a data center. 

Owning servers doesn’t erase dependency. It just changes its shape. You trade a vendor’s shared control plane for a building’s power, cross-connects, and the handful of people who keep it online. The cloud makes the opposite trade: enormous elasticity and reach in exchange for larger shared points of failure.

Both are valid choices. The mistake is pretending one of them grants immunity.

What Failed and What We Learned

Let’s get it out of the way: during the recent us-east-1 outage, we felt it at Pinata. Parts of our stack run on AWS, and when that region stumbled, some parts of our service did too. What mattered was what happened next.

Most customer-facing systems rerouted within seconds to minutes. Alarms fired, runbooks were followed, and regional fault domains worked as designed. For most users, the disruption went unnoticed.

A few components took longer to recover. Our monitoring systems quickly saw this and clearly told us where to focus next. Within an hour, we deployed temporary failovers and saw the remaining systems start healing. Within a day, those patches were hardened into permanent safeguards.

Our quick recovery wasn’t luck. It came from years of experience of building failsafes into every layer of Pinata. Outages are painful, but they’re also diagnostic. They show you exactly where to invest. And every time you choose to invest, you build the muscle memory that turns the next outage from panic into process.

Why Pinata Builds on the Cloud

There are two main alternatives to building on a cloud provider. You can run your own data center, or you can rent hardware from a “bare metal” provider like OVH or Hetzner. Both have trade-offs.

Running your own data center offers complete physical control, but it also means managing everything: power, cooling, networking, hardware replacements, and 24/7 staff. It’s capital-intensive, slow to expand, and bound by geography. For teams with steady, predictable workloads, it can make sense. For everyone else, it limits flexibility.

Bare metal rentals are different in form but similar in dependency. You get dedicated physical servers, but they still live in someone else’s data center, connected through someone else’s network, and provisioned through someone else’s API. Modern bare metal providers can spin up new machines in minutes, but that process still depends on their control plane, their backbone, and their uptime. In practice, it’s a narrower version of the cloud with fewer tools, and more manual effort to build redundancy and automation.

At Pinata, we build on the cloud because we want to spend our time building Pinata, not reinventing physical infrastructure. Modern cloud platforms are the product of decades of engineering investment by some of the best infrastructure teams in the world. They’ve solved problems of global scaling, observability, redundancy, and automation that would take us years (and a fortune) to reproduce.

Every one of those systems represents a team dedicated to solving a single hard problem. Pinata has to solve many of those problems at once to meet our customers’ needs. Using cloud providers lets us leverage those mature solutions instead of rebuilding them from scratch, so our engineers can focus on the thing we're good at: building a world class off-chain storage platform.

It’s not about avoiding dependency, it’s about choosing dependencies designed for resilience, flexibility, and speed.

So that begs the question: Is decentralization even real?

From Centralized Platforms to Decentralized Protocols

Decentralization isn’t the opposite of centralization. It’s what happens when many centralized systems agree to cooperate through shared protocols.

Look at Ethereum or Bitcoin. They’re made up of thousands of individually centralized nodes / servers owned by miners, stakers, and businesses, each with its own hardware and network setup. These systems don’t remove centers; they coordinate across them. Consensus turns a collection of self-contained systems into a resilient network that keeps running even when some parts fail.

That same idea applies to how we think about data and content delivery.

Where IPFS Fits

IPFS applies decentralization to data itself. It uses content addressing. Put simply, you retrieve information by what it is (its CID), not where it lives. That simple shift makes location optional and recovery automatic.

If you host the same content in multiple places, the CID never changes. If one provider or gateway slows down or goes offline, the data is still accessible from others. You can pin it with Pinata, another IPFS provider, or your own node. The data layer becomes resilient by design, not by configuration. Pinata's platform is designed for speed and rapid scalability. Other hosts of IPFS may optimize for cost or greater control of their physical hardware. Neither of these options are wrong. The beauty is that IPFS lets all of these parties serve content together via a standard decentralized protocol.

The Useful Paradox

Ethereum, Bitcoin, and IPFS all depend on centralized parts, but none depend on any particular one. That design means a node can fail, a gateway can reboot, a provider can vanish. When these things happen, the protocol keeps going. Decentralization here isn’t the absence of control; it’s the distribution of recovery paths. It’s what turns the messy reality of dependence into a system that bends instead of breaks. Centralization gives you speed. Decentralization gives you staying power. Together, they form a system that can scale quickly under normal conditions and degrade gracefully when things go sideways.

We can’t eliminate dependencies, but we can choose them carefully. We can’t promise a world without failure, but we can design systems that recover fast and keep serving when it happens. That’s what centralization and resilience look like working together.