# Migrate a web application to Quake AI Source: https://docs.quake.ai/docs/platform/migration/migrate-web-applications-to-quake-ai Markdown: https://docs.quake.ai/docs/platform/migration/migrate-web-applications-to-quake-ai.md > Move an existing web application from a VPS, Heroku, or hyperscaler VM to Quake AI behind a self-managed edge reverse proxy. --- # Migrate a web application to Quake AI In this migration guide, you move an existing web application to Quake AI. You stand up an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) in front of application VMs, sync application data and uploads from the source, and cut over DNS with a rollback path. Quake AI has **no managed database** and **no native CDN** for your app tier. You operate the database and cache layers on Compute or Block Storage. Static acceleration requires a third-party CDN in front of the origin if you need edge caching. **What you will migrate:** a web app or HTTP API on a DigitalOcean Droplet, AWS EC2, Heroku dyno, or another provider VM. **What you will learn:** - How to stand up an edge reverse proxy as the migration target with **one floating IP** - How to sequence [Migrate from Droplets](/docs/compute/migration/migrate-from-droplets) or [Migrate from EC2](/docs/compute/migration/migrate-from-ec2) for your source - How to sync uploads with [Migrate from S3](/docs/object/migration/migrate-from-s3) - How to cut over DNS with blue/green staging and rollback **Time estimate:** 45 minutes (excluding database and upload sync time)
```d2 direction: right source: Source web app\n(Droplet / EC2 / Heroku) target: Edge reverse proxy\n+ app backends compute: Compute migration\npage s3: Migrate from S3 dns: DNS cutover\n+ rollback source -> compute -> target source -> s3 -> target target -> dns ```
## Prerequisites Before you start, confirm you have: - SSH or export access to the source application and database - OpenTofu installed locally and [application credentials](/docs/platform/access/generate-app-credentials) for Quake AI - Enough quota for the application instances, one edge-proxy instance, and **one floating IP** - The concept-translation page for your source: [Coming from AWS](/docs/platform/migration/coming-from-aws), [Coming from DigitalOcean](/docs/platform/migration/coming-from-digitalocean), [Coming from Azure](/docs/platform/migration/coming-from-azure), or [Coming from GCP](/docs/platform/migration/coming-from-gcp) Skim [Deploy the edge reverse proxy template with OpenTofu](/build/deployments/deploy-edge-reverse-proxy-template) if you have not applied that template before. ## Step 1: Map the source provider Note the source VM size, attached volumes, object bucket for uploads, production hostname, and TLS certificate issuer. Map firewall rules and VPC layout using your provider concept-translation page. ## Step 2: Stand up the target stack 1. Download the [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) template and the application template that matches your stack, such as [full-stack app](/build/iac-templates/full-stack-app). 2. Set the domain, backend address, key name, and sizing in `terraform.tfvars`. 3. Run `tofu apply` and record the edge proxy floating IP. The edge proxy allocates **one floating IP** and runs Caddy for automatic HTTPS. Keep application and database backends on private addresses. ## Step 3: Move compute workloads - **DigitalOcean Droplets:** follow [Migrate from Droplets](/docs/compute/migration/migrate-from-droplets). - **AWS EC2 or other hyperscaler VMs:** follow [Migrate from EC2](/docs/compute/migration/migrate-from-ec2). Those pages cover image export, cloud-init, and SSH mechanics. Deploy your application code and environment variables on the target instances after the base OS is ready. ## Step 4: Move application data and uploads Dump and restore the application database onto instances or volumes in the target stack. Validate row counts and migration scripts on a staging hostname first. Sync user uploads and static assets with [Migrate from S3](/docs/object/migration/migrate-from-s3). Update application config to read from the new bucket endpoint. ## Step 5: Recreate network rules Translate VPCs or Droplet firewalls with [Migrate from DigitalOcean VPC](/docs/network/migration/migrate-from-do-vpc) or [Migrate from AWS VPC](/docs/network/migration/migrate-from-aws-vpc) as appropriate. Confirm the edge proxy can reach each application backend and that application health checks pass. ## Step 6: Cut over DNS and traffic 1. Configure the production domain on Caddy and verify automatic certificate issuance. 2. Add the target application backend to the edge proxy and verify its health endpoint. 3. Lower DNS TTL in advance, then point the production hostname at the Quake AI floating IP. **Rollback:** revert DNS to the source origin if health checks fail or error rates spike. Keep the source VM running until the target stabilizes. **Session continuity:** plan for one-time re-login if session cookies bind to the old hostname. ## Step 7: Verify the migrated web application - Load primary routes and API health endpoints on the production hostname. - Confirm upload URLs and signed links work against the new Object Storage bucket. - Verify responses from each configured backend if you route to multiple application instances. ## Step 8: Clean up migration scaffolding Remove temporary sync hosts and delete source volumes only after verification holds. ## What you migrated You moved a web application to Quake AI behind an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy), composed compute and object migration pages for data movement, and cut over DNS with rollback. Return to the [Web applications and APIs](/build/solutions/web-applications) solutions leaf for the workload-shaped migration overview.