CODEX HOSTING
Codex hosting: publish what the agent built
Codex works on a repository. A cloud task ends in a pull request, and the CLI and IDE extension change files on your own machine. Either way what you end up with is a branch, so publishing means building that branch and uploading the folder it produces.
Free plan, free SSL, no credit card.
- 1
- branch, which is what a Codex task leaves behind
- 23
- framework guides, one per build command
- 1
- free site with HTTPS, no card
- 25
- publishes a day on the free plan
What you are holding
What Codex outputs
Changes to a repository. OpenAI documents Codex as running in the cloud, in an open-source CLI, and in an IDE extension for VS Code, Cursor and other VS Code forks, with a cloud task ending in a pull request when the work is ready.
So there is no artifact to download and no export flow to follow. What exists after a task is a branch, or a set of edits in your working tree. Publishing is therefore the ordinary thing: check out the branch, run the project's build, and upload the folder the build wrote. The agent is not really part of that question, which is why this page spends its time on the folder rather than on the agent.
The part that is specific to an agent is worth stating plainly. A cloud task can touch a build configuration, a base path, or an environment file without your noticing, because you reviewed the feature rather than the plumbing. So the first publish after a Codex task deserves the same review as a merge: look at what the build produced, not only at what the diff said.
The fork
Which of the two paths you are on
Once the branch is checked out, this is the same question every project answers.
Already static, no build
The repository is a folder of HTML, CSS, JavaScript and images with an index.html at the root. No compilation involved.
- Upload the folder directly, or zip its contents with
index.htmlat the top level. - Exclude
.gitand any.env: neither belongs at a public address. - A single self-contained page can be dropped on its own.
- Up to 25 MB per upload on the free plan, 25 MB across the account.
A project, build the branch first
There is a build script. Check out the branch, install, build, and upload what the build wrote.
- Run
git checkouton the branch, thennpm installandnpm run build. - Build the branch you actually want live, not whatever was last checked out.
- Upload the output folder, not the repository root and not
node_modules. - The deploy guides name the command and folder for 23 frameworks.
Step by step
From a Codex task to a live address
Codex leaves you a branch rather than a build, so these steps start where its documentation stops.
-
Get the branch onto your machine
A cloud task can open a pull request when the work is ready; the CLI and IDE extension change files locally. Either way, check out the branch you want to publish.
-
Read the diff for build and config changes
Look specifically at
package.json, the framework config and any.envfile. Those are the changes a feature review tends to skim, and they are the ones that decide what the build produces. -
Install and build
Run
npm install, thennpm run build. If the build fails here, it would have failed in a pipeline too, and finding out on your own machine is faster. -
Upload the output folder
Drop the folder the build wrote. Not the repository, not
node_modules, and never the.gitfolder. -
Check the published page against the task
Open the live address and confirm the thing you asked for is on it. This is the review step a pull request cannot do for you.
Codex surfaces and outputs from OpenAI's own material, read 8 September 2026: the Codex upgrades announcement at openai.com states that the Codex CLI is open source and that the IDE extension brings the agent into VS Code, Cursor and other VS Code forks, and the Codex cloud documentation at developers.openai.com describes choosing an environment, describing the result you want, watching the task logs or letting it run in the background, asking for follow-up changes, and opening a pull request when the work is ready. Product surfaces can change.
Who it is for
The people who reach for this
-
Developers
A branch an agent wrote, at a URL a reviewer can open, before deciding whether it deserves a real deploy target.
-
Reviewers
A pull request read as a running page rather than as a diff, which is the only way some changes can be judged.
-
Product and marketing
The change the agent made, visible to somebody who does not read code, at a link that expires when the review does.
-
Solo builders
You are the only reviewer. Seeing the built branch at an address is faster than reasoning about it.
In detail
What you actually get
A branch as a page somebody can open
The most useful thing about publishing agent output is that a reviewer can look at it instead of reading it.
- Expiring links from Starter: six hours, a week, or a date, so a review link cleans itself up.
- Password protection from Starter, checked at the edge before any file is served.
- A separate site per branch if you want them side by side, within your plan's site count.
- The address stays the same across republishes, so re-running the task does not re-send the link.
Publishable from a script
If the agent is in your terminal, the publish can be too, without a browser in the loop.
- A public API for deploying from a script or a job.
- A VS Code extension that signs in with email and works on every plan, including in VS Code forks.
- Raw API tokens are a paid feature; the extension sign-in is not.
Versions, because agent output gets re-run
A task rarely lands right the first time, and comparing two attempts is easier when both were published.
- Up to 25 publishes a day on the free plan.
- From Pro, restoring the previous version is one click.
- The swap is atomic, so a reviewer never opens a half-published page.
Troubleshooting
What breaks, and why
The two below are the ones that come specifically from publishing a branch an agent wrote.
-
The .git folder went up with the site
Why You uploaded the repository rather than the build output, and
.gitcame with it. That directory contains your full history, which at a public address is readable by anyone who guesses the path.Fix Upload the build output instead. The deploy-time security check flags a published
.gitfolder explicitly, on every plan, because this is the mistake with the worst consequences. -
The build behaves differently from the task description
Why The agent changed something under the feature: a base path, a build script, an environment variable. The pull request was reviewed for what it was asked to do, and the plumbing went through unread.
Fix Diff the config files before building, and open the published page rather than trusting the diff. A page at an address is the only review that catches this class of change.
-
Every route except the home page returns a 404
Why The app routes in the browser, so /about exists only once JavaScript has run. A static host asked for /about looks for a file at that path, does not find one, and answers 404 before your code loads.
Fix Turn on the Single-page app switch in the site settings. Unknown paths are then served the root index.html and the client router takes over. Free on every plan, applied without a redeploy, and off by default because a multi-page site wants real 404s.
-
The API keys the tool wrote into the code are now public
Why AI tools fill in the value they can see, and a key in front-end code is readable by anyone who opens the page. No host can fix that: a published page is public by definition.
Fix The deploy-time security check names the key it found. Rotate it, then move the call behind something that can hold a secret. Every plan, free included, and it never blocks the publish.
No card required
What the free plan includes
Publishing a branch to look at it costs nothing, which is what makes it worth doing for a change you are not sure about yet.
- 1 live site on a real free plan, not a trial of a paid one, with HTTPS and no card to start.
- Up to 25 MB per upload and 25 MB of storage across the account.
- 5,000 visits and 5 GB of traffic a month.
- Up to 25 publishes a day, which is the number that matters when you are regenerating.
- The Single-page app switch, so a client-routed build works without paying for anything.
- The deploy-time security check, which warns about a stray .env file, a .git folder, a private key or an API key left in your JavaScript.
- A small Droply badge in the corner of the page. Removing it starts on Starter.
- Free sites are served noindex, so search engines do not list them. Search visibility starts on Starter.
Droply vs Static.app
How this compares with the other host built for AI output
Static.app has a Codex page of its own. These rows come from its published pricing and its own documentation.
| Droply | Static.app | |
|---|---|---|
| Upload a build folder | Yes, directly, no archive required. | ZIP is the documented path. |
| Expiring links for a review | From Starter: six hours, a week, or a date you pick. | Not listed on any of its plans. |
| Password protection | From Starter, enforced at the edge. | Not listed on any of its plans. |
| Rollback to an earlier build | From Pro, one click. | Backups are listed as a feature page. |
| Loose .html file accepted | Yes, dropped on its own with nothing around it. | No. Its Claude page states a loose .html file is not accepted and must be zipped. |
| Single .jsx or .tsx without a build | Yes. It is transformed in the visitor browser at the published address. | No. Its Claude page says React-based artifacts need a self-contained HTML version first. |
| Free plan | 1 site, 25 MB storage, no card, and a plan rather than a trial. | A 7-day trial with no credit card, then paid. 1 site and 50 MB during it. |
| Security check on every publish | Every plan, free included: leaked keys, a stray .env, a committed .git folder. | Not offered. |
Static.app figures checked 8 September 2026 on its own pricing page (free tier: 1 site, 50 MB, a 7-day trial with no credit card; Starter $5 a month or $60 a year for 2 sites and 500 MB with a custom domain; Medium $10; Large $15) and on its Claude hosting page, which states that a loose .html file is not accepted and must be zipped, that React-based artifacts need an extra step because you have to ask the model for a self-contained HTML version, and that Import from URL takes claude.ai and claude.site links. Product plans can change.
When Droply is the wrong choice
Codex is used on real applications more often than on brochure sites, and most real applications are not static.
- The branch changes an API, a server-rendered route or a database migration. None of that can be shown at a static address.
- You want every pull request published automatically. There is no Git integration and no CI here: a publish is an upload or an API call you make.
- The generated app has a database, a login screen or server actions. Those need a runtime; only the static half of it can be published here.
- You want a build to run here, on upload or on every push. There is no build step and no Git integration: you build locally and bring the output.
- You are running WordPress or another PHP application. A static export of it can be hosted here, but the application itself cannot.