The App That Lives Nowhere in Particular
You type in the address and get a 503. The company's servers are down, or they've gone bust, or a regulator pulled the plug. You refresh twice, out of some vestigial optimism, and nothing changes. The app is just gone, because it lived on someone else's machine and that someone is no longer cooperating.
Decentralized apps, usually called dApps, are built around a different premise entirely: no single machine hosts them. Pull the plug on one computer and the app keeps running. Understanding why requires getting into the actual plumbing, not just the sales pitch.
What's Actually Hosting the Thing
A conventional app has a clear address. Instagram runs on Meta's servers. Take those servers offline and Instagram goes dark.
A dApp splits that single host across a network of thousands of independent computers, each one running the same software and holding copies of the same data. The backbone for most dApps is a blockchain, which is worth thinking of less like a database and more like a ledger printed simultaneously on thousands of printers at once. Every participating computer, called a node, holds a full or partial copy. When you interact with a dApp, your request doesn't go to a headquarters. It gets broadcast to whichever nodes are nearby, verified by consensus rules baked into the protocol, and recorded across the whole network.
Ethereum, the most widely used platform for dApps, has had over 6,000 active nodes at various points in its history. Shut down a hundred of them and the network barely notices.
The Part Most Guides Skip
The logic layer of a dApp, the code that actually does things, usually lives in something called a smart contract. A program stored directly on the blockchain. Not on a server that runs blockchain software. On the chain itself.
Here's what that means concretely. Say a simple dApp lets two strangers bet on a coin flip. The rules of the bet, who wins, how funds are released, are written into a smart contract and deployed to Ethereum. Once deployed, that code sits at a specific address on the chain and will execute exactly as written, forever, regardless of whether the developer is still alive, solvent, or even interested. Nobody can quietly edit it after the fact.
That permanence is both the point and, occasionally, the horror. A smart contract called The DAO once had a bug that let an attacker drain roughly 60 million dollars worth of Ether through a flaw in its logic. The code did exactly what it said. It just said the wrong thing. Immutability cuts both ways, and anyone telling you otherwise is selling something.
So Where Do the Files Live
Here's the wrinkle most explainers gloss over. Smart contracts handle logic and state, but a full app also needs a front-end: HTML, images, JavaScript, all the visual stuff you actually touch. That can't live on the blockchain itself. Prohibitively expensive. Painfully slow.
The solution most dApps use is a separate distributed file system, with IPFS (the InterPlanetary File System) being the most common. IPFS works differently from a web server. Instead of asking "give me the file at this address," you ask "give me the file with this specific fingerprint." The fingerprint is a cryptographic hash, a unique string generated from the file's contents. Any node that has a copy can serve it to you, and you can verify you got the right file because the hash will match.
Picture it like this: instead of ordering a specific copy of a book from one particular warehouse, you describe the exact text, word for word, and any library in the world holding a matching copy can hand it to you.
Consider a worked example. A developer named Priya builds a decentralized exchange. She writes the smart contracts, deploys them to Ethereum, then uploads her front-end files to IPFS. She registers an IPFS hash with a decentralized naming service called ENS, so users can type a human-readable address instead of a string of letters and numbers. Her friend Marcus in another country can load the app even if Priya's laptop is off, even if the company she worked for shuts down, because the files exist on every IPFS node that has cached them and the contracts run on Ethereum's network.
What People Get Wrong About "Decentralized"
This is where honest caveats earn their keep.
Most users don't access dApps by running their own node. They use a browser extension like MetaMask, which talks to Ethereum through a third-party provider, often Infura or Alchemy. Those providers run centralized infrastructure. If Infura goes down, a huge chunk of dApp users suddenly can't connect, even though the underlying blockchain is fine. This has happened.
Similarly, most front-ends are still pinned to IPFS through a centralized pinning service, or simply hosted on a regular web server for convenience. The smart contract might be immortal, but the pretty interface in front of it could vanish tomorrow.
So ask yourself: if every user request routes through two AWS data centers, is "dApp" doing any real work in that sentence?
The honest picture is this. The core logic, in a well-built dApp, is genuinely decentralized and censorship-resistant. The user-facing layers are often less so. Calling something a dApp because it touches a blockchain while routing all traffic through centralized infrastructure is technically accurate and also a bit rich.
Decentralization is a dial, not a switch.
What Keeps the Network Running at All
None of this works without people willing to run nodes. The incentive varies by network. On proof-of-work chains, miners earn newly created coins. On proof-of-stake chains like modern Ethereum, validators lock up their own funds as collateral and earn fees for honest behavior. Behave dishonestly and the protocol slashes your stake.
It's a system that replaces the need to trust a company with the need to trust that enough strangers are self-interested enough to follow the rules. Which, frankly, is a surprisingly durable foundation once the network is large enough.
The threshold matters. A small dApp network with thirty nodes is fragile. A network with thousands of geographically distributed validators running on independent hardware is genuinely hard to kill. Size is the moat.
Running on Stubbornness and Math
No CEO can take a dApp offline. No unpaid server bill brings it down.
The app persists because its rules are encoded in math that thousands of machines agree to enforce, and the economic incentives are designed to keep those machines running. That's not magic. It's a specific engineering trade-off: you give up the ability to patch things quietly or respond nimbly to mistakes, in exchange for something that can't be switched off from a single room.
The interesting question isn't whether decentralization is good or bad in the abstract. It's whether the thing you're building is worth making permanent. Because once you deploy it, the code doesn't care what you meant.