Platform
The Signadot Platform
Signadot Sandboxes turn one Kubernetes cluster into hundreds of isolated environments. One primitive powers a complete cloud-native validation platform built for agentic scale.
Runs in your cluster
Playground cluster available
Agent-Native Surface
Local Development
Automated Testing
Signadot Sandboxes
Your Kubernetes cluster
The core primitive
Signadot Sandboxes
The Sandbox is the foundation of the Signadot platform. It is a lightweight, isolated environment that layers onto the cluster you already run, so developers and coding agents can exercise a change against the real, full-stack system in seconds.
It does this without duplicating your stack. A Sandbox forks only the services your change touches and reuses your shared dependencies for everything else, which enables a single cluster to run hundreds at once.
Request routing
Routing keys send tagged traffic to your forks
Every Sandbox is assigned a unique, opaque routing key. The routing layer reads that key on each request and sends it to the forked service when it matches, or to the shared version when it does not. This is what lets many Sandboxes share one cluster safely.
Two ways to enforce routing
Signadot routes that traffic using your existing service mesh, or its own built-in proxies when you do not run one.
DevMesh, no mesh required
Lightweight Go proxy sidecars built into the Operator. The sidecar on the destination service reads the routing key and forwards each request to the fork or the shared version. This is the recommended path when you do not run a service mesh, and it works alongside Linkerd.
Your existing service mesh
When you already run Istio, Gateway API, or Linkerd, Signadot programs the mesh directly. The routing decision happens at the calling service, which sends each request straight to the right destination, with no extra sidecars.
Routing beyond service-to-service HTTP
Query-parameter entry points
For entry points where you cannot set headers, like a browser link, a webhook, or a curl call, add
?sd-routing-key= to the URL. The routing layer converts it into the standard headers and propagation continues from there.Async and Kafka
For message queues, the routing key travels as a message header. Sandboxed consumers process only the messages that match their key, and shared consumers skip those, so async workflows stay isolated end to end.
Context propagation
OpenTelemetry carries the key across every hop
The routing layer steers a single hop. To keep a request on the right path across a whole call chain, each service has to forward the routing key on its outbound calls. That happens at the application layer.
The key rides in the W3C
baggage and tracestate headers. If your services use OpenTelemetry instrumentation, those headers propagate automatically with no extra code.Already running distributed tracing? The routing key travels with the context you already propagate, including OpenTelemetry, Datadog, New Relic, and Jaeger.
request headers
# the routing key travels with the request
GET /api/route
baggage: sd-routing-key=a1b2c3
tracestate: sd=a1b2c3
# forwarded automatically on every
# outbound call by OpenTelemetryRouteGroups
Group Sandboxes for changes that span services
A RouteGroup combines several Sandboxes under one routing context, so you can test a feature that spans multiple services where each one comes from its own pull request.
Sandboxes are selected dynamically by label, so a Sandbox joins the group the moment it is created. The RouteGroup gets its own routing key and preview endpoints that set the key for you.
Resource plugins
Provision any dependency per Sandbox
Some dependencies need more than request routing. A resource gives a Sandbox its own ephemeral piece of infrastructure, created on startup and torn down with the Sandbox. It can be a database, a queue, or anything else a resource plugin knows how to provision.
Resource plugins define how to provision and clean up a resource as versioned, containerized workflows. You install a plugin once and reuse it across Sandboxes. Its outputs, like host and credentials, are injected into the fork as environment variables.
sandbox.yaml
spec:
resources:
- name: customerdb
plugin: mariadb
params:
dbname: customer
# the fork reads the ephemeral DB
env:
- name: MYSQL_HOST
valueFrom:
resource:
name: customerdb
outputKey: provision.host
“Our Signadot based tooling had a CSAT that was 28 points higher than our older Platform Engineering tech.”
One validation platform, from local to merge.
Brex moved developer testing onto Signadot instead of maintaining a fleet of full preview environments, giving every engineer a reliable place to validate changes.
Architecture & security
Your code and data stay in your cluster
Only the control plane runs in Signadot's SaaS. The Operator, your workloads, and your data all stay inside your own Kubernetes cluster. The Operator connects out over a secure tunnel and does the work of creating forks, programming routes, and managing resources, so nothing sensitive leaves your environment.
Database isolation
Give each Sandbox the right data
Request routing handles services. Stateful data needs its own approach, so a schema change or a seeded test never touches shared data. Signadot gives you a few, and they all clean up when the Sandbox ends.
Partition
Share the existing database and separate test data by a tenant key like an org or user ID.
Ephemeral
A resource plugin spins up a temporary database or schema for the Sandbox and removes it on teardown.
Branch
Each Sandbox gets its own database branch that inherits the parent schema and data, then runs independently.
Message queues
Multi-tenant async on one shared broker
Isolation follows your messages too. The routing key rides on each message, so async work stays on the same path as the request that started it, with no per-Sandbox broker to run.
Sandboxed consumers ask Signadot's in-cluster Routes API which keys are theirs and process only matching messages, while shared consumers skip anything bound for a Sandbox. Works with Kafka, RabbitMQ, SQS, and Pub/Sub.
Ecosystem
Fits your stack
The engine plugs into the tools you already run, from service meshes and CI to the test frameworks and coding agents your team uses.
Spin up your first sandbox in minutes.
Give your team and your coding agents isolated environments and automated validation on the cluster you already run. No duplicated infrastructure, no waiting on shared staging.
