Vibe Coding to Production: How to Ship AI-Built Apps Without Breaking Everything

You vibe-coded a full app in a weekend. It runs locally. It's actually good. Now what?

This is the moment where a lot of AI-native builders hit a wall. The vibe coding to production gap is real, and it's not a skill problem — it's a context problem. Cursor and Claude Code are extraordinary at generating working code. They are not trying to be your DevOps team. That gap is yours to close, and in 2026, it's the #1 friction point for builders who move at AI speed.

This guide is for you: the developer who shipped a real thing over a weekend and now needs to deploy it without quietly destroying your AWS account, leaking credentials, or waking up to a $4,000 bill.

---

The Vibe Coding Production Gap

When you generate code with an LLM, you get code that works in the happy path. What you often don't get is production hardening — and that's not a knock on the tools, it's just the nature of the problem. Here's what actually breaks when you push AI-generated code to real infrastructure.

Missing environment variables

Your app runs locally because you have a .env file. On the server, that file doesn't exist, and the LLM didn't add secrets management — it assumed you'd handle it. So your app crashes on startup, throws a null reference, or silently falls back to an unauthenticated state. This is the most common first failure.

Example: Your Next.js app calls process.env.OPENAI_API_KEY. Claude Code wrote that correctly. But your EC2 instance has no idea what that variable is, and you didn't configure it in Parameter Store or Secrets Manager. The app starts, hits a route that calls the OpenAI API, and throws a 500.

Wrong IAM permissions

LLMs tend to suggest IAM policies that are broad enough to "just work." s3:* instead of s3:GetObject. iam:* on a Lambda that only needs to write to DynamoDB. This isn't laziness — it's the model optimizing for the code working, not for least-privilege security. When you deploy this to prod, you've just opened blast radius on a misconfigured role.

No observability

The app runs. Then something goes wrong — a user can't log in, a webhook stops firing, a job silently fails. You have no logs, no metrics, no alerting. You find out when a user emails you or, worse, when you check your database and notice nothing has been written for six hours. AI-generated apps rarely include structured logging or distributed tracing because those aren't functional requirements — they're operational ones.

Cost surprises

LLMs write code that calls APIs in loops, spins up resources eagerly, and doesn't think about throttling or caching. A DynamoDB table with on-demand pricing and no query optimization. A Lambda that calls an external API on every invocation with no memoization. An S3 bucket configured for public access with no lifecycle rules. These are time bombs. You don't notice until the bill arrives.

Security misconfigs

An S3 bucket set to public. An RDS instance with a security group open to 0.0.0.0/0. A Kubernetes service exposed as LoadBalancer instead of ClusterIP. These are the kinds of configurations that pass a smoke test (the app works) but fail a security audit. AI-generated infrastructure-as-code often defaults to permissive settings because restrictive defaults break things, and breaking things is a bad demo.

---

The Production Checklist for Vibe-Coded Apps

Go through this before you push anything to a real environment. It's not exhaustive — it's the minimum viable hardening for an AI-built app.

1. Repo structure and secrets management

Never commit secrets. Not even to a private repo. Set up your secret management before anything else:

• Use .env.example with placeholder values and add .env to .gitignore
• For AWS: use Parameter Store or Secrets Manager, not hardcoded env vars in task definitions
• For Vercel/Railway/Render: use their secrets UI, not the repo
• Audit your git history before making a repo public — git log and tools like trufflesecurity/trufflehog will find keys you forgot you committed

2. Container or serverless? Choose the right runtime

This decision affects cost, scaling behavior, and operational complexity more than almost anything else.

• Serverless (Lambda, Cloud Run, Vercel Functions): Right for event-driven workloads, unpredictable traffic, stateless APIs. Cold starts are real — don't use it for latency-sensitive paths.
• Container (ECS, Cloud Run, Kubernetes): Right for always-on services, apps with persistent connections (WebSockets, SSE), or anything that needs more than 15 minutes of execution.
• Managed runtimes (Railway, Render, Fly.io): Right for getting something running fast without thinking about clusters. Slightly more expensive at scale, much cheaper in engineering time.

The LLM probably wrote you a stateless Express or Next.js app. That runs fine on serverless or a small container. Start there.

3. IAM and least-privilege permissions

Tighten every IAM role before you deploy:

