Deploy

How to deploy an OpenAI Codex-generated website

Built your site with OpenAI Codex in the cloud, the CLI or your editor? Get the code onto a host, fix what differs in production, and go live on your domain.

The short version

OpenAI Codex writes the code, but it doesn't host your website. Whether you used Codex in ChatGPT (Codex cloud), the Codex CLI or the Codex extension in your editor, you end up with an ordinary project: a React or Next.js app, a Python or Node server, sometimes one HTML page. To put it in production, get the code onto GitHub or into a ZIP, fix the few things that behave differently on a server, and deploy it to a host.

Option	Good for	What to know
ProHostiva	Front ends and servers alike, with HTTPS and your domain in one place	A paid plan. We check your project for free first, and can publish it and connect your domain for you.
Front-end platforms (Vercel, Netlify, Cloudflare Pages…)	Static sites, React or Vue apps, Next.js	Free tiers (read their terms for commercial use). Long-running servers, Python and PHP are limited or not offered.
App platforms or your own server (Render, Railway, Fly.io, a VPS…)	Servers, background jobs, full control	More to set up yourself. On your own server, updates, security, backups and HTTPS are yours to look after.

Not sure your project is ready?

Run the free production readiness check on your project whichever host you pick. It runs the real production build and tells you, in plain language, what to fix first. No account needed.

1. Find where your code is

You used	Where the code is	What to do
Codex cloud (Codex in ChatGPT)	In your GitHub repository. Codex can work on it in the cloud and create pull requests with its changes.	Review and merge the changes you want to keep. The host deploys a branch, usually `main`, so work that isn't merged isn't included.
Codex CLI or the editor extension	In a folder on your computer	Push it to GitHub (you can ask Codex to commit and push), or zip the folder. See Deploying from a ZIP.

Codex's environment isn't your hosting

Codex environments can use secrets injected at runtime, which keeps the values out of your prompts and your code. Treat them as credentials the agent, and the code it runs, can read while it works. They also don't follow your code to a host: add the production values again there as environment variables.

2. Have Codex make it production-ready

Code that runs in Codex's sandbox or on your computer often assumes a fixed port, a local database and a .env file. Give Codex a task like this one (in Codex cloud, review the changes before you merge them):

Prepare this project for production hosting. The host builds from the
repository root, runs one container, sets the PORT environment variable
and provides secrets as environment variables. Please:
- make the app listen on PORT
- move every secret and API key into environment variables, and list
  their names (without values) in .env.example
- make sure .env is in .gitignore
- read the database URL from an environment variable instead of
  pointing at localhost
- make sure there is a production build and a start command
- make the home page / return a normal page without a login
Don't deploy anything. Change the code and list what you changed.

Keep it that way with AGENTS.md

Codex automatically reads AGENTS.md files in your repository and uses them as instructions when working on your project. Add a few lines to the one at the root so later changes don't undo the work:

## Deployment
- Production builds from the repository root and runs as one container.
- The app must listen on the PORT environment variable.
- Secrets and URLs come from environment variables; never commit .env.
- Add every new variable name to .env.example.
- The home page / must answer without a login.

On ProHostiva, AGENTS.md is never served, even on a plain HTML site where every other file in the folder is published. On other hosts, check before you put anything private in it.

Project layouts to watch for

Separate front-end and back-end folders (such as frontend/ and backend/). ProHostiva builds the top level of a repository or ZIP, so put each part in its own repository and deploy them as two websites, or ask Codex to make the backend serve the built front end so it's one app.
A Docker Compose file with a database next to the app (docker-compose.yml). Multi-container setups aren't supported: deploy the app on its own and use a hosted database such as Supabase or Neon.
A Dockerfile at the top level is always used when it's there. If it was written for development, ask Codex to make it production-ready or remove it, and we'll build the project ourselves.

3. Deploy it with ProHostiva

Check it (free)
Paste your repository's address into Check my project, or upload the ZIP. Anything the report flags can usually be handed straight to Codex as a task.
Start a new website
In your dashboard, click Host a website, then choose GitHub repository and connect GitHub, or upload the ZIP. Pick the branch your merged work is on. See Deploying from GitHub.
Check what we detected
We show the framework, the runtime version and the build and start commands. Change a command only if you know it's different.
Add environment variables
Everything in your .env.example goes under Developer settings → Environment variables, with production values. Tick Secret for anything private.
Publish
Name the website, choose its address and click Publish website. We build it in an isolated container, check that the home page answers, and put it online at yourname.prohostiva.com.
Connect your domain
Under Domains, add your domain, create the two DNS records we show and click Verify DNS. HTTPS is set up for you. See Connecting your own domain.

Updating the site later

Keep working with Codex as before. When the changes are on your deployed branch (merged from a Codex cloud pull request, or pushed from your computer), click Publish latest version on the website's page. Nothing goes live until you click, and if a new version fails to build or start, the current one stays online.

Rather we did it?

Not technical, or short on time? Create your account and email support@prohostiva.com with your GitHub repository (or the ZIP) and your domain. We'll publish the website and connect the domain for you. Setup help is free on every plan.

Before you send people to it

Rotate any key that was ever committed, including in a pull request you later closed: it stays in the Git history. Create a new key at the service and set it as an environment variable.
Allow your domain where your code or its services expect known addresses: Django's ALLOWED_HOSTS, an API's CORS origins, and sign-in redirect URLs at Google, GitHub, Supabase or Auth0.
Switch services to production: Stripe live keys and a webhook pointing at your domain, a production database rather than a test one, real email settings.
Run your database migrations. They're never run automatically on deploy.

Common problems

The live site doesn't have Codex's latest changes: Codex's changes aren't merged into your deployed branch yet, or the website deploys a different branch. Merge them, then click Publish latest version.
It worked in Codex but the build fails: often a missing lockfile or a dependency that was only installed in Codex's environment by its setup script. Make sure it's listed in package.json or requirements.txt, then deploy again.
Health check failed: the app listens on a fixed port instead of PORT, or the home page redirects to a login. See Troubleshooting.
"We couldn't find a website or app here": the project is in a subfolder. See the layouts above.
Database connection errors: the database URL still points at localhost. Use your hosted database's URL in an environment variable.
A blank page (React, Vue, Svelte): a missing VITE_ variable. Add it and deploy again.