This post covers how to take an application built with vibe coding tools (Lovable, Bolt, or similar AI builders that typically deploy on Supabase and Netlify/Vercel) and migrate it into AWS with the processes, controls, and architecture that the Well-Architected Framework demands.
If you have already outgrown Heroku specifically, our Heroku to AWS migration guide covers that path in detail. This post addresses a different starting point: AI-generated code that was never designed with operational maturity in mind.
What vibe coding actually produces
The term “vibe coding”, coined by Andrej Karpathy in early 2025, describes a workflow where you describe what you want in natural language and an AI generates the application. Tools like Lovable, Bolt, and v0 have turned this into a product category. You prompt, the AI scaffolds a React or Next.js frontend, connects it to Supabase for auth, database, and storage, and deploys to Netlify or Vercel. In under a day you have a working application with users signing up.
The output is genuinely impressive for validation. The typical stack looks like this:
This is a perfectly valid architecture for a prototype or an MVP with limited traffic. The problem emerges when the product works, users arrive, and you need to operate it seriously.
Where vibe coded apps fall short
The gap is not in the application code. It is in everything the AI did not generate because you did not ask for it, and because the platforms abstract it away.
No environment separation. Most vibe coded apps run on a single Supabase project. There is no staging environment, no isolated dev database, no way to test database migrations without risking production data. The AI generates RLS policies, but there is no process to review or test them before they hit live users.
No infrastructure as code. The Supabase project was created through a dashboard. The Vercel deployment was connected via a UI. Nothing is reproducible. If you need to rebuild the environment (disaster recovery, compliance audit, new region) you are clicking through dashboards and hoping you remember the configuration.
No CI/CD beyond deploy-on-push. Vercel and Netlify deploy on every push to main. That is it. There is no test stage, no security scanning, no approval gate, no canary deployment. Every commit goes straight to production. For a prototype, that is speed. For a product with paying users, that is risk.
No monitoring or alerting. Supabase provides basic dashboards. Vercel shows function invocations. But there is no structured logging, no distributed tracing, no alerting on error rate spikes or latency degradation. When something breaks at 2am, you find out from a customer complaint on Twitter.
No security boundaries. The Supabase service key (full database access) is often exposed in environment variables with no rotation policy. There is no WAF, no network isolation, no principle of least privilege applied to service-to-service communication. The AI generated RLS policies, but nobody reviewed whether they actually prevent data leakage across tenants.
No backup and recovery strategy. Supabase Cloud runs daily backups, but point-in-time recovery is only available on Pro plans, and testing a restore is a manual process. There is no documented RTO/RPO, no tested recovery procedure, no multi-region failover.
No cost control. Supabase and Vercel charge based on usage. When traffic spikes (which is the goal) costs spike unpredictably. There is no reserved capacity, no budget alerts, no way to right-size resources because you do not control the infrastructure layer.
The migration path: from managed platforms to AWS
The goal is not to rewrite the application. The code Lovable generated works. The goal is to wrap it in the infrastructure, processes, and operational practices that turn a prototype into a production system. We frame every migration against the AWS Well-Architected Framework because it is not an academic checklist. It is the minimum bar for running software reliably at scale.
Here is how the typical vibe-coded stack maps to AWS:
Applying the Well-Architected Framework
Each pillar addresses a specific gap that vibe coded apps inherit from their platform dependencies:
Building the DevOps layer that vibe coding skipped
Our AWS-validated expertise with modern DevOps workflows tells us what a mature delivery pipeline should look like. Vibe coded apps have none of it. Not because the tools are bad, but because the platforms deliberately hide this layer to reduce friction. When you move to AWS, you get to build it properly.
CI/CD pipeline design
On Lovable/Vercel, the deployment model is: push to main → deploy to production. No gates, no tests, no approval. The AWS equivalent is not just a pipeline. It is a quality and security gateway.
A production-grade pipeline for a migrated vibe coded app typically looks like this:
2. Build stage: Application is containerised (Docker build), dependencies are locked, build artefacts are versioned.
3. Test stage: Unit tests, integration tests against a transient test database, contract tests for API boundaries.
4. Security stage: SAST scanning (Semgrep or SonarQube), dependency vulnerability check (Trivy, Snyk), container image scan before pushing to ECR.
5. Deploy to staging: Automatic deployment to a staging environment that mirrors production. Smoke tests run against staging.
6. Approval gate: Manual or automated approval before production deployment. For teams that need it, this is where QA signs off.
7. Deploy to production: Rolling update via ECS with health check validation. Automatic rollback if the new version fails health checks.
8. Post-deploy validation: Synthetic monitoring confirms critical user paths still work. Alerts fire if error rates spike within the first 15 minutes.
We build this in GitHub Actions with OIDC federation to AWS. No long-lived access keys, no shared secrets. Each environment (dev, staging, production) lives in its own AWS account for blast radius isolation.
Preview environments (replacing Vercel’s preview deploys)
One thing teams love about Vercel: every PR gets a live preview URL. This is non-negotiable for most teams migrating away. On AWS, you build this yourself, but the result is more powerful.
The pattern: a GitHub Actions workflow triggers on PR open/update. It spins up a short-lived ECS service (or a dedicated CloudFront distribution pointing to an S3 bucket for static apps) with a unique subdomain. The preview environment connects to a dedicated database schema or a branch-specific Supabase project if you are keeping Supabase for development velocity. When the PR is merged or closed, another workflow tears the environment down.
This takes effort to build initially, but once it is in place the developer experience matches or exceeds what Vercel provided, with the addition of running against real AWS infrastructure rather than a platform abstraction.
Infrastructure as Code
Every resource the application depends on (VPC, subnets, security groups, RDS instance, ECS cluster, load balancers, CloudFront distributions, IAM roles, secrets) is defined in Terraform or Terragrunt. Nothing is created through the AWS console.
This gives you:
- Reproducibility: Spin up a complete copy of the environment in minutes for disaster recovery or regional expansion
- Auditability: Every infrastructure change goes through a pull request with peer review
- Drift detection: Automated checks catch when someone modifies resources outside of code
- Compliance evidence: Auditors can review your infrastructure configuration as code rather than clicking through consoles
For teams coming from the vibe coding world, this is the single biggest operational upgrade. Your infrastructure stops being a mystery and becomes a versioned, documented, reviewable artefact.
Monitoring and observability
Vibe coded apps typically have zero observability. You find out something is broken when a user tells you. On AWS, you build observability in from day one:
- Structured logging: Application logs shipped to CloudWatch Logs or a third-party platform (Datadog, Grafana Cloud) with consistent formats and correlation IDs
- Metrics: CloudWatch or Prometheus for request latency, error rates, database connection pool utilisation, queue depths
- Alerting: PagerDuty or Opsgenie integration with tiered severity levels. Critical alerts wake someone up. Warnings create tickets.
- Dashboards: Service-level dashboards showing the four golden signals (latency, traffic, errors, saturation) at a glance
- Distributed tracing: X-Ray or OpenTelemetry for tracing requests across services, essential when your monolith starts splitting into microservices
The migration process in practice
The actual migration follows a phased approach. We do not recommend a big-bang cutover for vibe coded apps because there is usually undocumented behaviour that only surfaces under real traffic.
Total timeline for a typical vibe coded application: 5-8 weeks. More complex setups with multiple services or compliance requirements extend this to 8-12 weeks.
When to stay on Lovable/Supabase Cloud
Not every vibe coded app needs to migrate. The platforms are a good fit when:
- You are still validating product-market fit and shipping speed matters more than operational maturity
- Traffic is low and predictable (hundreds, not thousands, of concurrent users)
- You have no compliance requirements (SOC 2, ISO 27001, Cyber Essentials Plus, HIPAA)
- Your team is small and does not have the capacity to manage infrastructure
- The application is internal-facing or non-critical
The migration makes sense when any of these become true:
- You have paying customers who expect uptime commitments you cannot guarantee on a shared platform
- You need network isolation, private subnets, or VPN connectivity to partner systems
- Compliance or regulatory requirements demand infrastructure controls the platforms cannot provide
- Costs are growing unpredictably and you need capacity planning and reserved pricing
- You need a proper CI/CD pipeline with security scanning, testing gates, and controlled deployments
- You want to own your infrastructure as a business asset, defined and versioned in code
Vibe coding is not the problem
To be clear: we are not against vibe coding. Tools like Lovable and Bolt are genuinely impressive for what they do, getting from idea to working software in hours rather than weeks. The AI-generated code is often clean, well-structured, and functional. The issue is not code quality.
The issue is that going from “it works” to “it is production-ready” requires a layer of engineering that no AI builder provides today: infrastructure ownership, deployment automation, security controls, observability, disaster recovery, and cost governance. That layer is what turns a side project into a business.
The vibe coded prototype is your starting point, not your technical debt. Treat the generated code as a validated specification of what the product should do, then build the operational foundation it needs to run reliably at scale.
Built something with Lovable or Bolt that's ready to scale?
Book a free 30-minute call to discuss your setup and get a migration roadmap.
How we can help
We have migrated applications from Heroku, DigitalOcean, Vercel, and Supabase Cloud to AWS. Every migration is delivered with infrastructure as code, automated CI/CD, monitoring, and documented runbooks. The target architecture is designed against the AWS Well-Architected Framework, ensuring your new environment meets best practices for security, reliability, performance, and cost from day one.
As an AWS Advanced Tier Partner, we have access to funding programmes that can offset a significant portion of migration costs. Depending on your scale and situation, programmes like the Proof of Concept (PoC) or Migration Acceleration Program (MAP) can cover 50-80% of the engagement cost. We assess eligibility as part of the initial scoping conversation.
See our Heroku to AWS migration case study for a detailed example of how we approach platform migrations. Ready to evaluate whether migration makes sense for your vibe coded app? Our cloud migration services start with a no-commitment assessment of your current setup.
