Web applications and APIs

Deploy a web application or HTTP API on Quake AI VMs or Kubernetes clusters. You operate the application runtime, session layer, TLS, and data stores; Quake AI provides compute, networking, block and object storage, floating IPs, and optional self-managed Kubernetes.

What this is for#

Teams shipping a web app or HTTP API need a public tier that terminates TLS, routes traffic to app servers, holds application state, and keeps monthly cost predictable. Quake AI runs the compute, network, and storage layers; you own the runtime, reverse proxy or gateway, certificates, and deployment pipeline. The outcome is a public web stack with flat egress and plan-based compute pricing, deployable from a validated OpenTofu template and its companion deployment guide.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The web application is five architecture decisions. Each maps to a tier in the diagram and to the template or how-to that builds it.

1. Web and API clients. Browsers and API consumers reach the application over HTTPS. A third-party CDN in front of the origin is optional for static assets and cached responses.

2. Third-party CDN. A CDN such as Cloudflare, Fastly, or Akamai caches static assets and absorbs burst traffic. Point cache misses at the floating IP on your reverse proxy, WAF, or API gateway.

3. Edge reverse proxy with TLS. The edge reverse proxy runs Caddy on a dedicated VM with a floating IP. Caddy obtains and renews certificates for your application domain, terminates TLS, and forwards requests to app instances on private networks. Use the edge WAF when you need request filtering, or the API gateway for API routing and rate limits.

4. App runtime. Run the application on Compute VMs or a self-managed Kubernetes cluster (Magnum). The full-stack app, Next.js app, and three-tier app templates cover common VM layouts; Magnum fits teams that deploy with Helm or GitOps.

5. Application state and value-add variations. Keep relational data in self-managed Postgres on Block Storage. Add a Valkey cache in front of the app tier for sessions and hot reads. Serve user uploads, exports, and static assets from S3-compatible Object Storage when the app stores durable files.

The edge and gateway templates provision dedicated perimeter VMs on floating IPs. Deploy an edge reverse proxy, WAF, API gateway, or tunnel gateway based on the controls your application needs. Add a third-party CDN for geographic edge delivery.

Services involved#

Get started#

Each template below pairs with a step-by-step deploy tutorial. Start from the template that matches how you run the app, then follow its tutorial to stand it up.

• Edge reverse proxy (deploy walkthrough): Caddy with automatic TLS on a floating IP in front of a private backend
• Edge WAF (deploy walkthrough): SafeLine L7 filtering on a dedicated perimeter VM
• API gateway (deploy walkthrough): APISIX routing, rate limits, and auth plugins in front of private APIs
• Edge tunnel gateway (deploy walkthrough): Pangolin tunnel endpoint for private or home-lab origins
• Full-stack app template and its deploy tutorial: single-stack pattern with app server, database, and networking for compact apps.
• Next.js app template and its deploy walkthrough: container-based Next.js runtime on a single VM, served over HTTPS and connected to a Postgres database.
• Three-tier app template and its deploy tutorial: separate web, application, and database tiers for larger traffic.
• Self-managed PostgreSQL template and its deploy tutorial: stand up the database tier on Block Storage.
• OpenTofu template library: browse validated IaC starting points for the layouts above.

Estimate the cost#

Migrating an existing web application?#

Move a web app or HTTP API that already runs on a DigitalOcean Droplet, AWS EC2, Heroku, or another provider's VM fleet. The outcome is the same application on Quake AI compute behind a self-managed edge VM, with uploads, configuration, and traffic cut over in a controlled order.

Follow this cutover path. Each step links an existing migration page; this section composes those pages into a workload-shaped sequence rather than duplicating their steps.

1. Map your source provider. Start with the concept-translation page for your current cloud: Coming from AWS, Coming from Azure, Coming from GCP, Coming from DigitalOcean, or Coming from Hetzner.

2. Stand up the target shape on Quake AI. Pick the template that matches how you run the app after migration: edge reverse proxy for automatic HTTPS in front of private backends, full-stack app for a compact VM layout, or three-tier app for separate web, application, and database tiers.

3. Move compute workloads. For DigitalOcean Droplets, follow Migrate from Droplets. For AWS EC2 or other hyperscaler VMs, follow Migrate from EC2.

4. Move object and file data. Sync user uploads, static assets, and media with Migrate from S3.

5. Recreate network topology and security rules. Translate VPCs, subnets, and firewall rules with Migrate from DigitalOcean VPC (or the matching network migration page for your source provider).

6. Cut over traffic. Add the target backends to your reverse proxy or API gateway, verify health endpoints, then switch DNS to its floating IP. Shift traffic at the CDN or DNS layer when you need a gradual rollout.

Workload-specific cutover callouts#

• Application data and uploads. Export the application database and sync file uploads or object-storage buckets before you point production DNS at Quake AI. Validate row counts, media URLs, and signed-link behavior on the target stack.
• Edge routing and TLS. Configure your production hostname on Caddy, SafeLine, or APISIX and verify certificate issuance before you lower DNS TTL. Confirm each backend passes its application health check.
• DNS switch and rollback. Lower TTL on the production hostname several days before cutover. Keep the source stack warm until error rates stabilize. Roll back by pointing DNS at the old origin if health checks or error budgets fail.
• Session continuity. Active browser sessions may not survive a DNS switch. Shorten session TTL before cutover or accept a one-time re-login window.

For a hands-on walkthrough of this vertical, follow Migrate a web application to Quake AI.

Considerations and limits#

• You operate the runtime. Quake AI provides the compute, network, and storage primitives; the application server, framework, and process management are your responsibility under the shared responsibility model.
• No managed database or CDN. Databases, cache layers, and search indexes run on Compute or Block Storage you operate. Static acceleration requires a third-party CDN in front of the origin.
• Flat egress. Quake AI applies a no-egress-fee policy for outbound transfer, which helps applications that serve large media or API payloads.
• Three US regions. All current regions are in the United States. A globally distributed application needs CDN coverage and, if required, additional origin regions outside Quake AI today.
• CPU-only compute. Application runtimes are CPU-bound; Quake AI flavors are AMD EPYC with no GPU option (compute FAQ).
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. Where a workload requires HIPAA, PCI-DSS, FedRAMP, or ISO 27001, check the platform scope in Compliance and certifications.