How to Deploy a Website with OpenAI Codex (No GitHub)

Build the site, add Birta to the Codex CLI, authorize the remote MCP connection, and ask Codex to publish the finished files. You get a stable live URL without pushing the repo to GitHub or uploading a ZIP to another dashboard.

1. Step 1BuildCreate index.html
2. Step 2ConnectLog in to the Birta MCP
3. Step 3DeployPublish and test the URL

What Codex builds — and what hosting still has to do

OpenAI Codex is an AI coding agent: it inspects a codebase, edits files, runs commands, tests a build and works with a GitHub repository, in ChatGPT, the desktop app, an IDE extension and the terminal. Those surfaces help with development; they do not make every generated site compatible with the same hosting workflow.

A landing page, portfolio, documentation site or client-side prototype is usually a good static case. A web app that owns authentication, a database, server API routes, background jobs or private API keys needs application hosting, and the static site versus application test settles it.

Ask Codex to classify the workspace before changing it:

Inspect this project without changing it. Decide whether it can run entirely as a static website after a production build. Check the framework, package scripts, server routes, authentication, database code, background jobs, private environment variables, and any local video or PDF assets. End with either "Ready for the Birta static publish workflow" or a specific list of blockers.

Step 1: Build the Codex website

Birta hosts production output, not a development server. Run the production build and note the folder it writes into, dist, build, out, whatever the framework uses. That folder needs index.html at its root, with every referenced CSS and JavaScript file beside it. Relative asset paths must still work from a hosted URL. The folder's name means nothing to Birta: what you publish is addressed from the site root.

You do not need to guess the build command. Ask Codex to inspect the existing framework and scripts, preserve the current architecture, and run the real production build:

Prepare this codebase for a static Birta deployment. Inspect the package scripts and framework configuration before editing. Run the correct production build, tell me which folder it writes into, and make sure that folder has index.html at its root. Check internal links and asset paths from a hosted URL. Do not publish yet. Report the command you ran, the directory contents, and every blocker.

A working preview on localhost is not enough. The production output must exist and must not depend on a local process after the build finishes.

Step 2: Connect Birta to the Codex CLI

Add Birta as a Streamable HTTP MCP server. This gives the AI agent a narrow set of project, publish, version, and rollback tools:

codex mcp add birta --url https://birta.dev/mcp

Then start the browser authentication flow:

codex mcp login birta

Sign in with the one-time code sent to your email and allow access. Codex stores its OAuth authentication separately; there is no API key to paste into the repository. Check the integration with codex mcp list, or open Codex and run /mcp. The birta server should appear.

If the command in your installed version does not accept the URL, configure the same server in ~/.codex/config.toml:

[mcp_servers.birta]
url = "https://birta.dev/mcp"

The official OpenAI Codex MCP documentation covers remote servers, OAuth, config.toml, and the shared configuration used by the CLI, desktop app, and IDE extension. Birta's Codex connection guide remains the short command reference, and if the acronym keeps appearing without ever being defined, here is a plain explanation of MCP. Codex can also find this connector on its own, by reading the llms.txt file the agent reads first.

Step 3: Deploy the Codex website to a live URL

Create a Birta project in the dashboard if you do not already have one. Return to the same Codex workspace and use one explicit prompt. The agent should verify the output again, list available projects, and stop if the destination is ambiguous.

Use the connected Birta tools to list my projects. Ask me to choose if more than one project could be the destination. Verify that the build folder has index.html at its root. Publish all built files, images and fonts included, to the selected project with the description "Initial Codex website publish", addressing every path from the site root: index.html at the root and nested files under the same relative paths as in the build folder, without the folder name in front. Return the live URL, version number, preview URL, and every warning exactly as Birta reports them.

Birta validates the package before changing the public site. A missing entry point or invalid payload is rejected while the current version stays live. A successful deploy returns the URL, preview, and recorded version.

Test the live URL, not only the local preview

AI-generated code can build successfully and still fail in a real browser. Open the deployed site in a private window, so your local session cannot hide a problem.

1. Hard-refresh the home page on desktop and mobile.
2. Open every route and click navigation, buttons, and forms.
3. Check CSS, JavaScript, images, and fonts for 404 responses.
4. Inspect the browser console and network panel for errors.
5. Search the built files for secrets and private API keys.
6. Confirm that the live URL is the intended Birta project.

A missing image or font is usually a path or filename-case problem rather than a transfer problem. A missing video or PDF is expected: those are not served and need a public source.

Add a custom domain

The first deploy is live at the standard project address, and that address keeps working. For a name of your own, open the project dashboard and add a root domain such as example.com or a subdomain such as www.example.com, add the DNS record Birta shows at your provider, then click Verify.

A root domain uses the displayed A record, a subdomain the displayed CNAME. If your provider proxies records, Cloudflare among them, switch to DNS only until verification passes. HTTPS comes up on its own, and nothing changes in the Codex project.

A domain you own needs a paid plan; the free tier publishes at the standard address. For the panel steps see the custom-domain guide, and for the part that goes wrong, apex versus www and the proxy that breaks verification, see what each DNS record does.

Birta, Sites in Codex, or a full-stack platform?

Deployment cases look similar in search results and need different infrastructure. Use this workflow when Codex already holds a finished static directory and you want a direct, versioned path to a shareable site, with no repository connection, build-settings dashboard or ZIP handoff.

If your account already provides Sites in Codex or a Vercel or Netlify plugin, that may be the shortest route to a working preview. Use application hosting when the project is a Node.js service or needs auth, a database, server-side APIs, persistent data or secret environment variables.

Iterate in Codex, then update or roll back

Keep working in the same codebase or worktree. After each visible change, review the diff, rebuild the site, and deploy the built files to the same project with a useful description. That turns each iteration into an understandable version instead of an anonymous overwrite.

Review the current changes, rebuild the static site, and verify that the build folder has index.html at its root. Check the built output for unexpected files and private values. Publish the built files, addressed from the site root, to the same Birta project with the description "Update: [summarize the visible change]". Return the live URL, new version number, preview URL, and warnings. Then list the latest versions and identify which one is live.

If the new version is wrong, ask Codex to list the available versions first. Choose a known-good version and roll back. The later version stays in history, and the local repo is not changed.

List the versions of my Birta project and mark the live one. Do not change anything until you show me the choices. After I select a version, roll back to it and return the restored version number and live URL.

Not every iteration has to go through a rebuild. Once a site is published, the connected agent can edit a single file on it directly and publish the result as the next version.

Common Codex deployment problems

Birta is missing from /mcp

Run codex mcp list. Add the server again only if it is absent. If it exists but authentication failed, run codex mcp login birta and complete the browser flow.

The deploy has no index page

The published site has no index.html at its root. Inspect the framework output directory, rebuild from the project root, and publish its files with the paths taken from that folder rather than with the folder name in front of them.

The build expects a server

A route, API, database, or runtime environment variable is still required after the build. Choose application hosting; removing the error message does not make the architecture static.

Images or fonts are missing

Check URL paths and filename case first, because that is almost always the cause. PNG, JPEG, WebP, WOFF and WOFF2 files are published and served like any other asset. PDFs are not served from the site, so link those from a public URL.

Codex picked the wrong project

Stop before publishing. Ask Codex to list projects with their names and addresses, then name the exact destination in the prompt. Never infer the target from a similar project name.

Frequently asked questions