Deploy a website from Codex — past the preview, onto your own domain

From a built folder to a live address, in three commands

Wire Clize into Codex, take a free handle, publish the folder Codex built, then move it onto a domain you own.

1. Wire Clize into Codex Run clize install --codex, which writes the skill into ~/.agents/skills, the open directory Codex reads.
2. Claim a free handle Run clize claim mystudio. The name is yours first come, first served, and it is the target the deploy needs; --email opens support@ on it too.
3. Deploy the folder Run clize deploy ./site --domain mystudio.clize.app. HTTPS is automatic and the reply prints the live address.
4. Move onto a domain you own Run clize domain buy mystudio.com --confirm, then deploy against that host. The certificate is issued in about thirty seconds.

The whole chain, with real output

Assume Codex has written the site already — a folder of HTML, CSS, JavaScript and images, or the static build output of a framework project.

$ npm i -g @clize/clize
$ clize login
$ clize install --codex

Add --dry-run the first time and it shows where the capability lands before writing anything:

$ clize install --codex --dry-run
▸ Codex
    skill · up to date · clize → ~/.agents/skills/clize/SKILL.md
    skill · up to date · clize-site-build → ~/.agents/skills/clize-site-build/SKILL.md
    mcp   · skipped (default; add --mcp for the structured tool layer)

Then a name — handles are free and first come, first served, so this comes before the deploy rather than after it:

$ clize claim mystudio
✓ mystudio.clize.app is yours; the placeholder site is in place. Inbound is not open (off by default) — one command adds it.

$ clize deploy ./site --domain mystudio.clize.app
Live at https://mystudio.clize.app (14 files: 14 KV + 0 R2; uploaded 14, skipped 0; TLS automatic)

That is a real HTTPS address with a certificate you never requested. clize init --handle mystudio binds the directory once, after which clize deploy ./site is enough. One thing worth setting deliberately on a site meant to be indexed: unknown paths return a real 404 when the folder has a 404.html and otherwise fall back to index.html with a 200 — --not-found 404-page forces the first.

Where the official guide stops

OpenAI publishes a use-case page for exactly this task: hand Codex a repo, a screenshot or a design brief, let @build-web-apps build it, let the @vercel plugin deploy and return the URL, then iterate from that URL in the same chat. On the last step it is explicit — "A preview deployment is the default; ask for production only when you mean it."

Good advice, and also the end of the page. A preview deployment is a disposable URL on a platform subdomain, built for review. The domain is assumed throughout. And nothing receives mail: the moment the site says "contact us", something has to catch the reply, and no deploy plugin ships a mailbox.

The curated skills repository has the same boundary at larger scale — skills/.curated/ carries deploy skills for Netlify, Vercel, Cloudflare and Render. Four working paths to a URL, not one of which registers a domain or opens an inbox, because that is not what a deploy skill is for. The gap is not an oversight in any one guide; it is the distance between "deployed" and "live".

No second account to open

The two hosting products people land on next are both legitimate. What they share is the first step.

Netlify. Its Codex-native route adds Netlify as an MCP server so the agent can create and publish sites with, in its words, no separate deploy step — and needs an account to do it. OpenAI's curated netlify-deploy skill spells the prerequisite out: the Netlify CLI, a valid project, and a Netlify account with an active login session, checked with npx netlify status before anything runs. Netlify Drop is the advertised exception — a live URL with no account — but you download the folder and drag it into a browser, a human in the middle of an agent workflow.

static.app. Its Codex hosting page is the closest thing to this one on the open web: HTTPS with no configuration, built-in forms, custom domains, a desktop app that republishes on every rebuild. The entry is an upload — ZIP the output and drop it, or install the sync app and sign in.

Clize starts elsewhere: you already have a Codex account, and that is the account. The free tier is a tier rather than a trial — three handles, five mailboxes, twenty deploys a day, 500 MB per site — and the only step that costs money is registering a domain, which quotes the price first.

Where the domain comes from

This is the question the other three leave to you, and Codex can answer it itself:

$ clize domain search mystudio
$ clize domain buy mystudio.com          # quote only — nothing is registered
$ clize domain buy mystudio.com --confirm
$ clize deploy ./site --domain mystudio.com

domain search prices several names at once. domain buy without --confirm returns a quote and registers nothing — that gate is on every command that spends money, which is what makes it reasonable to leave in an agent's hands. Auto-renew is on by default, and the certificate is issued about thirty seconds after the domain is bound. A name you already own comes in with clize domain import, and clize domain check yourname.com is the four-layer diagnosis for a site that "deployed fine" but will not open.

And an address people can write to

A launched site has somewhere for replies to land. That is the half no deploy tool covers, and here it is one flag:

$ clize claim mystudio --email
✓ mystudio.clize.app is yours; the site and support@mystudio.clize.app are in place.

# or on the domain you bought:
$ clize email setup mystudio.com          # MX, SPF, DKIM, DMARC handled

Inbound is off by default because each receiving handle costs DNS records in a shared zone. With it on, Codex can read the mailbox rather than merely forward it: clize email inbox returns what arrived, filtered to people and verification codes, and --wait-for blocks until a specific message shows up — which is how an agent signs the site up for a forms service and confirms it on its own. Outbound has the mirror gate: clize email send drafts by default and sends only with --confirm. Agent Inbox is that half in full.

How Codex actually picks this up

Skills. clize install --codex writes four SKILL.md files into ~/.agents/skills/ — the open Agent Skills directory rather than a Codex-specific path, which is why Pi and OpenClaw read the same copies. Nothing restarts and no config is edited, and skills are read only when relevant, so they cost no context in sessions that do not need them.

MCP, if you prefer structured tools. The syntax matches Claude Code's — both take the stdio command after a -- separator — but they write to different config files, so a machine running both hosts registers twice:

$ codex mcp add clize -- clize-mcp        # lands in ~/.codex/config.toml
$ claude mcp add clize -- clize-mcp        # Claude Code, for comparison

To keep only the shipping half in context, the server takes a profile: clize-mcp --profile sites narrows it to claiming a handle and deploying a site, plus the account calls that let the agent report what it is about to spend. A bare clize install covers both hosts in one pass — the Claude Code walkthrough takes that side.

What this will not do

• Static files only. A framework project is fine if it builds to static output, but there is no Node process, no server-side rendering, no database and no logged-in application. If Codex just wrote you an Express API, Vercel or Netlify is the right host.
• The two exceptions: form and waitlist submissions forwarded to an endpoint you name, and a real checkout if the site sells something.
• Size limits are real. 500 MB per site on the free tier, 90 MB per file, twenty deploys a day.
• Clize does not write the site. Codex does — the repo stays yours, and Clize stores the built output, never the source.

What is left is narrow: for a marketing site, a launch page, docs or a portfolio, this ends on a domain you own, with a certificate and a working inbox, run by the agent that built it. Sites by Clize is the category page, the Lovable and Bolt comparison asks the same question of browser builders, and the command reference lists every flag above.

$ npm i -g @clize/clize && clize login
$ clize install --codex
$ clize claim mystudio --email
$ clize deploy ./site --domain mystudio.clize.app