Source: https://www.hype-stack.dev/docs/getting-started/going-to-production

# Going to production

Use this checklist before you point real users at a Hype Stack deploy. The fastest path is
[`hype-stack deploy web`](/docs/cli/deploy) on Fly or Railway; the checks below still apply if you host the pieces
yourself. Shipping the mobile app or the browser extension too?
[`deploy mobile` and `deploy extension`](/docs/cli/deploy) have their own store-side prerequisites covered on the deploy
page.

## Production checklist

| Area               | What to verify                                                                                                       |
| ------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Database           | `DATABASE_URL` points at the intended Postgres (not local Docker)                                                    |
| Cache              | `VALKEY_URL` (and password if required) match the deployed Valkey / Redis                                            |
| Storage            | `RUSTFS_*` / bucket credentials match the environment; see [Storage](/docs/backend/storage)                          |
| Frontend env       | `VITE_API_BASE_URL` is the public API origin                                                                         |
| Backend origins    | `FRONTEND_URL` (and admin URL if present) match deployed sites for CORS and email links                              |
| Auth (WorkOS)      | Redirect URIs and cookie settings match production domains                                                           |
| Auth (Better Auth) | `BETTER_AUTH_URL` matches the public API origin; Google callback URIs updated                                        |
| Admin              | `SUPER_ADMIN_EMAIL` includes your operator accounts, `ADMIN_URL` is the deployed admin origin                        |
| Billing            | Live keys for your provider (Stripe, Lemon Squeezy, or Polar), webhook pointed at `/checkout/webhook`, live plan ids |
| Email              | `RESEND_API_KEY` and verified `RESEND_FROM_DOMAIN`; `RESEND_WEBHOOK_SECRET` if the newsletter pack is installed      |
| AI chat            | Provider keys (`OPENAI_API_KEY` at minimum) and a private `AI_STORAGE_BUCKET`                                        |
| Monitoring         | Optional `SENTRY_DSN` on the backend, `VITE_SENTRY_DNS` on the web apps, `EXPO_PUBLIC_SENTRY_DNS` on mobile          |
| Migrations         | Schema applied with `migrate deploy` (or via `hype-stack deploy web`)                                                |
| Domains            | Custom `url` values in `stack.json` match DNS; auth callbacks updated                                                |

## Safety pitfalls

### Wrong `FRONTEND_URL` or API origin

Auth callbacks, CORS, and email links all depend on these lining up. A staging frontend talking to a production API (or
the reverse) fails in confusing ways.

### Better Auth URL drift

`BETTER_AUTH_URL` must be the public API origin Better Auth is served from. If it still says `http://localhost:3000` in
production, sign-in and OAuth callbacks break.

### WorkOS / Google redirect mismatch

Provider consoles must list the production callback URLs. Localhost entries alone are not enough. See the
[WorkOS](/docs/packs-templates/packs/starter-saas-workos) and
[Better Auth](/docs/packs-templates/packs/starter-saas-betterauth) pack pages.

### Billing webhook still on localhost

Live mode needs a public webhook endpoint and the live signing secret (`STRIPE_WEBHOOK_SECRET`,
`LEMONSQUEEZY_WEBHOOK_SECRET`, or `POLAR_WEBHOOK_SECRET`). A secret from the provider's local forwarding CLI only works
for forwarded local events. The same goes for the newsletter pack's `RESEND_WEBHOOK_SECRET`.

### Migrations skipped or pointed at the wrong database

Deploying app code against an old schema fails at runtime. Prefer the release / pre-deploy migration step from
[`deploy`](/docs/cli/deploy). Never run `migrate dev` against a shared production database.

## Final preflight

1. Run typecheck and tests locally against the branch you will ship
2. Confirm env vars on every app and service
3. Deploy with `npx @hype-stack/cli deploy web` (or your own pipeline)
4. Hit `/ping` on the API and sign in once on frontend and admin
5. Trigger a test webhook (or a sandbox checkout) if billing is installed
6. Confirm [Observability](/docs/development/observability) is receiving events if Sentry is configured

## Related

- [Deploy](/docs/cli/deploy)
- [Env variables](/docs/backend/env-variables)
- [Troubleshooting](/docs/development/troubleshooting)