Web3 Hosting for dApps: How to Host Frontends, RPC, Storage and Data

Web3 hosting is everything your dApp needs that does not live on-chain: the frontend people load in a browser, the domain that points to it, the RPC endpoints that read from and write to the blockchain, the indexer behind your dashboards, and the storage for images and metadata. Your smart contracts may be decentralized, but every one of those other layers runs on infrastructure that someone on your team chose, configured and can get wrong.

That gap is where some of the most expensive incidents in crypto started. When Bybit lost about $1.5 billion in February 2025, investigators traced the theft to malicious JavaScript planted in the Safe{Wallet} interface files stored in an AWS S3 bucket, not to a bug in a smart contract. Less than three months later, Curve Finance’s curve.fi domain was hijacked at the registrar level and pointed at a wallet drainer.

This guide covers dApp hosting layer by layer: what to host where, when decentralized hosting is worth the extra work, how to keep RPC and indexing from becoming your bottleneck, how to pay for infrastructure in crypto, and the security and SEO decisions that shape whether users trust your product before they ever connect a wallet.

Key takeaways

• Web3 hosting covers six off-chain layers: frontend, naming, RPC access, indexing, storage and background services.
• Most production dApps use a hybrid model: a CDN-hosted app on a normal domain, plus an IPFS mirror and an ENS name for every release.
• During a launch, RPC rate limits usually break before the website does, so run two RPC providers with failover.
• Some of the largest crypto losses, including the $1.5 billion Bybit theft, started in the hosting layer rather than in a smart contract.
• Fleek hosting and The Graph’s hosted service no longer exist, so any stack or tutorial that still depends on them needs updating.

What Web3 Hosting Means in 2026

Web3 hosting is the infrastructure that serves the off-chain parts of a decentralized application. It covers the frontend, naming, blockchain access through RPC nodes, data indexing, file storage and background services, and it can be centralized, decentralized or a mix of both.

The term gets used loosely. Some companies use it for crypto-friendly VPS plans, others for IPFS pinning, others for node APIs. All of them are part of the picture, but none of them is the whole picture. A dApp is only as available as its weakest hosted layer: a contract that runs perfectly on Ethereum is useless to most people if the website will not load or the RPC endpoint is rejecting every request.

The market also changes fast, and that is a hosting risk on its own. The Graph shut down its hosted service on June 12, 2024 and moved subgraphs to Subgraph Studio and its decentralized network. Fleek, once a popular all-in-one IPFS hosting platform, discontinued its hosting service on January 31, 2026 after pivoting to AI. If your stack, your docs or your tutorials still point to either one, they need updating.

We have run into a small version of this ourselves. A live cryptocurrency price slider on one of our WordPress theme demos broke because it relied on an outdated price API integration, and the fix that stuck was dropping the integration and showing static values instead of patching it again. In a dApp, the dependency is usually far more critical than a slider, which is why it pays to know exactly which third parties each layer relies on.

The Six Layers of dApp Hosting

Good hosting for Web3 developers starts with a map of what you actually run. Most dApps break down into six layers, and each one fails in its own way.

Layer	What it does	Common options	What users see when it fails
Frontend	Serves the app interface (HTML, JavaScript, CSS)	Vercel, Netlify, Cloudflare Pages, GitHub Pages, S3 plus a CDN, IPFS	A blank page, or worse, a tampered app
Naming	Points people to the frontend	DNS domain, ENS name, DNSLink	Site unreachable, or traffic redirected to a phishing copy
RPC access	Reads chain state and broadcasts transactions	Alchemy, Infura, QuickNode, Chainstack, your own node	Balances fail to load, transactions hang
Indexing and APIs	Turns on-chain events into queryable data	The Graph (Subgraph Studio), Goldsky, Ponder, SubQuery, your own database	Empty dashboards, stale history
Storage	Holds images, NFT metadata and documents	Decentralized storage such as IPFS pinning (Pinata, Filebase, Storacha), Arweave and Filecoin, or S3-style object storage	Broken images, missing metadata
Off-chain services	Runs relayers, keeper bots, notification workers and custom APIs	VPS, dedicated servers, containers, serverless functions	Gasless flows, alerts or automated actions stop working

Writing the stack out like this exposes single points of failure fast. A team with one RPC key, one registrar account and one pinning provider has three ways to go offline, and none of them involve the blockchain.

Centralized, Decentralized or Hybrid Hosting?

There are three broad ways to host a dApp, and the right one depends on what you are protecting against.

Centralized hosting

