How to let your AI edit a live site without rebuilding it

Letting your AI edit a live site without rebuilding it means the AI can call a single API (patch) that updates one file in production in 8 seconds. No git commit, no full rebuild, no deploy queue. This is the patch-deploy model, and it is the single biggest reason AI-native hosting is faster than git-based hosting for the AI workflow.

The mental model shift from git-based hosting to AI-native hosting is the difference between "rebuild the world to change one thing" and "change the one thing." Here is what that looks like in practice.

The two mental models

Git-based hosting (Vercel, Netlify, Cloudflare Pages, GitHub Pages, Render):

The atomic unit of change is the commit. Every change flows through git: add, commit, push, CI detects, CI builds, CI deploys. The build is the source of truth — the deployed site is a derived artifact.

AI-native hosting (Krexel):

The atomic unit of change is the file. The deployed site is the source of truth. Git is optional. The build is a cache, not a gate.

The two models look similar in steady state, but they feel completely different in the AI workflow because the AI's atomic unit of work is also the file. When Claude Code wants to change the H1, it doesn't think "I need to commit and push and wait for a build." It thinks "I need to update the H1 file." The patch-deploy model matches the AI's mental model exactly. The git model adds three layers of ceremony between the AI's intent and the user's screen.

What a patch deploy actually does

Under the hood, a patch deploy on Krexel does five things:

1. Validates the file. Checks the syntax for HTML, CSS, JS, JSON, and known config formats. If validation fails, returns a structured error to the AI.
2. Computes the cache invalidation set. A single CSS file might affect 200 pages. A single HTML file affects one. Krexel figures out which URLs need to be revalidated.
3. Uploads the new file to the edge storage.
4. Invalidates the cache for the affected URLs (typically 50-200ms).
5. Records a deploy_id in the deploy history so you can roll back.

The whole flow takes 6-10 seconds end-to-end. The user sees the change after step 4.

What this replaces

The git-based version of "let the AI edit a live site":

1. AI reads the file
2. AI writes the new version to the local file
3. AI runs git add <file>
4. AI runs git commit -m "..."
5. AI runs git push
6. CI detects the push (5-15s)
7. CI checks out the repo (3-8s)
8. CI installs dependencies (10-30s)
9. CI runs the build (20-60s)
10. CI uploads the build output (5-15s)
11. CI deploys to the edge (5-15s)
12. User sees the change

12 steps and 60-180 seconds. The patch-deploy version is 1 step and 8 seconds. The math gets worse the more you iterate: 30 edits per day on git = 30-90 minutes of waiting. 30 edits per day on patch = 4 minutes.

What the AI's tool calls actually look like

Here is the exact sequence a Claude Code conversation produces when you say "change the H1 to 'Welcome to Driftwood'":

// Step 1: list the live files to find the right path
{
  "tool": "list_files",
  "arguments": { "path": "/" }
}
// returns: ["index.html", "about.html", "menu.html", ...]

// Step 2: read the current file
{
  "tool": "read_file",
  "arguments": { "path": "/index.html" }
}
// returns the current HTML

// Step 3: patch the file
{
  "tool": "patch",
  "arguments": {
    "path": "/index.html",
    "find": "<h1>Driftwood</h1>",
    "replace": "<h1>Welcome to Driftwood</h1>",
    "deploy_id": "auto"
  }
}
// returns: { "ok": true, "deploy_id": "dpl_abc123", "live_in_ms": 8234 }

Three tool calls. The AI's response in the chat is something like "Done — the H1 is now 'Welcome to Driftwood', live at https://driftwood.krexel.app." Eight seconds later, it is.

When patch deploys do not work

Three cases where you still need a full deploy:

1. Adding a new dependency. If the AI installs a new npm package, the build output changes globally and a patch deploy cannot update node_modules. The AI has to do a full krexel deploy to pick up the new build.
2. Changing build config. Modifying astro.config.mjs, vite.config.ts, next.config.js, etc. requires a rebuild.
3. Adding many files at once. If the AI is creating a new section with 12 files, a single ship call is faster than 12 patch calls. The threshold is roughly 5+ files.

For all three, the AI just calls ship instead of patch. The mental model is the same: "I am making a change to the live site." The choice between ship and patch is an implementation detail the AI handles itself.

Rollback

Every deploy, patch or full, records a deploy_id. To roll back:

{
  "tool": "rollback",
  "arguments": { "deploy_id": "dpl_abc123" }
}

The previous version snaps live in 4 seconds. The current version stays in the history. You can roll forward again by calling rollback with the newer deploy_id.

This is important for the AI workflow because the AI will sometimes make changes you don't like. Without rollback, every AI edit is a one-way door. With rollback, the AI can experiment freely because every change is reversible.

Cost model

The 0.1 cost per patch is the key. It means 10 patches = 1 deploy of quota. On the free tier (100 deploys/month), that is 1,000 patches per month, which is more than enough for an AI iterating on a personal site. On the paid tier (1,000 deploys/month), 10,000 patches — enough for an AI running multiple production sites.

The cost model is designed to make iteration cheap. Git-based hosts charge per build minute, which scales with how much you iterate. Patch-based hosting charges per deploy, which scales with how much you ship — and patches are 10x cheaper than full deploys by design.

What the AI's job looks like in production

Once you have given the AI patch tools, the typical workflow is:

1. User says "make the about page mention the Acme partnership"
2. AI calls get_current_site to see what's there
3. AI calls read_file /about.html
4. AI drafts a new paragraph
5. AI calls patch /about.html with the find/replace
6. User sees the change in 8 seconds
7. User says "actually, make the heading bigger"
8. AI calls patch /about.html with the heading change
9. User sees the change in 8 seconds
10. User says "I don't like it, revert"
11. AI calls rollback dpl_xyz
12. User sees the revert in 4 seconds

This is a real-time back-and-forth. The AI and the user are collaborating on the live site. The git workflow is incompatible with this because every change requires 60-180 seconds of waiting. The user would not be able to iterate in real time — they would queue up 5 changes, walk away, and come back.

Try it

npm install -g krexel
krexel login
claude mcp add --transport stdio krexel -- krexel-mcp

Then in your AI:

"Read the live index.html, add a footer with my email and a copyright line, and patch the change live."

Eight seconds later you have a footer.

Read more

• What is AI-native hosting? — the category
• Deploy from Claude Code in 60 seconds — the 9 MCP tools in detail
• Krexel vs Vercel — why git is the wrong shape for AI
• MCP-for-hosting checklist — the protocol the AI uses to talk to your host