# Deploy your website

> **Related:** [Project access](https://docs.atmyapp.com/account.md) · [Hand the website over to your client](https://docs.atmyapp.com/ai-assistant.md) · [Changelog](https://docs.atmyapp.com/changelog.md) · [Examples](https://docs.atmyapp.com/examples.md) · [Choose your integration](https://docs.atmyapp.com/integrations.md) · [Connect a JavaScript website](https://docs.atmyapp.com/quick-start.md) · [Troubleshooting](https://docs.atmyapp.com/troubleshooting.md)
> **Also:** [HTML version](https://docs.atmyapp.com/deployment) · [Docs index](https://docs.atmyapp.com/llms.txt)

---
AtMyApp provides content; your website's rendering strategy determines how it reaches visitors.

## Static production

Fetch content during the build, generate HTML, and deploy the output directory through your host. Configure production project values in the build environment and keep preview keys out of production configuration. Use `errorPolicy: 'throw'` for required content so a failed read cannot silently become a successful empty build.

A published content change needs a rebuild and successful deployment before static HTML changes. Verify that your hosting workflow performs that step. Also generate dynamic routes and the sitemap from the same published content snapshot where your framework supports it.

For Astro, production defaults to static. Do not set `DEV_MODE=true` on a static production build. Read [Astro modes](/guides/astro-previews/) before configuring a dynamic adapter.

## Server or browser rendering

Fetch content in a request loader or browser code and handle loading, empty, and error states. Make cache behavior deliberate. Keep preview clients scoped to individual requests and prevent shared caching of preview responses. Public website API keys can be included in browser code; CLI tokens cannot.

## Release schema and code together

Review `atmyapp migrate --dry-run --verbose` against the intended project before applying a schema change. Deploy code compatible with existing content or backfill the content first. Preserve the previous working website deployment while the new build runs. Document how to roll back code and whether the schema change is backward compatible.

## Verify production

1. Open a known content page without preview parameters.
2. Confirm the title, canonical URL, favicon, and expected content.
3. Publish a small content edit and follow it through rebuild or cache refresh.
4. Open a preview and confirm unpublished edits appear only there.
5. Test a real form submission intentionally and confirm receipt.
6. Run [optional diagnostics](/guides/diagnostics/) and distinguish build-time evidence from runtime evidence.

Finally, walk through the [client handoff](/ai-assistant/). A passing build is not a substitute for testing the deployed website.