From Lovable to Self-Hosted: Your Migration Playbook

Why You’re Here

You built your MVP on Lovable in days. It works. Users love it. Now you need to migrate to self-hosted infrastructure because:

• You need backend control Lovable doesn’t provide
• Your architecture is getting too complex for the platform
• You need custom integrations that aren’t supported
• You’re hitting scaling or workflow limitations

This guide shows you exactly what to do and in what order. No theory — just the practical steps to get from Lovable to a self-hosted production system you control.

The Migration Reality: Lovable vs Self-Hosted

Before diving into the playbook, understand what changes when you leave Lovable:

Category	Lovable	Self-Hosted
Deployment	Click deploy. Everything handled automatically.	You own containerization (Docker), infrastructure-as-code (Terraform), and orchestration (often Kubernetes). You control everything — and you’re responsible for everything.
Monitoring & Errors	Basic error tracking built-in.	You implement structured logging, application performance monitoring (APM), and error tracking with tools like Grafana + Loki or Datadog. You see exactly what’s happening inside your app when things break.
Security	Platform handles HTTPS, basic security configs.	You enforce HTTPS, implement authentication/authorization, manage secrets (AWS Secrets Manager or HashiCorp Vault), sanitize inputs, and protect against OWASP Top 10 vulnerabilities. Security becomes your discipline, not someone else’s default.
Database Management	Schema changes just work. Wipe and restart if needed.	Zero-downtime migrations with real user data. Every schema change must be backward-compatible. You need backup/recovery procedures that you’ve actually tested.
Infrastructure	Managed environment, limited customization.	You configure auto-scaling, load balancing, disaster recovery. You optimize costs by scaling up during traffic spikes and down during quiet periods.
AI Gateway	Built-in AI gateway handles LLM requests.	You implement your own gateway. For Elixir, use ReqLLM. For Ruby/Rails, use RubyLLM. Both provide structured LLM interactions with retry logic and error handling.

The tradeoff: Lovable is fast but limited. Self-hosted is powerful but requires infrastructure work you didn’t need before.

The Practical Migration Approach

Here’s the step-by-step sequence. Don’t skip steps — each builds on the previous.

Step 1: Choose Your Stack (Week 1)

Pick your framework first. Everything else flows from this decision.

Recommended frameworks:

Why these three? They all have clear “production stories” — mature deployment patterns, strong community support, and real-world examples of scaling. Avoid frameworks without proven production deployments at scale.

Step 2: Set Up Core Infrastructure (Week 1-2)

What you’re building: The foundation that lets you deploy reliably.

Actions:

• Containerize your app — Write a Dockerfile that packages your application with all dependencies. This ensures “works on my machine” becomes “works everywhere.”
• Set up GitHub Actions — Create a CI/CD pipeline that automatically runs tests and deploys when you push to main. Start simple: run tests on every pull request, deploy to production on merge to main.
• Choose a cloud provider — AWS (most mature, most complex), GCP (best for data/AI workloads), or Azure (best if you’re Microsoft-heavy). For most founders: start with AWS or GCP. Deploy using managed services (AWS ECS, Google Cloud Run) before jumping to Kubernetes.
• Implement infrastructure-as-code — Use Terraform to define your infrastructure in code. This means you can rebuild your entire stack reliably when (not if) something breaks at 3am.

Deliverable: You can push code to GitHub and have it automatically deployed to production.

Step 3: Implement Observability (Week 2)

What you’re building: The ability to see what’s happening inside your production app.

Actions:

• Structured logging — Replace console.log with structured logs (JSON format) that include timestamps, severity levels, request IDs, and context. Use Loki or CloudWatch.
• Error tracking — Implement error monitoring with Sentry or Rollbar. You need to know when things break, with full stack traces and user context.
• Basic APM — Set up application performance monitoring. For Phoenix: use PromEx + Grafana. For Rails: New Relic or Datadog. For Next.js: Vercel Analytics or Datadog.

Why this matters: On Lovable, you click around and see errors. Self-hosted, you need these tools to know what’s broken and where.

Deliverable: When your app crashes in production, you receive an alert with enough context to fix it.

Step 4: Lock Down Security (Week 2-3)

What you’re building: Protection against common vulnerabilities.

Actions:

• Review AI-generated code — If you used Lovable or Cursor to generate code, manually review authentication, authorization, database queries, and user input handling. AI-generated code prioritizes speed over security.
• Implement secrets management — Move all API keys, database credentials, and secrets out of .env files and into AWS Secrets Manager, HashiCorp Vault, or your cloud provider’s equivalent.
• Input sanitization — Ensure all user inputs are validated and sanitized on the server side to prevent injection attacks.
• Enforce HTTPS — Configure SSL/TLS certificates (use Let’s Encrypt for free certs). No production app should serve over HTTP.
• Check OWASP Top 10 — Review the OWASP Top 10 security vulnerabilities list and ensure your app isn’t vulnerable to the most common attacks (broken access control, security misconfiguration, injection flaws).

Deliverable: You’ve addressed the security basics. You’re not Fort Knox, but you’re not leaving the door unlocked.

Step 5: Set Up Database Management (Week 3-4)