The frontend runs on a conventional platform or CDN and resolves through a normal DNS domain. It is the fastest to ship, the easiest to debug and the best for search visibility. The trade-off is control: a registrar, a cloud account or a hosting provider can take the site down, and anyone who compromises those accounts can change what users load.

Decentralized hosting

The frontend is built as static files, published to IPFS or Arweave, and reached through an ENS name or a content identifier (CID). Because a CID is derived from the file contents, the same CID always returns the same bytes. That makes silent tampering much harder and keeps the app reachable even if your company or a provider disappears. The costs are slower first loads through public gateways, more moving parts in the deploy pipeline, and weak discoverability in search engines.

Hybrid hosting, the model most production teams use

Most serious projects combine the two: a fast CDN-hosted app on a normal domain for everyday users, plus an IPFS build of every release with its CID published in the release notes and an ENS name pointing to it. When Curve lost its .fi domain in May 2025, it moved users to a new domain and publicly pushed for wider ENS support as a way to remove registrar hijacks as an attack vector. A hybrid setup gives you that fallback before you need it.

Which setup fits your project

Project type	Hosting model	What to prioritize
Prototype or hackathon build	Centralized: a static host on its free tier and one managed RPC provider	Ship fast, but keep the build static so you can move it later without a rewrite
NFT collection or marketplace	Hybrid: CDN-hosted app, DNS domain plus ENS name, an indexer for listings	Metadata and images pinned with two providers or stored on Arweave, so tokens never point at dead links
DeFi app that touches user funds	Hybrid: CDN app, IPFS mirror for every release, two or more RPC providers	Frontend integrity: registrar lock, DNSSEC, immutable builds, published hashes and outside monitoring
Wallet or signing interface	Hybrid with the strictest deploy controls you can run	Nothing reaches production without review, plus Subresource Integrity and a strict Content Security Policy

Frontend Hosting: CDN, IPFS or Both

Start with a static build. Next.js with static export, Vite, SvelteKit and Astro can all produce plain files that any host can serve. A static frontend is cheaper, easier to cache and portable: the same build can go to a CDN and to IPFS without changes. Server-side rendering is fine for marketing pages, but keep wallet flows in a static bundle so you can mirror them anywhere.

If you are working out how to host a dApp on IPFS, you need three things:

• A CID you create yourself. Build in your own CI pipeline and generate the CID and a CAR file there, so you are never locked into one provider’s build system.
• At least one pinning service or your own node. IPFS only keeps content available while someone pins it. Pinata, Filebase and Storacha are common choices, and teams with operations capacity run Kubo or IPFS Cluster on their own servers.
• A human-readable name. DNSLink maps a normal domain to a CID through a TXT record, and an ENS contenthash does the same for a .eth name. Gateways such as eth.limo then serve that ENS name over HTTPS for browsers without native IPFS support.

Fleek alternatives in 2026

Teams that relied on Fleek for everything had to move every layer before the January 31, 2026 deadline. If you are comparing Fleek alternatives, replace each part of what it bundled instead of looking for one new platform to depend on:

• Static HTTPS hosting: Cloudflare Pages, GitHub Pages or Netlify for the normal web version of the app.
• IPFS pinning: Pinata, Filebase or Storacha, ideally two of them. Filebase published a migration path written specifically for former Fleek users.
• All-in-one Web3 hosting: platforms such as 4EVERLAND still bundle deployment to IPFS and Arweave. They are convenient, but they bring the single-vendor risk straight back.
• Self-hosted: Kubo or IPFS Cluster on your own server, with DNSLink updates automated in CI.

The migration guide published on the IPFS blog makes the same argument. It recommends keeping HTTP hosting, IPFS pinning and DNS as independent, swappable parts, and creating CAR files in your own CI so you can move the same content to a new provider without rebuilding anything else. That advice holds for any Web3 hosting setup, Fleek user or not.

Practical tip: pin every production release with two independent providers. For a static frontend measured in megabytes, a second pinning provider costs very little next to an outage during a market event.

IPFS vs Arweave vs CDN vs VPS: What Each Option Is For

These four options are not competitors so much as tools for different jobs. Most dApps end up using at least three of them.

Option	Best for	How you pay	How long content stays	SEO on its own
CDN or static host	Main app, marketing site, docs	Free tier, then usage-based	As long as the account is active	Strong
IPFS with pinning	Verifiable frontend mirrors, NFT metadata	Monthly pinning plan, or your own node	As long as at least one node pins it	Weak unless served through your own domain
Arweave	Permanent archives, NFT media, release snapshots	One upfront fee per upload	Designed to be permanent	Weak
VPS or dedicated server	RPC nodes, relayers, bots, custom APIs	Monthly, sometimes payable in crypto	As long as you pay and maintain it	Not applicable

