# No Hosting: How ChainRender Actually Works

A ChainRender app has **no host**. There is no web server, no S3 bucket, no IPFS pin, no CDN — nothing that anyone
has to keep running for your app to exist and work. This page explains how that's possible and why it's different
from every other approach.

## Where a normal app lives vs. where a ChainRender app lives

A normal web app is files (`index.html`, JS, CSS) sitting on a server. Someone pays for that server, controls it,
and can change or remove the files. Even a "decentralized" dApp usually works this way — the contract is on-chain,
but the *frontend* is hosted.

A ChainRender app is **bytes stored on-chain** (via SSTORE2) and **rendered by an on-chain `view` function**. To
display it, you call `renderHash(hash)` — a free `eth_call` that returns the HTML. There is no file on a server
anywhere in this picture. The app exists as long as the chain does, hosted by no one.

```
normal app:      browser → your server → index.html   (server can change/remove it)
ChainRender app: browser → any RPC → renderHash(hash) → HTML   (on-chain, immutable, hosted by no one)
```

## Why not just use IPFS?

IPFS is a real improvement over a centralized server — it content-addresses *files*, so a CID always refers to the
same bytes. But IPFS solves a different, smaller part of the problem, and it has gaps ChainRender doesn't:

| | IPFS-hosted frontend | ChainRender |
|---|---|---|
| What's addressed | The frontend *files* (a CID) | The *app itself* (a hash), rendered on-chain |
| Availability | Depends on someone *pinning* the files | Guaranteed by the chain — nothing to pin |
| Discovery | Off-chain (you need the CID from somewhere) | On-chain (resolve a name → the app) |
| Live data | The files are static; data still needs a separate call | Data is read on-chain at render time |
| Rendering | Your browser runs the fetched JS (trust the code) | The chain renders it (analyzable, graded, safe by construction) |
| Verifiable trust | The CID matches the files — but the files can do anything | Graded A/B/C, enforced, actions declared |

The short version: **IPFS makes the files immutable; ChainRender makes the *app* immutable, available, discoverable,
data-live, and provably safe — with nothing to host and nothing to pin.** IPFS still needs someone to keep the
content pinned or it disappears; a ChainRender app can't disappear as long as the chain is alive.

## What "no hosting" buys you

- **Permanence.** Your app outlives you, your company, your servers. No renewal, no re-pinning, no bit-rot.
- **Censorship-resistance.** There's no host to pressure, no domain to seize, no files to take down.
- **Zero ops.** No deploy pipeline, no hosting bill, no uptime to maintain. Register once; it renders forever.
- **Verifiability.** Anyone reproduces the exact app from the chain — trust becomes verification.

## The one honest caveat

You still read *through* something — an RPC endpoint. The *app and its output* are on-chain and reproducible
(nobody can change what `renderHash` returns), but *which RPC you query* is your choice, and that RPC sees your
request (a metadata concern, not an integrity one). Use a private or light-client RPC if that matters to you. This
is the only "infrastructure" left, and it's swappable and optional — not a host of your app.

## Related
- **[What's Fully On-Chain](./fully-on-chain.md)** · **[Content Addressing](./content-addressing.md)**
- **[Comparison to Alternatives](../resources/comparison.md)**