Self-hosted vibecode stack

The modern vibecode stack is assembled from a sprawl of managed services, each separately metered: hosting on one vendor, Postgres on another, Redis on a third, then vector search, inference, auth, object storage, queues, and observability, each with its own meter and invoice. This page maps each of those categories to a self-host path on Quake AI, so you can run the stack on Compute you operate.

What this is for#

Teams that have watched a vibecode project accumulate a dozen separately billed SaaS dependencies can consolidate those dependencies onto one stack they own. Each category below has a validated OpenTofu template and a deployment walkthrough that stands up the self-hosted equivalent on Quake AI Compute.

The mechanism this addresses is fragmentation. A typical vibecode stack runs:

• A separate bill, dashboard, and contract for each vendor, reconciled at different times.
• Independent scaling cliffs, where each vendor moves from free tier to paid and paid to "contact sales" on its own curve.
• Metered data movement between layers, because traffic between the hosting tier, the database, the cache, and the inference provider crosses billed egress boundaries on every hop.

Running the stack on Quake AI puts those layers on one provider you operate, with no metered outbound transfer. You take on operating the services yourself in exchange for one bill and flat egress between layers. The trade-off is real: you run, patch, back up, and scale each service under the shared responsibility model.

Reference architecture#

Download diagram: SVG, PNG, and PDF.

The stack groups into six layers, each assembled from templates you can deploy independently:

• App runtime runs the long-lived application and its API.
• Data layer holds the relational database, cache, vector store, and object storage.
• AI layer routes inference requests to a model backend.
• Dev platform hosts the git forge, CI, and container registry.
• Observability covers product analytics, error telemetry, infrastructure metrics, and uptime.
• Team operations covers project tracking, chat, secrets, feature flags, and the other tools a team pays for separately from the app itself.

Map your stack to a self-host path#

Each row names a common paid SaaS for the category and the Quake AI template or deployment that replaces it. Build the stack one row at a time; nothing here requires adopting every layer at once.

Perimeter and gateways#

The rows above cover app runtime, data, AI, and team-ops SaaS. The perimeter layer (reverse proxy, WAF, API gateway, tunnel access, cache, edge functions, DNS) is a separate set of vendors. Self-host the software on regional VMs where a validated OpenTofu template exists; use a third-party CDN for global PoPs and volumetric DDoS absorption.

The Edge & gateways category holds perimeter templates: edge reverse proxy, edge WAF, API gateway, edge tunnel gateway, edge cache, and edge functions. Each pairs with a deployment walkthrough linked in the table above where one exists.

Run the team's tools too#

The stack sprawl is not only technical. Teams that consolidate hosting and datastores often still meter project tracking, chat, and internal tools across a separate set of vendors. The same self-host path applies.

Services involved#

Get started#

Start with the layer that costs you the most today, then add others. Each template links its deployment walkthrough.

• Runtime first. Next.js app and its deploy walkthrough, or Coolify host for push-to-deploy across several apps.
• Add the data layer. Self-managed Postgres, Redis, and Qdrant for vector search.
• Add the developer platform. Forgejo with CI and Harbor, threaded end to end in CI/CD pipelines.
• Add observability. Umami for analytics, the monitoring stack for metrics, and Uptime Kuma for status pages.
• Add inference. Inference gateway, covered in AI inference and RAG.
• Add team operations. Plane for project tracking, Mattermost for chat, and Infisical for secrets.

Estimate the cost#

The estimate below covers a starting point: the application runtime and its database. Every other row from the tables above appears below as an optional add-on (its marginal cost on top of the starting point) or an alternative (its own standalone cost, to compare against the starting point instead of adding to it).

Considerations and limits#

• You operate every layer. Quake AI provides Compute, Network, and Object Storage; the services that run on them are yours under the shared responsibility model. There is no platform-managed database, cache, or inference product.
• Single-node starting templates. Most templates here provision one VM with file-backed or block storage. For high availability, run each service against external Postgres and Object Storage and route requests through an edge reverse proxy or API gateway.
• CPU-only compute. All instances are AMD EPYC with no GPU option (compute FAQ). The inference gateway routes to a model backend you run elsewhere or to a CPU-served model; it does not add local GPU.
• Full BaaS. The Supabase self-host stack reproduces Supabase's database, auth, storage, and Realtime layer on one instance. For a backend assembled from separate pieces instead, compose Postgres, Object Storage, and the auth-oidc identity provider yourself.
• Flat egress between layers. Quake AI applies a no-egress-fee policy, so traffic between the runtime, the database, and the cache does not accrue per-gigabyte charges the way inter-vendor traffic does.
• Three US regions. All current regions are in the United States.
• When this pattern is not the right fit.
  • Teams that want managed products with no servers to operate and accept per-vendor metering for that.
  • Workloads that need a GPU-backed managed inference endpoint with no instance to run, where a hosted inference provider behind the gateway fits better.
  • Early prototypes where a single free tier is enough and operating any infrastructure is premature.