How to host a website on the Internet Computer (ICP): the 2026 guide

Hosting a website on the Internet Computer sounds more exotic than it is. Your visitors type a URL, the page loads over HTTPS, and nothing about the experience says "blockchain." What changes is everything behind the URL: there is no server you rent, no CDN contract, and no single company that can switch your site off.

This guide explains what is actually happening, what you can and can't host, and the two practical ways to get a site live.

What "hosting on ICP" means

The Internet Computer (ICP) is a public blockchain network that runs general-purpose programs called canisters. A canister bundles WebAssembly code with its own memory, and it is replicated across a subnet: a group of independent machines (13 or more nodes on a standard application subnet) that run the same code and agree on its state.

A website on ICP lives in an asset canister, a canister whose job is to store files (HTML, CSS, JavaScript, images) and answer HTTP requests for them. It is your web server, file storage and certificate authority rolled into one program. Because it runs on a subnet of many nodes rather than one machine, a single hardware failure doesn't take the site down.

How a page request reaches your canister

Browsers don't speak the Internet Computer's protocol, so a translation layer sits in between. Here is the full path of one request to yoursite.com:

1. Browser. A normal HTTPS request. No extension, no wallet.
2. DNS. Your domain points at an ICP HTTP gateway. A TXT record tells the gateway which canister ID serves that hostname.
3. HTTP gateway. Converts the HTTP request into a canister call. HTTP gateways are not part of the protocol itself, and anyone can run one.
4. API boundary node. The network's public entry point. It routes the call to the subnet hosting your canister.
5. Subnet and canister. A replica runs your asset canister's http_request handler and returns the file.

The interesting part is step 3 on the way back. A page view is a query call, answered by a single replica without going through consensus, which keeps it fast. To stop a faulty or malicious node from serving altered content, the asset canister certifies its files in advance: the subnet signs a Merkle tree of the content, and the gateway checks the response against that signature before it hands anything to the browser. If the check fails, the visitor gets an error instead of a tampered page.

What you can host (and what you can't)

ICP hosts anything that ends up as files in a folder, and it can also run real backends, just not the kind you're used to.

That last row is where ICP differs from static hosts like GitHub Pages. A backend canister can hold state (up to hundreds of GiB of stable memory), serve an API and talk to other canisters, so a full app can live on the network with no external server at all. Webstead deploys Motoko backends alongside their frontend for exactly this reason, including apps exported from the Caffeine AI builder.

Option 1: deploy it yourself with icp-cli

DFINITY's command-line tool, icp-cli, is the current way to deploy canisters by hand. The broad steps:

1. Install icp-cli (it is distributed through npm as @icp-sdk/icp-cli) and create an identity. The identity's principal is who controls the canister.
2. Get cycles. Buy ICP on an exchange, send it to your identity's ledger account (icp identity account-id prints it), then convert it with icp cycles mint --icp <amount> -n ic. Cycles are held against your principal by the cycles ledger.
3. Describe the site in icp.yaml. The @dfinity/static-site recipe takes your build commands and output folder:

canisters:
  - name: frontend
    recipe:
      type: "@dfinity/static-site@v0.4.0"
      configuration:
        build:
          - npm ci
          - npm run build
        dir: dist

4. Deploy to mainnet with icp deploy -e ic frontend. The first run creates the canister (paying the creation fee from your cycles), installs the asset canister code and uploads your files.
5. Add SPA routing if you need it. For a single-page app, put a _redirects file containing /* /index.html 200 at the root of the output folder.
6. Keep it funded. Watch the canister's balance and top it up with icp canister top-up <canister-id> --amount <cycles> -n ic before it runs low.

The site is then live at https://<canister-id>.icp0.io (newer tooling prints the equivalent icp.net address). A custom domain is a separate step, covered below.

This route gives you full control and costs only the cycles you burn. The price is that you are now the operator: you hold the keys, buy the ICP, mint the cycles, watch the balance and set up DNS. Lose the identity's key and you lose control of the canister.

Option 2: use a managed ICP host

A managed host does the operator work and leaves you with the developer experience of Netlify or Vercel. With Webstead, for example:

• Connect a GitHub repo and the framework is detected; every push to your branch redeploys. Or upload a folder or zip with no Git at all.
• The build runs in a sandbox, and the result is deployed to a fresh asset canister on ICP mainnet.
• Cycles are funded and monitored for you. The dashboard shows runway in days rather than a 12-digit balance, and warns before anything freezes.
• You get a free yoursite.webstead.app subdomain, and a wizard generates the DNS records for your own domain.

The trade-off is custody: during the beta, Webstead controls the canisters and funds their cycles on your behalf. Your site is still an ordinary asset canister on the public network, so moving to self-custody later doesn't mean rebuilding anything.

Connecting a custom domain

The ICP gateways issue TLS certificates for custom domains automatically, but they need proof that you own the domain and that the canister agrees. That takes three DNS records and one file:

1. A CNAME from your hostname to the ICP gateway.
2. A TXT record (_canister-id.yourdomain) containing the canister ID.
3. An ACME challenge CNAME so the gateway can obtain a certificate.
4. A /.well-known/ic-domains file in the canister listing the hostname, so a domain can't be pointed at a canister that never agreed to it.

Then you register the domain with the gateway, and within a few minutes it serves your site over HTTPS. Subdomains (www.example.com) are the easiest; a bare apex domain needs a DNS provider that supports ALIAS, ANAME or CNAME flattening. If you use Cloudflare, keep the records DNS-only (grey cloud) so the gateway can see them. Our custom domains guide walks through each record.

Is it fast, and is it good for SEO?

Search engines see an ICP site like any other. Crawlers fetch the same HTML over the same HTTPS, so titles, meta descriptions, canonical tags, sitemaps and structured data all work as usual. The usual static-site advice applies: a pre-rendered site (Astro, Hugo, a static Next.js export) is easier to index than a client-only SPA that builds its content in JavaScript.

Speed depends on the gateway nearest your visitor and on caching. Query calls skip consensus, so they return quickly, and the gateways cache responses. Treat your own site as the benchmark: deploy it and measure it rather than relying on anyone's headline numbers, ours included.

When ICP is the right choice

ICP hosting earns its keep when who controls the site matters: a project that shouldn't depend on one cloud account, a community or DAO site, a web3 app's frontend that should be as tamper-resistant as its contracts, or anyone who wants their site to keep running regardless of a single provider's decisions. It is also a natural home for apps whose backend can live in a canister too.

If you need server-side rendering, a SQL database or a PHP CMS, a conventional host is still the simpler answer. For everything that builds to a folder of files, the Internet Computer is a real option today, and the cost is lower than most people expect. Our explainer on canisters, cycles and what ICP hosting costs does the arithmetic.