What you’re building: Safe, zero-downtime database changes.

Actions:

• Implement migration workflow — Use your framework’s migration tools (Rails: Active Record Migrations, Phoenix: Ecto Migrations). Every schema change must be a versioned migration file.
• Backward-compatible migrations — Learn the expand-contract pattern: when adding a column, make it nullable first. When removing a column, deprecate it for one release before dropping. Your migrations must work while old code is still running.
• Set up automated backups — Configure daily database backups to separate storage (AWS RDS automated backups, or pg_dump to S3). Set retention policies (keep 30 days minimum).
• Test recovery procedures — Actually restore from a backup to a test environment. If you’ve never tested recovery, you don’t have backups — you have hopes.

Why this matters: On Lovable, you can wipe the database and start over. With real users and real data, every database change must preserve existing data and work with running code.

Deliverable: You can safely change your database schema without downtime or data loss.

Step 6: Implement the AI Gateway (Week 4)

What you’re building: Your own LLM request handling.

If your app uses AI features, you need to replace Lovable’s AI gateway.

For Elixir/Phoenix: Use ReqLLM — A Req plugin for interacting with LLM APIs. Provides structured request/response handling, retry logic, and error handling. Integrates cleanly with Phoenix applications.

For Ruby/Rails: Use RubyLLM — Purpose-built for Rails applications. Handles API interactions with OpenAI, Anthropic, and other LLM providers. Includes retry logic, rate limiting, and cost tracking.

For JavaScript/Node.js: Use Vercel AI SDK or LangChain.js — Both provide structured LLM interactions with streaming support, tool use, and provider abstraction.

Implementation priority: If AI is core to your product, tackle this in Week 2-3. If it’s supplementary, push to Week 5-6.

Deliverable: Your app makes LLM requests through your own gateway, not Lovable’s.

Step 7: Set Up Scaling & Cost Management (Week 5+)

What you’re building: Infrastructure that scales with demand without wasting money.

Actions:

• Configure auto-scaling — Set up policies that automatically add servers when CPU or memory exceeds thresholds (usually 70-80%), and remove servers when demand drops.
• Implement load balancing — Distribute traffic across multiple instances. AWS: Application Load Balancer. GCP: Cloud Load Balancing.
• Set up cost monitoring — Use cloud provider cost dashboards to track spending. Set up alerts when costs spike unexpectedly.

Why this comes last: Don’t optimize for scale before you have scale. Get the app working reliably first, then optimize for traffic patterns you can measure.

Deliverable: Your infrastructure automatically handles traffic spikes without manual intervention.

What’s Critical vs What Can Wait

Must-have before launch (Week 1-4):

• Core infrastructure and deployment (Step 1-2)
• Basic observability — at minimum, error tracking (Step 3)
• Security fundamentals: HTTPS, secrets management, input sanitization (Step 4)
• Database backups with tested recovery (Step 5)

Can wait until after launch (Week 5+):

• Advanced APM and distributed tracing
• Multi-region deployment and sophisticated disaster recovery
• Auto-scaling (unless you have proven traffic patterns that demand it)
• Infrastructure-as-code can start simple and expand as needs grow

The critical insight: You can launch self-hosted without perfection. Get security and reliability right. Everything else can be added incrementally as you grow.

Framework-Specific Resources

Resource	Rails	Phoenix	Next.js
Deployment	Kamal for containerized deployments	Fly.io for global edge deployment, or Docker + AWS ECS	Vercel (managed) or Docker + Cloud Run (self-hosted)
Monitoring	Honeybadger (error tracking), Scout APM (performance)	PromEx + Grafana stack, or AppSignal	Vercel Analytics, Sentry for errors
Database	Active Record Migrations with Strong Migrations gem	Ecto Migrations (zero-downtime aware)	Prisma for migrations, or raw SQL with migration tools
AI Gateway	RubyLLM	ReqLLM	Vercel AI SDK
Scaling	Standard horizontal scaling with load balancers	BEAM clustering handles distribution naturally	Serverless scaling (Vercel) or container orchestration

Your Timeline

Realistic migration timeline for a single full-stack developer:

• Week 1-2: Framework choice + core infrastructure setup
• Week 2-3: Observability + security lockdown
• Week 3-4: Database management + AI gateway
• Week 5+: Scaling and optimization

Total: 4-6 weeks to production-ready self-hosted infrastructure.

If you have a team, you can parallelize: one person on infrastructure, one on security review, one on database setup. That can compress the timeline to 2-3 weeks.

Next Steps

1. Audit your current Lovable app — What features do you use? What integrations matter? What data exists?
2. Choose your framework (Rails, Phoenix, or Next.js)
3. Set up a test environment — Don’t migrate directly to production. Build your self-hosted stack alongside Lovable first.
4. Follow the 7-step sequence above — Don’t skip steps. Each builds on the previous.
5. Plan your cutover — Once self-hosted is working, plan the final migration: DNS switch, data export/import, user communication.

You built your MVP in days. Migration to self-hosted will take 4-6 weeks. That’s not a failure — that’s the cost of control, flexibility, and eliminating platform limitations.

Now you know what to do, in what order, and why. Time to start.