Skip to main content

Architecture

SandboxMesh is built on a decoupled architecture. We provide a fully managed, hosted control plane for your team to collaborate, while the actual execution and traffic routing happens securely inside your own Kubernetes clusters.

This means your source code, your environment variables, and your customer data never leave your infrastructure.

The Decoupled Model​

┌─────────────────────────────────┐       ┌─────────────────────────────────┐
│       Hosted SaaS Portal        │       │      Your Customer Cluster      │
│                                 │       │                                 │
│  - Team & Org Management        │       │  - SandboxMesh Agent            │
│  - Quotas & Billing             │ <───> │  - SandboxMesh Operator         │
│  - Cluster Registration         │       │  - Your App Workloads           │
│  - Sandbox Lifecycle Intent     │       │  - Your Rendered Sandboxes      │
└─────────────────────────────────┘       └─────────────────────────────────┘

The Hosted Control Plane​

Our hosted SaaS portal acts as the command center for your entire organization.

  • Centralized Management: Manage multiple teams, organizations, and access controls in one place.
  • Unified Quotas: Set concurrent sandbox limits to keep your cloud costs predictable.
  • Secure Provisioning: Create and destroy sandboxes through the UI or API without needing direct kubectl access to the cluster.

The In-Cluster Execution Plane​

Inside your cluster, a lightweight agent and operator work together to execute the commands from the control plane.

  • The Agent: Securely polls the hosted control plane for new sandbox assignments using a cluster-specific bootstrap token.
  • The Operator: Reconciles those assignments, snapshotting your real workloads and spinning up the necessary Kubernetes Deployment and Service resources natively.

How Sandboxes are Created​

  1. A developer requests a new preview environment via the SandboxMesh Portal or API.
  2. The Hosted Control Plane registers the intent and validates team quotas.
  3. The In-Cluster Agent securely fetches the new assignment.
  4. The Operator snapshots the requested workload, spins up an isolated sandbox clone, and wires up the routing rules.
  5. The Portal updates to show the environment is live and ready for traffic.

Next Steps​

  • Understand how traffic finds your new environment by reading about Routing.
  • Dive deep into the specific Kubernetes objects we generate in the Resource Model.