Skip to main content
Gumstack runs on Google Cloud Platform (GCP) with infrastructure designed for multi-tenant isolation, secure builds, and encrypted communications.

​
Hosting

ComponentDetails
Cloud providerGoogle Cloud Platform (GCP)
ComputeGoogle Kubernetes Engine (GKE) with dedicated clusters
Regionus-west1 (Oregon, USA) with multi-zone availability (us-west1-a, us-west1-b, us-west1-c)
Container orchestrationKnative Serving with Kourier networking layer
Container registryGoogle Artifact Registry (30-day image cleanup policy)
Primary databaseGoogle Cloud Spanner (regional, multi-zone)
Analytics databaseClickHouse Cloud (GCP)
Encryption keysGoogle Cloud KMS

​
Enterprise deployments

Enterprise customers can be provisioned with dedicated GCP projects that include isolated Spanner instances, storage buckets, and service accounts, providing complete data and compute isolation.

​
Container isolation

Every MCP server runs in its own isolated container with multiple layers of protection:

​
gVisor sandboxing

All MCP server pods run with gVisor (runtimeClassName: gvisor), a kernel-level sandbox that intercepts system calls. Customer code never executes directly on the host kernel. This prevents container escape attacks and limits the blast radius of any vulnerability in user code.

​
No cloud credentials

MCP server pods use a Kubernetes service account with no GCP Workload Identity annotation. This means customer code has zero access to GCP APIs, metadata servers, or any cloud resources. All GCP operations (logging, credential retrieval, token validation) are proxied through the Gumstack backend over HTTPS.

​
Network policies

A strict Kubernetes NetworkPolicy is enforced on all MCP server pods:
DirectionRule
IngressOnly from the Kourier ingress gateway (the load balancer). No pod-to-pod traffic between MCP servers
EgressOnly to public internet on ports 80/443. All RFC 1918 private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are blocked
This prevents:
  • One customer’s server from accessing another’s
  • Lateral movement to internal services or databases
  • Access to the GCP metadata server (169.254.169.254)

​
Namespace isolation

All MCP servers deploy to a dedicated gumstack-mcp Kubernetes namespace, separate from the backend API and other platform components.

​
Network architecture

​
Traffic flow (MCP clients)

Client (Cursor / Claude / Gumloop)
  → GKE Global L7 Load Balancer (HTTPS:443)
    → Kourier Ingress Gateway
      → Knative Service Pod (gVisor sandbox)

​
Traffic flow (API)

Client / MCP Server
  → GKE Global L7 Load Balancer (HTTPS:443)
    → Gumstack Backend Service (FastAPI)

​
Domain mapping

Each MCP server gets a unique subdomain (e.g., your-server.gumstack.com) via Knative DomainMapping, with Google-managed TLS certificates.

​
TLS and encryption in transit

PropertyDetails
Minimum TLS versionTLS 1.2 (enforced via GCP SSL policy with MODERN profile)
Certificate managementGoogle-managed certificates via GKE Certificate Manager
HTTP redirectAll HTTP requests are 301 redirected to HTTPS
MCP server TLSHTTPS-only Gateway API listener on port 443
Internal cluster trafficWithin-cluster communication uses the GCP VPC (standard for GKE)

​
Build pipeline security

When you deploy an MCP server, Gumstack builds a Docker container from your code:
PropertyDetails
Build secretsGCP access tokens for Artifact Registry are passed via Docker BuildKit --secret mount, never baked into image layers
Build timeout10-minute timeout prevents resource exhaustion
Temp file cleanupBuild directories are always cleaned up in a finally block
Private repo accessGitHub App installation tokens are used for cloning (not persisted)
Image taggingImages are tagged with the git commit SHA for traceability
Reserved env var filteringGUMSTACK_* and GUMLOOP_* prefixes are rejected at API level and filtered again at deployment time (defense-in-depth)

​
Runtime containers

Deployed containers run with:
  • gVisor sandboxing (kernel-level isolation)
  • No cloud credentials (dedicated service account with no GCP bindings)
  • Strict network policies (no private IP egress)
  • Readiness and liveness probes for health monitoring

​
Scaling and availability

​
MCP servers (Knative)

PropertyDefault
Min replicas1 (keeps at least one pod warm)
Max replicas10 (configurable per server)
Concurrency target100 concurrent requests per pod
Auto-scalingKnative scales up when concurrency exceeds the target

​
Backend API

PropertyProduction
Min replicas6
Max replicas48
Scale triggersActive concurrent requests (target 40), CPU (50%), memory (50%)
Scale-down stabilization30-minute window before scaling down
Rolling updatesmaxSurge: 3, maxUnavailable: 1 for zero-downtime deploys

​
Node pool auto-scaling

GKE node pools scale automatically based on demand. Production capacity ranges from 2-20 nodes for MCP workloads and 6-72 nodes for backend services.

​
Deployment rollback

Knative creates a new revision for each deployment. If a revision fails readiness checks, the previous revision continues serving traffic. Explicit rollback is also available via the Gumstack API, which re-deploys a previous image version. Every deployment is tracked in the database with status transitions (BUILDING → DEPLOYING → LIVE or FAILED), and build status is reported back to GitHub commits for visibility.

​
Internal API security

The Gumstack backend exposes /internal/* endpoints that MCP servers call for token validation, RBAC checks, and activity logging. These endpoints:
  • Require authentication on every request (OAuth JWT, GumCP API key, or Firebase token)
  • Resolve the full user profile from the database before processing
  • Are org-scoped to prevent cross-organization access

Security Overview

High-level security posture

Data Protection

Encryption, secrets, and credential management

Deploying

Deployment process and environment variables

Internal MCP Servers

Server management and configuration