2
1 Comment

We gave Claude deploy access to production. The hard part was choosing what to forbid.

Quick follow up to my origin story post from earlier this week. A few people asked about the MCP part, so here is how it actually works and what we learned building it.

The flow from the user side is almost embarrassingly short. You finish your code in Claude or Cursor. You say deploy this. About two minutes later you get a working link back: server provisioned, SSL in place, environment configured as part of the deploy. Then the part I personally use most: you change something, say update it, and the same link refreshes. No terminal, no dashboard, no context switch.

Why bother? Because the place where people write code with AI is a chat window, and every step that forces them out of it loses users. For technical folks that step is friction. For people like me, and I can't code, that step is fear. The dashboard is where I start guessing. The chat is where I already know what to say.

But here is the part that turned out to be the actual work. Giving an AI agent the power to deploy is easy. Deciding what it must never be able to do took longer than the integration itself. And honestly, the line ended up in a different place than I expected.

What the agent can do, the full project lifecycle:

  • create and deploy a project
  • redeploy and update it
  • add and remove custom domains
  • work with project files

What it can never touch, by design:

  • billing and subscription (read only, the write tools simply don't exist)
  • the account itself

On top of that, every action is rate limited and every single one lands in an audit log. And every deploy coming through MCP goes through the same security scanning as a manual upload, before the agent even gets the project. The line is not deploy versus delete. The line is money versus everything else.

The thing that surprised us most: first deploys get the applause, but updates carry the product. Watching usage, the loop of tweak, update, check the link is where people actually live. An agent that can only deploy once would be a demo. The boring update path is the feature.

We are in open beta, and this whole thing is still being shaped by whoever shows up and breaks it. Which brings me to the question I'm genuinely curious about: if you build with AI tools, where is your personal line? What would you happily let an agent do to your production, and what stays human only?

on June 5, 2026
  1. 1

    The strongest point here is that first deploys are the demo, but updates are the habit.

    A lot of AI deployment products will probably over-position around “ship from chat,” but the real trust problem is what happens on the 12th update, when the user is moving fast and the agent has enough power to create damage.

    So I think the sharper frame is less “Claude can deploy to production” and more “Claude can keep updating production safely inside strict boundaries.”

    That also makes the forbidden list more important than the feature list.

    For me, money, account ownership, customer data, and destructive infra actions stay human-only. Deploy/update can be agentic if the rollback, audit log, permission boundary, and scan layer are obvious enough that the user does not have to trust the agent blindly.

Trending on Indie Hackers
Your build-in-public audience is not your market. I learned the difference the slow way. User Avatar 257 comments Most founders don't have a product problem. They have a visibility problem User Avatar 57 comments Day 4: Why I Built a $199 Workspace Nobody Asked For User Avatar 39 comments How to automatically turn customer feedback into high-converting testimonials User Avatar 39 comments Built a "stocks as football cards" thing. 5 days in, my launch tweet got 7 views. What am I missing? User Avatar 34 comments Spent months building LazyEats AI. Spent 1 day realizing I have no idea how to get users. User Avatar 29 comments