• Audit every permission your app needs — look at every AWS SDK call, every GCS client, every Azure resource access
• Scope S3 access to specific buckets and operations (s3:GetObject on arn:aws:s3:::mybucket/*, not s3:* on *)
• Use IAM Roles for service accounts (IRSA) in Kubernetes, not static credentials
• Rotate any credentials the LLM may have generated as placeholders
• Run aws iam get-account-authorization-details or equivalent to audit what's actually attached

4. Environment configuration (staging vs. prod)

Run two environments. This is non-negotiable for anything that touches real users or real money.

• Staging should match prod's architecture, not be a stripped-down version
• Use different AWS accounts, GCP projects, or at minimum different namespaces for isolation
• Configuration should be environment-specific: different database URLs, different API rate limits, different feature flags
• Never test database migrations on prod first. Run them on staging. Wait. Then run on prod.

5. Observability basics (logs, metrics, alerts)

You need three things before you go live: structured logs, a latency/error metric, and at least one alert.

• Add structured JSON logging to your app — use pino (Node), structlog (Python), or slog (Go)
• Ship logs to CloudWatch, Datadog, or Grafana Cloud — pick one and set it up before day one
• Set an alert on error rate > 5% and p99 latency > 2s — these catch 80% of production fires
• For Lambda: enable X-Ray tracing. For containers: add a health check endpoint and wire it to your load balancer

6. Cost guardrails

Set a budget alert before you deploy, not after your first month's bill.

• AWS: set a billing alert at $50, $100, and your actual threshold in AWS Budgets — takes 3 minutes
• Enable Cost Explorer and tag every resource with your project name
• For LLM API calls in your app: add rate limiting and set max token limits on every call
• DynamoDB: use provisioned capacity with auto-scaling, not on-demand, until you understand your traffic pattern
• S3: add lifecycle rules to delete or archive old objects — AI-generated apps almost never include these

7. Security scanning

Run a scanner on your code and your infrastructure before launch.

• Code: npm audit, pip-audit, or trivy fs . for dependency vulnerabilities
• Docker images: trivy image yourimage:tag — catches CVEs in base images
• IaC: checkov or tfsec on any Terraform/CloudFormation the LLM generated
• Secrets: trufflehog git file://./ before your first push to a public repo

8. DNS and TLS

Don't ship on a raw IP or with self-signed certificates.

• Use Cloudflare in front of everything — it gives you TLS, DDoS protection, and a CDN for free
• Use ACM (AWS Certificate Manager) for TLS on ALBs and CloudFront — it's free and auto-renews
• Set your DNS TTL low (60–300 seconds) before launch so you can move fast if something breaks
• Check that www and the apex domain both resolve and redirect correctly

9. Rollback strategy

Know how you're going to undo a bad deploy before you deploy.

• If you're on ECS or Kubernetes: keep the previous task definition or deployment spec and know the rollback command (aws ecs update-service --task-definition previous-arn or kubectl rollout undo)
• If you're on a managed platform (Render, Railway, Fly): know where the deploy history lives and how to repoint
• Database migrations: make them backward-compatible so a rollback doesn't break data. Add columns, don't rename them.
• Run at least one intentional rollback drill on staging before you're doing it at 2am under pressure

---

How Clanker Cloud Bridges the Gap

Here's the honest problem with the checklist above: you can read it, understand it, and still spend four hours trying to figure out what IAM roles your app actually needs, whether your security groups are misconfigured, and why your container won't start in ECS when it works fine on your laptop.

Clanker Cloud is built for exactly this moment. It's an AI workspace for infrastructure that works with your existing cloud credentials — nothing leaves your machine, no hosted SaaS layer touching your AWS account.

Here's what it actually does for vibe coders:

Query your infra in plain English. Before you deploy, ask: "What IAM roles are attached to my Lambda functions?" or "Show me all S3 buckets with public access." You get live answers from your actual account, not documentation.

Scan for misconfigs before they bite you. Autonomous security agents run against your infrastructure and surface the things that would otherwise become post-mortems: overly permissive security groups, missing encryption at rest, exposed endpoints, IAM wildcards.

Generate a reviewed deployment plan. Clanker Cloud reads your current state, understands what you're trying to deploy, and generates a plan you can inspect before anything happens. This is the read-first, act-second model — you see the diff before it's applied.

Execute only when you approve. Maker mode is explicit. Nothing in your infrastructure changes until you say so. For a vibe coder who's used to fast iteration, this is the right kind of friction — the kind that keeps you from accidentally deleting a production database.

It supports AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner, and DigitalOcean from one surface. You bring your own API keys (BYOK) — no token markup. Setup is under a minute: install the desktop app, connect your existing credentials, go.

Full documentation at docs.clankercloud.ai. If you want to see it in action first, check the live demo.

---

Real Workflow: Next.js App Built with Claude Code → Running on AWS

Let's make this concrete. You built a Next.js app using Claude Code over the weekend. It has a Postgres database, calls the OpenAI API, and has a few API routes. Here's how to go from repo to production.

Step 1: Audit the repo before touching any infra.

Run trufflehog git file://./ to make sure no API keys landed in commits. Check your .gitignore — confirm .env is in there. Run npm audit to catch any obvious dependency vulnerabilities. This takes 10 minutes and catches the most common first-day disasters.

Step 2: Set up secrets management.

Go to AWS Systems Manager Parameter Store. Add your OPENAI_API_KEY, your database URL, and any other secrets as SecureString parameters. Update your app to pull from Parameter Store using the AWS SDK or an environment variable injection at deploy time — not from a .env file on the server.

Step 3: Connect Clanker Cloud to your AWS account.

Install the desktop app, add your AWS credentials (they stay local). Ask: "What's running in my AWS account?" and get a live picture of what you're working with. If you have existing resources from previous projects, now's the time to understand what's there before you add more.

Step 4: Choose your runtime and containerize.

For a Next.js app, ECS Fargate is a solid choice — no cluster management, predictable pricing, supports the full Next.js feature set. Write a Dockerfile (or ask Claude Code to write one), build the image, push to ECR. Ask Clanker Cloud: "What IAM permissions does my ECS task need to read from Parameter Store and write to S3?" — it will tell you what to attach.

Step 5: Scan your IaC before applying.

If you wrote Terraform or CloudFormation (or asked Claude Code to), run it through checkov or ask Clanker Cloud to scan it for misconfigs. It will surface things like security groups open to 0.0.0.0/0, missing CloudTrail logging, or an RDS instance without encryption. Fix those before you apply.

Step 6: Set up your staging environment first.

Deploy to a staging environment — a separate AWS account or a separate ECS cluster with a staging prefix. Run your app. Test every route. Run a database migration on the staging database. Confirm it works.

Step 7: Generate and review your production deployment plan.

In Clanker Cloud, generate your production deployment plan. Review it — you'll see every resource being created, modified, or destroyed, with the expected impact. When you're satisfied, execute in maker mode.

Step 8: Wire up observability and DNS.

Before you share the URL: set up CloudWatch log groups for your ECS task, create a billing alert in AWS Budgets, and set a CloudWatch alarm on HTTPCode_Target_5XX_Count. Point your domain's nameservers to Cloudflare, add an A record to your load balancer, and enable "Full (strict)" SSL — TLS and DDoS protection in under five minutes. Now you'll know when something breaks before your users do.

Step 9: Ship it.

Post the link. The app is running, the secrets are managed, IAM is scoped correctly, you have observability, you have a rollback path. That's not a vibe — that's production.

---

Conclusion

Vibe coding got you to a working app faster than you could have imagined two years ago. The production gap is the last hurdle, and it's a solvable one — not with months of DevOps training, but with a focused checklist and the right tools.

The builders who are winning in 2026 aren't the ones who refuse to use AI. They're the ones who use AI for code generation and then apply the same intentionality to their infrastructure that they bring to their product decisions. Fast code, careful deployment.

Try Clanker Cloud free — install the desktop app, connect your existing cloud credentials, and see your infrastructure in plain English in under a minute. Or explore the open-source CLI if you want to start from the terminal.

You built something real. Now run it right.

---

FAQ

How do I deploy a vibe-coded app to production?

Start with a pre-deploy checklist: audit your repo for leaked secrets, set up secrets management (AWS Parameter Store, not .env files on servers), tighten IAM permissions to least-privilege, and choose a runtime appropriate for your app (ECS Fargate for always-on Next.js apps, Lambda for event-driven workloads). Set up observability — structured logs, at least one error rate alert — before you push to prod. Tools like Clanker Cloud can scan your infrastructure for misconfigs and generate a deployment plan you can review before anything executes.

Is vibe coding production ready?

The code that comes out of Cursor and Claude Code is often production-quality in terms of logic and functionality. What it lacks is operational hardening: secrets management, least-privilege IAM, observability, cost controls, and security configuration. These aren't things LLMs are bad at — they're things LLMs don't optimize for because they're not functional requirements. With the right checklist and tooling, vibe-coded apps absolutely ship to production. Thousands of them are running right now.

What are the best tools for deploying AI-generated code?

For infrastructure management and scanning: Clanker Cloud (queries your live infra, scans for misconfigs, generates reviewed deployment plans). For hosting: ECS Fargate, Railway, Render, or Fly.io depending on your complexity tolerance. For secrets: AWS Parameter Store or Secrets Manager. For security scanning: Trivy (containers and code), Checkov (IaC), TruffleHog (secrets in git history). For DNS and TLS: Cloudflare. For observability: CloudWatch (if you're already on AWS), Datadog, or Grafana Cloud.

What's the biggest mistake vibe coders make when going to production?

Skipping the IAM audit. Broad permissions (s3:*, iam:*) are the path of least resistance when you're generating infrastructure code, and they're fine for local development. In production, they're a misconfigured role away from a significant incident. The second biggest mistake is no observability — deploying an app with no logging or alerting means you find out something is broken when a user tells you, not when it starts breaking. Both of these are fixable in under an hour with the right setup.