Migrate a web application to Quake AI
Coming from another cloud?
▸AWS·Amazon EC2
This Quake AI feature maps to AWS’s Amazon EC2.
▸DigitalOcean·Droplet
This Quake AI feature maps to DigitalOcean’s Droplet.
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 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 or Migrate from EC2 for your source
- How to sync uploads with Migrate from S3
- How to cut over DNS with blue/green staging and rollback
Time estimate: 45 minutes (excluding database and upload sync time)
Prerequisites#
Before you start, confirm you have:
- SSH or export access to the source application and database
- OpenTofu installed locally and application 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, Coming from DigitalOcean, Coming from Azure, or Coming from GCP
Skim Deploy the edge reverse proxy template with OpenTofu 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#
- Download the edge reverse proxy template and the application template that matches your stack, such as full-stack app.
- Set the domain, backend address, key name, and sizing in
terraform.tfvars. - Run
tofu applyand 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.
- AWS EC2 or other hyperscaler VMs: follow 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. 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 or 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#
- Configure the production domain on Caddy and verify automatic certificate issuance.
- Add the target application backend to the edge proxy and verify its health endpoint.
- 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, composed compute and object migration pages for data movement, and cut over DNS with rollback.
Return to the Web applications and APIs solutions leaf for the workload-shaped migration overview.
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.
Last validated: 08.09.2026