January 2026

How I Made Claude Code Do Its Own Deployments

Most developers use AI assistants to write code, then manually run migrations, deploy functions, and push to production. That's leaving 40% of the workflow on the table.

I fixed that. Now when I ask Claude to add a feature, it writes the code AND deploys it. The entire backend-to-production loop happens in one conversation.

This is the difference between using AI as a typing assistant and using AI as an operator.

The Problem

Here's what my workflow looked like before:

  1. Ask Claude to implement a feature
  2. Claude writes migration file
  3. Claude says: "Now run supabase db push --linked"
  4. I copy the command, open terminal, run it
  5. Claude writes edge function
  6. Claude says: "Deploy with supabase functions deploy agent-think"
  7. I copy, paste, run
  8. Repeat for web, iOS, etc.

I was the bottleneck. Claude had to wait for me to context-switch, copy commands, run them, paste output back. It broke flow. It was slow.

The insight: Claude already knows the commands. Why am I the one running them?

The Fix: A Single Source of Truth

I created SOP.md (Standard Operating Procedures) — one document that tells Claude exactly how to operate in my codebase.

The key sections:

1. Default Behaviors

Things Claude does automatically without asking:

Action Tool/Command
Database migrations supabase db push --linked
Edge function deploy supabase functions deploy <name>
Web deploy vercel --prod
Migration repair supabase migration repair --status reverted <id> --linked

This isn't just documentation. It's permission. Claude reads this and knows: "I can run these commands. I don't need to ask."

2. Tool Access Map

Explicit about what requires human intervention:

Action Claude Can Do Needs Me
Supabase migrations Yes
Supabase edge functions Yes
Supabase secrets Yes (dashboard)
Vercel deploy Yes
iOS TestFlight Yes (Xcode)

Claude knows when to stop and when to proceed.

3. Decision Trees

What to do when things break: 

Error: "Remote migration versions not found"
  → Run: supabase migration list --linked
  → Find orphaned remote IDs
  → Run: supabase migration repair --status reverted <id> --linked
  → Retry: supabase db push --linked

This happened today. Instead of me debugging, Claude diagnosed and fixed the migration history mismatch on its own.

Real Example: The Session That Made This Clear

I asked Claude to implement a comprehensive notification system. Here's what happened:

Me: "Implement granular notification preferences — let users toggle morning briefing, afternoon check-in, proactive nudges separately."

Claude:

  1. Created migration file with new columns
  2. Ran supabase db push --linked
  3. Hit migration history error
  4. Diagnosed: orphaned remote migrations
  5. Ran supabase migration repair twice
  6. Re-ran migration successfully
  7. Updated edge function
  8. Deployed edge function
  9. Created iOS service
  10. Created iOS settings view
  11. Updated web app

All in one conversation. I watched. That's it.

Total human intervention: zero commands typed.

What Makes This Work

1. Explicit Permission

Claude is cautious by default. If you want it to deploy to production, you have to say so clearly. The SOP document is that explicit permission.

2. Context That Persists

The SOP lives in the repo as SOP.md. Claude reads it at the start of every session. The context carries forward.

3. Failure Handling Documented

Most "let Claude do it" setups fail at the first error. By documenting decision trees for common failures, Claude can self-recover.

4. Clear Boundaries

"Deploy edge functions: yes. Create Supabase secrets: no." When boundaries are clear, Claude operates with confidence inside them.

The Full SOP Structure

Here's what ended up in the document:

  1. Default Behaviors — Things Claude does automatically
  2. Tool Access Map — What Claude can/can't do
  3. Workflows — Step-by-step for features, bugs, deploys
  4. Decision Trees — Error recovery paths
  5. Tech Stack — Where everything lives
  6. Design System — UI principles (absorbed from existing docs)
  7. Quality Gates — Checklists before "done"
  8. Patterns — Learnings from previous sessions

Total: ~400 lines. One file. Single source of truth.

Results

Before: Feature requests took 2-3 back-and-forth sessions. I'd forget to deploy something. Things would break in production hours later.

After: Feature to production in one conversation. Claude handles the full loop. I review what shipped.

Time savings: Hard to measure, but context-switch elimination alone is probably 30-40% of my previous workflow.

Error reduction: Claude doesn't forget to deploy. I do.

The Meta-Lesson

This is what "AI-native workflow" actually means. Not using AI to type faster. Using AI to operate.

The companies winning right now aren't the ones with the best AI code generators. They're the ones who've figured out how to let AI handle the entire shipping loop.

Migrations. Deployments. Error recovery. All of it.

If you're still copy-pasting commands from Claude's output, you're leaving most of the leverage on the table.

Try This

  1. Create an SOP.md in your repo
  2. Start with three sections:
    • Default Behaviors (what Claude can run)
    • Tool Access Map (what requires you)
    • One Decision Tree (your most common error)
  3. Tell Claude to read it at session start
  4. Watch what happens

The leverage is real.

Code

The full SOP template is available in the project repo. Adapt it for your stack.

← Back to Build Log