#Self-hosted Overview

This section is intentionally minimal: most teams only need to deploy infra-operator, apply one Sandbox0Infra, and tune a few fields.

The One Thing to Know#

Sandbox0 self-hosted is operator-first.

Install infra-operator
Apply a Sandbox0Infra resource
Let the operator reconcile services and dependencies

Architecture#

Planes and Core Services#

Control plane (optional in single-cluster): edge-gateway, scheduler
Data plane (runtime): internal-gateway, manager, optional storage-proxy, optional netd
In-pod runtime: procd runs inside each sandbox pod and handles process/files/volume mount operations

Single-Cluster vs Multi-Cluster#

Mode	Required services	Typical use
Single-cluster	`internal-gateway` + `manager`	Most users, fastest path
Multi-cluster	control plane (`edge-gateway` + `scheduler`) + one or more data planes	Regional scale-out

Full Mode Single-Cluster#

In full mode single-cluster, internal-gateway, manager, storage-proxy, and netd are Sandbox0 services. PostgreSQL, S3/OSS, and optional image registry are middleware dependencies.

Request Flow#

Single-cluster (typical): client -> internal-gateway -> manager -> sandbox pod (procd)
Single-cluster (direct pod path): client -> internal-gateway -> sandbox pod (procd) (for applicable traffic paths)
Multi-cluster: client -> edge-gateway -> scheduler -> target cluster internal-gateway -> manager

Regional Boundary#

One region should keep control plane and its managed data-plane clusters aligned to the same regional storage context (PostgreSQL + object storage/registry settings).

What to Configure First#

spec.database (builtin for quick start, external for production)
spec.storage (builtin for quick start, S3/OSS for production)
spec.registry
spec.services.*.enabled
spec.publicExposure