# Guide: Deploying an App

Once you've built, graded, and styled your app locally (see **[Build, Grade & Style Before You Deploy](./test-before-deploy.md)**),
deploying is registering your app's bytes on-chain — a one-time cost, after which anyone renders it for free forever.

## The steps

1. **Compile** your composition to get its bytes and hash.
2. **Register** the bytes to the `ComponentRegistry` (one transaction). The hash is now a live, renderable app.
3. **(Optional) Name it** — register a subname (`myapp.chainrender.eth`) so it's resolvable by name. See
   **[ENS Names & Integration](./ens-integration.md)**.
4. **(Optional) Seed a theme** — if you tuned a custom theme, seed its CSS on-chain and point your app at it.
5. **Verify** — render the deployed hash against multiple RPCs and confirm byte-identical output. See
   **[Contracts → Verifying](../contracts/verifying.md)**.

## What you pay for

- **Registering bytes:** gas, once, proportional to app size (stored via SSTORE2 — cheap and permanent).
- **Rendering:** nothing, ever. It's a `view` call.
- **Naming:** a refundable stake (spam cost, not a fee).
- **Theme changes:** nothing at render time; a one-time seed only if you commit a new default theme.

## Multichain

Because rendering is deterministic and content-addressed, the same app has the same hash and output on any EVM
chain. To deploy across chains, register the same bytes on each; a chain-id-aware viewer resolves the right
deployment. (Portability, not bridging — each chain holds its own immutable copy.)

## Updating later

You don't mutate a deployed app — you publish a **new version** through the versioned-name registry (timelocked,
observable). See **[Update a Deployed App](./update-app.md)**.

## Related
- **[Contracts → Architecture](../contracts/architecture.md)** · **[Contracts → Verifying](../contracts/verifying.md)**