From one sentence to a live site — 39 design styles, real code in your repo, HTTPS and working email included.
Free handle included · No credit card · Works in Claude Code, Codex & any agent that runs skills or MCP
Domain pointed · DNS set · certificate issued · support@ ready when you ask for it
Your agent works in the chat. The site is really live.
Four things people actually use it for — from day one.

A hosted design method the agent follows — the site gets a temperament, not a template smell.

The pages are ordinary files your agent wrote — edit them, version them, take them anywhere.

Domain, DNS and HTTPS in one deploy — and an inbox on the same name, one flag away.

A local preview shows the real thing first — ship only when it looks right.
Every job runs the same way — and the domain is always yours.
Three steps. No dashboard, no config homework.
One package. clize install wires the skill into Claude Code, Codex, Pi — any agent that runs skills or MCP; log in once in the browser.
$ npm i -g @clize/clize $ clize install $ clize login
Brief in — style and design method out.
$ clize build site startPreview locally, then one deploy to a live domain.
$ clize serve $ clize deploy
Nothing is locked in a browser IDE — the site is files you keep.
Buying a domain or generating images always shows the price and waits for your confirm.
A real domain with working email — not a preview link that dies with the sandbox.
The half an agent normally can't finish. The files exist; the address doesn't. This is what closes that gap.
Deploy takes a directory and keeps its shape — index.html at the root, assets exactly where you wrote them. A trailing-slash URL resolves to that folder's index without a redirect, so nothing you linked in the markup moves.
$ clize deploy ./site → https://kilnhouse.clize.app
Ship a 404.html and a missing path answers with a genuine 404 — the thing a search engine needs to see. Without one the site falls back to the index. --not-found forces either behaviour when you want to decide it yourself.
$ clize deploy ./site \
--not-found 404-pageThe next deploy replaces the last one at the same address. There is no pipeline to configure and no build server to keep warm. A free account runs 20 deploys a day and carries 500MB per site.
$ clize deploy ./site \
--domain kilnhouse.studioComing in with one file instead of a project? Hosting a single HTML file is the short road, and the HTML viewer renders it in your browser before anything ships. Coming out of a chat instead of a repo — hosting a Claude artifact covers what an artifact is missing.
Normally four consoles and an afternoon. Here it is one chain the agent runs while you watch.
clize claim takes a free your-slug.clize.app, first come first served, up to three of them on a free account. Inbound mail stays shut until you add --email — every mailbox spends records in a shared zone, so we don't hand them out unasked.
$ clize claim kilnhouse --emaildomain search answers availability and price together, domain buy registers with auto-renew already on, and domain import brings a domain you registered elsewhere onto Clize's nameservers in one step you can safely repeat.
$ clize domain search kilnhouse \
--tld studioDeploying with --domain binds the host, then DNS and the TLS certificate are configured for you — a few minutes, no dashboard. Afterwards domain check reads all four layers back: registry delegation, zone, binding, served content.
$ clize domain check \
kilnhouse.studioThe same three commands from a different chair: deploying a website from Codex. Weighing this against a browser builder first — Lovable vs Bolt, judged on what happens after the build. The mailbox half of the name lives in Inbox.
An agent with hands in the real world needs brakes that are real too. All four are in the CLI, not in the pitch.
Registering a domain prints the price and stops there. The purchase happens only on a second run carrying --confirm — a wrong guess costs a line of output, never a charge.
Outbound is drafted for review; --confirm is what actually sends. Repeating the same recipient and subject within ten minutes is refused, so a retried run can't send the message twice.
What lands in the inbox is something the agent reads, never something it obeys. Promotions and notices are triaged out of the default view, and no message can redirect a run.
Point a stale project checkout at a live host and it ships to that host's real project and corrects itself on disk. Only an explicitly contradictory -p is refused, so two sites can't be crossed by forgetting which folder you're in.
And the honest limit, before you build on it: static pages, with forms and payments layered on top. No database, no server-side rendering, no logged-in application. If the product needs those, run it yourself and let this carry the site in front of it.
The short honest versions.
Sites is the web product of Clize: your coding agent writes a marketing site against a hosted design method, and Clize publishes it to a live HTTPS address — a free handle or your own domain — with an inbox on the same host. It installs into Claude Code, Codex, and any agent that runs skills or MCP, as a CLI and MCP server.
Live. The agent runs one deploy command and the folder becomes a public HTTPS address it can hand back to you. A local preview server is available for the pass before that, but it is a step in the run, not the end of it.
Yes. Every site is served over HTTPS, on a free handle at your-slug.clize.app or on a domain you own. The agent can search for a domain and register it, but anything that costs money is quoted first and needs your explicit confirmation.
It is one flag away. Claim a handle with --email, or run email setup on the domain afterwards, and support@ on that host receives mail your agent can read. Outbound is gated: the agent drafts, you approve, then it sends.
Those are browser-based builders: you work in their editor, and the site lives in their project. Sites keeps the work in the coding agent and repo you already use, and covers the parts a generated site usually lacks — the domain, the certificate, and a mailbox — from one account.
Your backend. Clize hosts static sites, plus forms and payments layered on top; it does not run a database, server-side rendering, or a logged-in application. If your product needs those, host the app yourself and let Clize carry the marketing site in front of it.
Yes, when you ask for one. Search reports availability and price in the same answer, buy registers the name with auto-renew already on, and import brings over a domain you registered somewhere else. Every paid step quotes first and stops; the registration only happens on a run that carries --confirm.
Neither. There is no pipeline to configure and no build server to maintain. Deploy is a real-world action the agent requests — folder to address, domain, DNS, certificate — behind a money gate and an identity gate, in the terminal you already have open.
A free .clize.app handle includes hosting, HTTPS and a working inbox.
$ npm i -g @clize/clize && clize install && clize build site start