Why decentralised apps still use centralised cloud services

A decentralised application can lose its website without its smart contracts stopping. The distinction matters to anyone who expects the service to remain usable during a cloud outage, a domain suspension or the failure of its operator.

What users call “the app” is usually several systems working together. Some enforce transactions across a distributed network. Others display balances, find records, deliver prices or connect a browser to that network. Decentralising one layer does not automatically decentralise the rest.

Follow a transaction through the application

Consider a hypothetical lending application. A borrower opens its website, connects a wallet, checks an available borrowing amount and submits a transaction. Behind that short journey sit several dependencies.

The website’s files must reach the browser. A domain-name service helps locate them, and a content-delivery network may serve them from nearby locations. The interface requests blockchain information through a node connection, often called an RPC endpoint. An indexer organises historical activity so the site can display it quickly. A price oracle supplies information used by the lending contracts.

The wallet then signs an instruction and sends it towards the network. Only part of the journey is the smart contract executing that instruction.

Ethereum’s technical introduction describes a dapp as a smart contract combined with a frontend. It also explains that frontend files can be hosted through decentralised storage. That is an architectural option, rather than evidence that every service using the label has adopted it.

Why developers buy managed infrastructure

Running every dependency independently requires people, equipment and operational expertise. A managed provider can supply a familiar deployment process, monitoring, security maintenance and capacity during a traffic spike. For a small team, those benefits can make a usable product possible.

The trade-off is concentration. Several apparently independent applications may purchase the same hosting, node access or data services. A common provider’s failure can then interrupt their interfaces together, even while the underlying blockchain continues operating.

Changing cloud brands is not always enough. Two services might share a region, an upstream provider or the same domain infrastructure. Resilience comes from understanding those relationships, rather than counting different names in a supplier list.

A node connection is an access decision

Applications need a way to read network state and submit transactions. They can operate their own nodes or use services run by someone else. Ethereum’s nodes and clients documentation explains the role of nodes and the ability to provide independent RPC endpoints.

A managed endpoint can fail, impose a limit or return stale information. A second genuinely independent connection may help, provided the application can switch correctly and compare responses where necessary. Operating a node reduces one external dependency but introduces responsibility for keeping it healthy and connected.

The same reasoning applies to indexers. A dashboard that cannot load an account history has a different failure from a contract that cannot execute withdrawals. The distinction should be visible in an incident explanation.

What remains possible when the website disappears?

Ask whether someone can reach the contracts through an alternative interface, whether the contract addresses and source code are documented, and whether an exit requires a central service to approve it. An experienced developer might interact directly where an ordinary customer cannot. Technical availability is therefore different from practical access.

Decentralised storage can help distribute frontend files, but retrieval gateways, domain names and update permissions still need examination. Similarly, an upgradeable contract can continue running while an administrator retains substantial power to change its behaviour. These are separate questions about availability and control.

Our Commentary on cloud concentration and decentralised applications considers the wider infrastructure issue. For a financial application, the consequences also connect to where DeFi returns come from and the risks suppliers bear.

The useful test is a specific failure: if this provider vanished tomorrow, what could a customer still read, submit or withdraw, using which documented alternative? An application’s answer reveals more than the word “decentralised” on its homepage.