A practical pattern: the app and marketing site on a CDN, every release mirrored to IPFS, NFT media that must never change on Arweave, and anything that needs to run continuously on a VPS or dedicated server.

RPC Nodes and Indexing: The Backend Teams Underestimate

Every balance, price and transaction in your interface goes through an RPC endpoint. If a single RPC node provider has an outage or throttles you mid-launch, your app stops working even though the chain is fine. On launch day this is usually what breaks first. A static site on a CDN can absorb a traffic spike. An RPC plan with a per-second request limit cannot.

• Use at least two RPC providers with automatic failover. viem’s fallback transport and ethers’ FallbackProvider both support this, so a provider outage becomes a slower request instead of a dead app.
• Lock down keys that ship to the browser. Any RPC key in a frontend bundle is public. Restrict it by domain and method in the provider dashboard, and route expensive calls through your own backend.
• Cut request volume before you buy capacity. Batch reads with multicall, cache data that does not change every block, and stop polling for things you can get from events.
• Run your own node when the numbers justify it. High request volume, privacy requirements and latency-sensitive flows are good reasons. For an Ethereum full node, the node requirements on ethereum.org call for at least 2 TB of fast SSD storage, and the operator guidance in EIP-7870 recommends a 4 TB NVMe drive, so budget storage before anything else.

Indexing deserves the same planning. Reading historical data straight from RPC is slow and expensive, which is why most dApps put an indexer between the chain and the interface. Subgraphs still pointing at The Graph’s old hosted service endpoints stopped answering in June 2024, and the current path is Subgraph Studio and The Graph Network. Managed options such as Goldsky and self-hosted frameworks such as Ponder or SubQuery are worth comparing on reorg handling, multi-chain support and how painful it is to re-index after a contract upgrade.

Chain-level upgrades can break an indexer just as easily as a contract upgrade. When Solana switched to its Alpenglow consensus on October 21, 2026, vote transactions disappeared from blocks, the confirmed and finalized commitment levels began describing the same state, and one slot could carry more than one candidate block in streaming data. Teams that missed the change saw transaction counts collapse on their dashboards with no real drop in activity. Our guide to how Solana works after Alpenglow explains what changed in plain terms.

Paying for Web3 Infrastructure in Crypto

Not every part of a Web3 stack fits on a CDN. Relayers, keeper bots, notification workers, private RPC nodes and custom APIs usually run on a VPS or a dedicated server, and many teams prefer to pay for that infrastructure the same way they hold their treasury: in crypto.

Checking providers one by one for a crypto VPS with the right location and specs takes time. A directory of Web3 hosting providers that accept crypto shortens that search by letting you compare VPS and dedicated server offers by country, accepted coins and DDoS protection in one place. Whichever provider you choose, check the details that matter for blockchain workloads:

• Disk type and size. Node sync is heavy on disk input and output. NVMe storage is the baseline, and archive nodes need far more space than full nodes.
• Location. Place RPC nodes and bots close to the users or services they talk to, and spread anything critical across at least two regions.
• DDoS protection and bandwidth. Public endpoints attract abuse. Confirm whether protection is included and whether bandwidth is metered.
• Terms of service and legal fit. Paying in crypto does not change a provider’s acceptable use rules or your obligations where you operate. Read the policy on nodes, bots and refunds before you deploy.

If you settle infrastructure invoices in stablecoins, the network matters too. Fees, wallet support and how easily your finance team can reconcile payments all change with the chain, and our comparison of USDT on TRC20 vs ERC20 walks through those trade-offs.

Editor’s note: Visualmodo has no commercial relationship with hosting-bitcoin.com and received nothing for this mention. We include it because it is a practical way to compare crypto-accepting VPS and dedicated server providers in one place.

Hosting Security: Attacks That Skip Your Smart Contracts

Smart contract audits get most of the attention, but some of the largest losses in the industry started in the hosting layer, because that is where an attacker can change what users sign without touching the contract.

Frontend tampering

In the Bybit case, attackers compromised a Safe{Wallet} developer’s machine, used it to reach the company’s AWS environment, and modified JavaScript files in the S3 bucket that served the Safe{Wallet} interface. The injected code was built to activate only for Bybit’s cold wallet, so the interface showed a normal transaction while the signers’ hardware wallets received a different one. About two minutes after the theft, the attackers replaced the files with clean versions.

DNS and registrar hijacking

Curve Finance has been hit at the domain layer twice, in August 2022 and again on May 12, 2025. In Curve’s own incident report, the team explains that attackers gained access at the registrar level and changed the DNS settings for curve.fi, sending visitors to a malicious site while the contracts stayed untouched. The website was the attack surface.

