Deploy from Claude Code in one call

You asked your agent to build a site. It wrote the HTML, ran the build, and now there is a folder of files on disk that nobody can see. The last step — getting it onto the web — is usually where the flow breaks. The agent stops, hands you a list of instructions, and you go off to do the deploy by hand. This post is about closing that gap: publishing a site straight from Claude Code, in one call, without leaving the conversation.

The friction with a traditional host

Most hosts were built for a human sitting at a dashboard, not an agent in a terminal. To put a site live on Vercel or Netlify the usual way, you create an account, connect a git remote, push the repo, wait for a build to run on their infrastructure, and then read a deploy log to find the URL. Every one of those steps is fine on its own. Strung together, they are five context switches that an agent cannot complete on its own — it needs your account, your git credentials, and your attention at the dashboard.

For a static site that is already built, most of that ceremony is buying you nothing. The files are done. You do not need a remote build, a CI pipeline, or an account wizard. You need a way to hand the bytes to a server and get a URL back.

shiply’s one-call model

shiply.now is built the other way around. The publish flow is an HTTP API first, and everything else — the dashboard, the CLI, the MCP tools — sits on top of it. Publishing needs no account: an agent can send a folder of files and get a live URL back in the same turn. The site is served from Cloudflare’s edge at <slug>.shiply.now, and there is no build step on shiply’s side. Whatever you upload is what gets served — plain HTML, or the build output your agent already produced.

Anonymous sites are deliberately temporary. They are live the moment they finish publishing and they expire after 24 hours unless you claim them. That makes the first publish genuinely zero-friction: no signup gate stands between “the files are done” and “here is the URL.” When you want to keep a site, you claim it — more on how in a moment.

Three ways to call it

There are three interfaces over the same publish flow. Pick whichever fits where your agent is running.

1. The MCP server (an agent calls it directly)

shiply runs an MCP server at https://shiply.now/mcp. Connect Claude Code to it and the agent gets a publish_site tool it can call on its own — no shell, no curl, no copying a URL between windows. The tool works without authentication: the response comes back with the live URL plus a one-time claim token. This is the path to reach for when the agent is doing the work, because publishing becomes one tool call inside the same conversation that built the site.

2. The CLI (one command in the terminal)

If your agent has a shell, the CLI is the shortest path. Point it at the directory you want to serve:

npx shiply-cli publish ./dist

It prints a live URL. One note worth getting right: the npm package is shiply-cli, not shiply — a different, unrelated package owns the bare name. The CLI also remembers the site it published so that the next publish updates the same URL instead of littering new ones, which matters once you are iterating.

3. Raw HTTP (the three-step flow underneath)

When npm is not available, or you just want to see the mechanics, the publish API is three steps. The site is live only after the third one finishes.

First, declare the manifest — the files you intend to upload, with their paths and sizes:

POST https://shiply.now/api/v1/publish
{
  "files": [
    { "path": "index.html", "size": 1840, "contentType": "text/html" }
  ]
}

The response gives you a slug, the site URL it will live at, and a presigned upload URL for each file. Because no auth header was sent, it also returns a claimToken and a claimUrl — save them, they are shown once.

Second, PUT the raw bytes of each file to its upload URL.

Third, POST to the finalize URL with the version id from step one. The version flips live atomically, and the site is now serving at its URL. That is the whole API: declare, upload, finalize.

A realistic version of this is an agent that has just run npm run build, walks the dist/ folder, and publishes it. It declares every built file in one manifest, PUTs each one, finalizes, and reads the URL back to you — all without you touching a dashboard.

Claim to keep it

An anonymous site expiring in 24 hours is a feature, not a limitation — it means the trial costs you nothing and leaves nothing behind. To make a site permanent, you claim it. Every anonymous publish returns a claim URL; open it in a browser and the site moves into an account, creating a free one first if you do not have it yet. From an agent, there is a smoother path: pass an agent name on the publish and the response carries a device-authorization flow. You open one URL, approve once, and that single action both claims the site you just published and authorizes the agent to make owned publishes from then on. After that, re-publishing updates the same site rather than spawning a new one.

When you would reach for this

This model fits a specific shape of work. It is the right call when an agent built the site and should be able to ship it — a generated landing page, a one-off report, a prototype you want to put in front of someone in the next minute. It fits client work and throwaway demos, where standing up an account and a git remote is more setup than the job deserves. And it fits the case where you simply want a real URL back fast, with a price you can read off the card: flat at $0, $8, or $24 a month, with no usage meter underneath.

It is not the right tool for everything. shiply serves static files and build output — there is no server-side code running your application logic on a normal site. If you need a full backend, a remote build pipeline, or per-request compute as the core of the product, a host built for that is the better fit. The trade shiply makes is narrow on purpose: take a finished static site from a folder to a live URL in one call, and get out of the way.

The short version

Traditional hosting asks an agent to be a human: make an account, connect git, trigger a build, read a log. shiply collapses that into a single HTTP call that needs no account, returns a real URL on Cloudflare’s edge, and serves your files as-is. Start anonymous and free, claim the site when you want to keep it, and let the agent that built the site be the one that ships it.