Infrastructure Security

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

Hosting

Component	Details
Cloud provider	Google Cloud Platform (GCP)
Compute	Google Kubernetes Engine (GKE) with dedicated clusters
Region	`us-west1` (Oregon, USA) with multi-zone availability (`us-west1-a`, `us-west1-b`, `us-west1-c`)
Container orchestration	Knative Serving with Kourier networking layer
Container registry	Google Artifact Registry (30-day image cleanup policy)
Primary database	Google Cloud Spanner (regional, multi-zone)
Analytics database	ClickHouse Cloud (GCP)
Encryption keys	Google 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:

Direction	Rule
Ingress	Only from the Kourier ingress gateway (the load balancer). No pod-to-pod traffic between MCP servers
Egress	Only 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

Property	Details
Minimum TLS version	TLS 1.2 (enforced via GCP SSL policy with `MODERN` profile)
Certificate management	Google-managed certificates via GKE Certificate Manager
HTTP redirect	All HTTP requests are 301 redirected to HTTPS
MCP server TLS	HTTPS-only Gateway API listener on port 443
Internal cluster traffic	Within-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:

Property	Details
Build secrets	GCP access tokens for Artifact Registry are passed via Docker BuildKit `--secret` mount, never baked into image layers
Build timeout	10-minute timeout prevents resource exhaustion
Temp file cleanup	Build directories are always cleaned up in a `finally` block
Private repo access	GitHub App installation tokens are used for cloning (not persisted)
Image tagging	Images are tagged with the git commit SHA for traceability
Reserved env var filtering	`GUMSTACK_` 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)

Property	Default
Min replicas	1 (keeps at least one pod warm)
Max replicas	10 (configurable per server)
Concurrency target	100 concurrent requests per pod
Auto-scaling	Knative scales up when concurrency exceeds the target

Backend API

Property	Production
Min replicas	6
Max replicas	48
Scale triggers	Active concurrent requests (target 40), CPU (50%), memory (50%)
Scale-down stabilization	30-minute window before scaling down
Rolling updates	`maxSurge: 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

Get Started

Platform

Building Servers

Security

Deployment

Reference

Infrastructure Security

Hosting

Enterprise deployments

Container isolation

gVisor sandboxing

No cloud credentials

Network policies

Namespace isolation

Network architecture

Traffic flow (MCP clients)

Traffic flow (API)

Domain mapping

TLS and encryption in transit

Build pipeline security

Runtime containers

Scaling and availability

MCP servers (Knative)

Backend API

Node pool auto-scaling

Deployment rollback

Internal API security

Security Overview

Data Protection

Deploying

Internal MCP Servers

​Hosting

​Enterprise deployments

​Container isolation

​gVisor sandboxing

​No cloud credentials

​Network policies

​Namespace isolation

​Network architecture

​Traffic flow (MCP clients)

​Traffic flow (API)

​Domain mapping

​TLS and encryption in transit

​Build pipeline security

​Runtime containers

​Scaling and availability

​MCP servers (Knative)

​Backend API

​Node pool auto-scaling

​Deployment rollback

​Internal API security

​Related docs

Security Overview

Data Protection

Deploying

Internal MCP Servers

Hosting

Enterprise deployments

Container isolation

gVisor sandboxing

No cloud credentials

Network policies

Namespace isolation

Network architecture

Traffic flow (MCP clients)

Traffic flow (API)

Domain mapping

TLS and encryption in transit

Build pipeline security

Runtime containers

Scaling and availability

MCP servers (Knative)

Backend API

Node pool auto-scaling

Deployment rollback

Internal API security

Related docs