> ## Documentation Index > Fetch the complete documentation index at: https://docs.gumstack.com/llms.txt > Use this file to discover all available pages before exploring further. # Infrastructure Security > Hosting, container isolation, network architecture, and build pipeline 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 ## Related docs High-level security posture Encryption, secrets, and credential management Deployment process and environment variables Server management and configuration