A hosting security baseline for dApps

• Protect the registrar account with hardware-key two-factor authentication, and enable registrar lock (plus registry lock where your domain extension supports it).
• Turn on DNSSEC and add CAA records so only the certificate authorities you choose can issue certificates for your domain.
• Deploy from CI with short-lived, least-privilege credentials instead of long-lived keys stored on developer laptops.
• Treat production builds as immutable, and publish the bundle hash or IPFS CID for every release so anyone can check that what they loaded matches what you shipped.
• Use Subresource Integrity for third-party scripts and a strict Content Security Policy for everything else.
• Monitor the live site from outside your own infrastructure for unexpected script changes, DNS record changes and newly issued certificates.
• Keep an IPFS mirror and ENS name ready, so users have a verified way in if the main domain is compromised.

When something does go wrong, the first hour decides how far the damage spreads. If your marketing site runs on WordPress, our first-hour response plan for a hacked WordPress site lays out a sequence that applies to any compromised frontend: confirm, preserve evidence, lock every credential, find the way in, then clean.

Traffic Spikes, Performance and Uptime

Web3 traffic rarely grows in a straight line. A token event, an exchange listing or a single thread from a large account can multiply traffic in minutes, and a well-run KOL campaign is designed to do exactly that. Plan capacity for the spike, not the average.

• Serve the frontend from a CDN with long cache lifetimes on hashed assets, so a spike costs you bandwidth instead of compute.
• Load test the RPC and indexer paths, not only the website. Those are the services with hard rate limits.
• Run the status page on separate infrastructure, so users can still check it when the main app is down.
• Track Core Web Vitals on the pages people land on first. A slow first load loses users before the wallet prompt ever appears.

SEO for Web3 Projects: Keep the Public Site Crawlable

Hosting decisions also shape whether people find the project at all. Search engines rely on pages they can fetch and read on normal domains. An app that only exists on IPFS behind an ENS name, or that renders nothing until a wallet connects, gives crawlers very little to work with.

A structure that works for most teams: keep the marketing site, docs and blog on the main DNS domain with server-rendered or static HTML, run the app on a subdomain such as app.yourdomain.com, and treat the IPFS build as a verified mirror rather than the version you want ranked. Explain what the product does in plain text on the page, not only inside the app. AI assistants increasingly answer questions about protocols and developer tools, and they need what crawlers need: clear passages they can extract and quote. Our guide to structuring a website for AI assistants covers how to write and mark up pages so those systems can cite them.

Hosting Mistakes That Quietly Hurt Web3 Projects

A lot of Web3 products do not fail because the idea is bad. They fail because the experience feels rough.

One of the most common mistakes is treating hosting as an afterthought. Teams spend weeks on tokenomics, smart contracts, visual design and wallet integrations, then push the frontend onto whatever platform is easiest and hope it works.

Another is ignoring frontend performance. In Web3, users already deal with enough friction. Wallet popups, transaction waiting, network switching and on-chain confirmations all create natural delays. Your hosting should remove friction, not add more.

Then there is the security side. Hosting does not control your smart contract logic, but it absolutely affects how secure and credible your product feels. Poor SSL handling, weak domain setup, sloppy secret management or unstable frontend delivery can make users hesitate before they even connect a wallet.

The last one is quieter: depending on one vendor for everything. When an all-in-one platform shuts down or changes direction, every layer that relied on it has to move at the same time, usually on someone else’s deadline.

Web3 Hosting Checklist Before Launch

1. Map all six layers and name an owner and a backup provider for each one.
2. List the third-party services each layer depends on, and check their status pages and deprecation notices every quarter.
3. Ship the frontend as a static build, deployed to a CDN and pinned to IPFS with at least two providers.
4. Point an ENS name or DNSLink record at the release CID, and publish that CID in your release notes.
5. Configure two RPC providers with failover, domain-restricted keys and batched reads.
6. Move indexing off any deprecated endpoint and test a full re-index.
7. Lock the registrar with hardware-key two-factor authentication, turn on DNSSEC and add CAA records.
8. Deploy from CI with short-lived, least-privilege credentials.
9. Load test RPC and indexer paths at several times your expected launch traffic.
10. Put the status page on separate infrastructure.
11. Keep the marketing site, docs and blog crawlable on your main domain.

Last reviewed in October 2026 against provider documentation, ethereum.org node requirements, the IPFS project’s migration guidance and public post-incident reports from Curve Finance and the Bybit investigation.

IPFS, ENS, RPC Nodes and SEO: Quick Answers for dApp Teams