How to publish a website from Codex

Codex can help you build a website, but the publishing steps depend on which Codex workflow produced it. A site created in ChatGPT Sites can be deployed and shared there. A code project in a folder or Git repository can use a separate Git-based host if you want to manage its build and runtime yourself.

First choose where the site should live

OpenAI’s ChatGPT Sites can create, host and share a website or lightweight app. The feature page says Sites can be public, can use a custom domain and is in public beta; plan, workspace and regional availability can vary. If that already meets your needs, use the built-in publishing flow and check its access settings before sharing. You do not need to move every Codex result to another provider.

A repository-based deployment is a different choice. It is useful when you want the code in your own Git workflow, need a separate hosting account, want to choose a static build or server process, or need to manage a runtime and services outside ChatGPT. OpenAI’s Codex Cloud guide describes connected repositories and isolated coding workspaces; that does not make Codex itself a hosting provider for a repository deployment.

1. Check what Codex actually created

Before publishing, open the project files and identify its framework and dependencies. Check package.json, the lockfile, the README and any generated build instructions. Ask Codex to list the install, build and start commands from the files rather than guessing them.

Then decide which output you have:

• Static site: the build produces HTML, CSS, JavaScript and assets, often in a folder such as dist or out. A static host can serve that output.
• Server application: the site needs a process at request time, such as a Node.js server, API, worker or server-rendered framework. A static output directory does not publish that process.
• External services: login, a database, file uploads, email or an AI API may run outside the website. Publishing the frontend does not migrate those accounts, users or data.

If the app only opens on localhost, follow the localhost-to-live publishing checklist before moving the domain.

2. Put the project in a Git repository

Review the files Codex changed and test the site locally. Add generated folders, .env files, private keys, database dumps and user data to the appropriate ignore rules; never push secrets into a public repository. Commit the project and push it to a Git provider that your hosting account can access.

Projects supports GitHub, GitLab and Bitbucket. Connect the repository, choose the production branch and review the detected framework and build settings. A typical static JavaScript project might use npm ci, npm run build and dist, but the repository’s lockfile and actual build output are authoritative. For a tested React/Vite example, see deploying React from Git.

Automatic deployment on push depends on the Git provider connection and its configured, verified webhook. Confirm that it is active before relying on each push to update production. Projects shows the deployed commit and build logs; if the build fails, fix the reported command or output path before pointing your domain at it.

3. Configure the runtime and services

If the application needs a continuously running API or backend, deploy it as a service rather than selecting a static output folder. Projects services run in containers and count toward the allowance of a paid plan. Check the current Projects plans and limits before selecting this route. A project that needs a full Node.js request-time runtime may also fit a self-managed VPS, depending on the framework and how much server administration you want to handle.

Store production values in the hosting environment and rotate development credentials. Reconfigure OAuth redirect URLs, allowed domains, CORS, database access rules and email callbacks for the final HTTPS address. If the Codex project connects to an external API, keep its private key on the server; a variable bundled into browser JavaScript is visible to visitors.

4. Test the deployed address before launch

Open the HTTPS address from another device. Check the home page, direct navigation to an internal route, refreshes, images, forms, sign-in and every API call. Review the build log and service state. If the site is meant to be public, test its pages in a logged-out browser too.

Only after those checks pass should you attach the production domain. Recheck DNS, the certificate, redirects and provider-specific OAuth settings after the domain changes.

Codex writes code; it does not imply a one-click Codex-to-Hostbrid integration. ChatGPT Sites may be the right destination for a focused site that fits its current availability and controls. For a repository-based deployment, Git carries the code and Projects builds the configured repository; server services and external integrations still need their own setup and tests.

Sources: ChatGPT Sites · OpenAI Academy: ChatGPT Sites · Using Codex Cloud · Hostbrid Projects guide