SaaS and B2B applications

Host a multi-tenant SaaS or B2B application on Quake AI. You operate the application tier, tenant isolation model, edge proxy, TLS, and data stores; Quake AI provides compute, networking, block and object storage, floating IPs, and optional self-managed Kubernetes.

What this is for#

Mid-market SaaS teams and B2B product builders need an application tier that serves tenants, holds per-tenant state, and keeps monthly infrastructure cost predictable. Quake AI provides the compute, network, and storage layers; you own the application, tenant isolation model, edge routing, certificates, and deployment pipeline. The outcome is a multi-tenant stack with flat egress and plan-based compute pricing, deployable from validated OpenTofu templates.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The SaaS stack is the three-tier app template plus two value-add variations. Each tier maps to the diagram and to the template or how-to that builds it.

1. SaaS tenants. Browser users and API clients reach the application over HTTPS. A third-party CDN in front of the origin is optional for marketing pages and static assets.

2. Third-party CDN. A CDN such as Cloudflare, Fastly, or Akamai caches static assets and absorbs burst traffic. Quake AI has no native CDN product, so you bring the provider and point cache misses at the web tier's public address.

3. Web tier. The three-tier app template web VM serves the public API and UI. Place an edge reverse proxy in front when you want a dedicated TLS endpoint, or use the edge WAF or API gateway for filtering and API controls.

4. App tier. The application VM authenticates tenants, enforces isolation, and reads and writes tenant state. The three-tier app template separates this tier from the web and database tiers; teams that deploy with Helm or GitOps run it on a Kubernetes cluster instead.

5. Postgres tier. Relational tenant data lives in self-managed Postgres on Block Storage, the database VM of the three-tier app template. The self-managed PostgreSQL template covers the same tier as a standalone stack.

6. Value-add variations. The monitoring variation adds a monitoring stack (Prometheus and Grafana) for tenant-facing service health, and the cache variation adds a Valkey cache in front of the app tier for sessions and hot reads. Serve tenant uploads, exports, and attachments from S3-compatible Object Storage when the application stores durable files.

Alternative front door. When the web or API tier stays private behind dedicated perimeter VMs, the Edge & gateways templates each provision one appliance on a floating IP: edge reverse proxy (Caddy with automatic HTTPS), edge WAF (SafeLine L7 filtering), API gateway (APISIX routing, rate limits, and tenant-aware plugins), or edge tunnel gateway (Pangolin for operator or staging access without public app ports). Deploy walkthroughs: reverse proxy, WAF, API gateway, tunnel. Add Front with a CDN for geographic edge; perimeter VMs terminate TLS in the Quake AI region you operate.

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 for tenant-facing APIs
• Edge tunnel gateway (deploy walkthrough): Pangolin tunnel endpoint for private admin or staging access
• Full-stack app template and its deploy tutorial: single-stack OpenTofu pattern with app server, database, and networking for early SaaS prototypes.
• Three-tier app template and its deploy tutorial: separate web, application, and database tiers for larger tenant counts.
• Kubernetes cluster template and its deploy tutorial: self-managed cluster for teams that deploy with Helm or GitOps.
• Self-managed PostgreSQL template and its deploy tutorial: Postgres on Block Storage for tenant data.
• Monitoring stack template and its deploy tutorial: stand up monitoring to watch tenant-facing services.
• OpenTofu template library: browse validated IaC starting points for the layouts above.

Estimate the cost#

Migrating an existing B2B SaaS application?#

Move a SaaS product that already runs on Amazon EKS or ECS, Azure AKS, Google GKE, Heroku, or VM fleets at another cloud. The outcome is the same multi-tenant application on Quake AI compute or a self-managed Kubernetes cluster, with tenant data, secrets, 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 greenfield template that matches how you run the app after migration: Full-stack app for a compact VM stack, Three-tier app when web, app, and database tiers stay separate, or Kubernetes cluster when you deploy with manifests or Helm.

3. Move compute workloads. For VM-based tenants or nodes, follow Migrate from EC2. For Kubernetes-hosted services, follow Migrate from EKS.

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

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

6. Cut over traffic. Add the target backends to your edge proxy or API gateway, verify tenant logins and health endpoints, then switch DNS to its floating IP. Use CDN or DNS weights when you need a gradual rollout.

Workload-specific cutover callouts#

• Tenant data migration. Plan per-tenant or shared-schema database moves (dump and restore, logical replication, or batch ETL) before you point production DNS at Quake AI. Validate row counts and tenant isolation rules on the target Postgres or application database.
• Secrets and configuration. Export environment variables, API keys, and OAuth client settings from the source platform. Load them into Quake AI through your deployment tool (OpenTofu variables, Kubernetes Secrets, or a vault you operate). Rotate credentials that cannot move verbatim.
• Session continuity. Active browser sessions may not survive a DNS switch. Shorten session TTL before cutover or accept a one-time re-login window; document the window for customers if your SLA requires it.
• 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.

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

Considerations and limits#

• Multi-tenant isolation is yours to design. Quake AI provides the compute, network, and storage primitives; tenant separation (shared-schema, schema-per-tenant, or database-per-tenant) and the authorization model are your application's responsibility under the shared responsibility model.
• Compliance posture. Quake AI holds SOC 2 Type I and Type II attestations and SOC 3. Where a tenant contract requires HIPAA, PCI-DSS, FedRAMP, or ISO 27001, state the gap and check the platform scope in Compliance and certifications.
• No managed database or CDN. Postgres, 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 SaaS workloads that serve large exports or media to tenants.
• 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).