Skip to main content

Signadot Documentation Overview

Introduction​

Welcome to the official documentation for Signadot.

Signadot is a Kubernetes-native platform that gives developers and AI agents isolated environments and integrated testing and validation to build microservices with confidence.

As AI coding agents take on more of the development workload, two problems become acute:

  1. Agents can't self-validate against real dependencies. Agents work on one service at a time, in isolation. Without a live environment to test against, they have no way to observe cross-service behavior or catch integration issues during development. They'll produce changes that look correct in isolation but break at runtime, and neither the agent nor the developer finds out until much later.

  2. PR volume makes post-merge validation untenable. Agents produce PRs fast. Leaving integration validation to a shared staging environment after merge was already a compromise: catching bugs too late, in a place where it's hard to attribute them. At agent-generated PR volumes, it breaks down entirely. When something fails in staging, you're debugging across hundreds of merged changes with no clear culprit and no confidence about what's safe to ship.

For self-validating and ensuring integration correctness as code is being written, Signadot gives developers and agents a live environment wired into real dependencies. Agents interact with Signadot through an MCP server, so any agent running in Cursor, Claude Code, VS Code, or any MCP-compatible environment can spin up sandboxes, run tests, and validate changes as part of its own workflow, without human intervention.

For keeping pace with the volume of changes flowing through the pipeline, every PR gets its own request-isolated sandbox that spins up in seconds, enabling automated validation before merge. Because each developer and agent gets their own environment with no contention, this scales with agent output without batching or waiting.

The Builder's Loop​

Signadot operates at both stages of the development cycle, giving developers and agents the eyes (live context) and hands (infrastructure) to act at each stage.

Inner loop (pre-PR): Developers and agents can self-validate their changes against live dependencies as they write code. Most inner loop tooling operates without a real environment — unit tests, linters, static analysis — so this is a meaningful shift. A sandbox spins up with only the changed services deployed, routing live traffic through the new code while falling back to the shared cluster for everything else. Developers and agents can inspect behavior using previews and sandboxed APIs and iterate until they're confident in the change, without waiting for a shared staging slot or a human reviewer.

Outer loop (PR and beyond): Once a change reaches a pull request, Signadot automatically creates a preview environment and enables running automated tests against it, comparing new behavior against the baseline. Teams can enforce quality gates and validation checks before merge, making the PR review itself faster and more focused. Test results and behavioral evidence are available at review time, helping teams move through the process faster and with more confidence.

Both loops are accessible through the same control plane: the CLI for developers and the MCP server for agents running in Cursor, Claude Code, VS Code, or any MCP-compatible environment.

Core Capabilities​

All capabilities are available to both developers and agents through a unified control plane.

Environments​

  • Local Development Environments: Test changes against real dependencies (production-scale databases, vector stores, third-party APIs) in a shared cluster, without building images or pushing code.
  • Pull Request Environments: Every PR automatically gets an isolated, full-stack environment for inspecting and validating changes in the context of all real dependencies, from UI tweaks to API changes.

Validation​

  • Integration & E2E Testing: Run integration and end-to-end test suites against ephemeral, production-like environments using Signadot Jobs, covering the full chain of interactions from the API gateway down to the database.
  • Smart Tests: Validate API behavior without writing brittle assertions. AI-powered Smart Diff compares new behavior against the baseline so you can assess the impact of a change, and synthetic smoke tests provide continuous health monitoring for any API endpoint.
  • Skills (coming soon): Natural language-defined validation flows that agents and developers can invoke by name to validate changes in a live environment, closing the feedback loop without manual orchestration.

How It Works​

Signadot installs into your Kubernetes cluster and connects to a remote control plane. Three properties make it possible to run many sandboxes simultaneously without cost or contention:

  • Only changed services are deployed. Unchanged services are served from the shared cluster, so a sandbox is a lightweight delta, not a full environment clone.
  • Isolation tuned to what you're testing. From request-level routing to logical or physical separation, each component can be isolated as little or as much as needed to reliably validate changes.
  • Stateful resources are scoped per sandbox. Databases, queues, and other stateful components get lightweight, sandbox-specific schemas or topics rather than full duplicates.

Request routing is handled either by the built-in devmesh for HTTP/gRPC traffic, or through service mesh integration (Istio, Linkerd) for advanced use cases. Both approaches use standard header propagation protocols like OpenTelemetry or B3 to split traffic between sandbox and baseline environments.

For asynchronous workflows, Signadot provides message queue isolation through libraries supporting Kafka, RabbitMQ, and other message queues. These libraries create sandbox-specific topics and queues, maintaining message ordering while automatically cleaning up resources when sandboxes are deleted.

Data isolation is achieved through resource plugins for stateful components like databases. These plugins create temporary schemas or databases for sandboxes with minimal overhead, enabling proper isolation of data changes while maintaining efficiency in shared resources.

This means a team running dozens of agents in parallel, each working on a different feature or fix, can each have a full-stack, production-like environment at a fraction of the cost of separate staging clusters. The validation bottleneck disappears because environments are no longer a scarce resource.

This architecture is similar to systems like SLATE at Uber and Staging Overrides at Lyft.

Getting Started​

For detailed architecture and concepts, see our technical documentation.