How to host an app built with Codex

Match the platform to the workload

For a framework-led website, evaluate Vercel. For a service-based backend, compare Render and Railway. Choose Fly.io if machine placement and regional control are actual requirements.

For AI-built business applications, AppHaven takes over the infrastructure around deployment, private access, databases and previews. The example below uses that model. You still review application permissions and data changes, whichever host you choose.

Start with the deployment contract

Your repository needs a Dockerfile and an apphaven.yaml describing the app and its database. Ask Codex to inspect the project before writing them: the build command, start command and migration tool must match your application.

The deployment guide gives a Node.js example and checks for persistent data, access and startup failures. Complete that setup once; keep the instructions below for subsequent changes.

Tell Codex how this repository ships

## Hosting on AppHaven

Read https://docs.apphaven.eu/agent-integration/ for CLI setup.
Read https://docs.apphaven.eu/ for current platform configuration.

- Work on a feature branch. Do not push directly to main.
- Build the app and run the relevant tests before proposing a release.
- Run `apphaven validate` after changing apphaven.yaml when installed.
- Report missing tools and checks you could not complete.
- Use synthetic records and sandbox integrations in previews.
- Never copy production secrets into code, logs, prompts or previews.
- Explain database migrations and compatibility with the prior release.
- Ask for a human review of the preview before a production release.

For diagnosis, the AppHaven CLI provides read-only access:
- `apphaven status <app>`: deployment state and URL
- `apphaven build-log <app>`: build output
- `apphaven crash-log <app>`: failed deployment output
- `apphaven logs <app> --service <service>`: application logs

A read-only CLI does not restrict Git. Production branch protection
and deployment permissions must be configured separately.

Connect the working branch to a preview

1. 1

   Configure the app in AppHaven

   Connect the repository and choose the production branch. Add required Variables and Secrets in Settings. Keep previews private.

2. 2

   Deploy the feature branch

   Select the branch in Deploy and wait for Running. If the console has not picked up the latest commit, use Check for updates in Source.

3. 3

   Seed a useful test case

   For an invoice change, include an unpaid invoice, a paid invoice, and one belonging to a different test user. An empty database will not reveal a query that returns another user’s records.

4. 4

   Review the behaviour and the diff

   Try the feature and its failure cases, then inspect the implementation. Pay particular attention to data changes and permissions. A working screen is evidence about that scenario, not proof that the entire change is correct.

Give feedback that Codex can reproduce

“The preview is broken” sends the agent searching. Include the action, the test record and the expected result. For example: “In the preview, marking TEST-001 as paid changes the total to zero. It should keep the original amount and change only the payment status.”

Let Codex read the relevant logs, propose a fix, and add a regression check. Keep the fix on the feature branch and repeat the same action after redeployment. You now have a specific reason to accept the change.

Enforce approval before production

Require reviewed pull requests on the production branch, and block direct pushes by the agent’s Git credentials. Then decide whether an approved merge should auto-deploy or wait for a console deployment.

If auto-deploy is enabled, anything that can update the production branch may trigger a release. AppHaven’s read-only diagnostic CLI does not remove that separate capability. Check the actual Git permissions before relying on a human approval step.

Stop finished previews

Once the release is checked, stop previews you no longer need. They use resources while running; being disposable does not make them free. Stopping retains deployment data, while deleting a deployment removes it. Keep anything you need before deletion.