# Signadot > Signadot is the platform for validating AI-generated code and microservices changes against real dependencies before merge. Its core is a novel approach to environment virtualization that spans services, datastores, message queues, and other resources: large numbers of lightweight ephemeral environments spin up in seconds without duplicating the entire stack for each one. Testing capabilities (Jobs, Smart Tests, and Plans) are layered on top of these environments to form a comprehensive validation platform, where code written by developers or by coding agents (Cursor, GitHub Copilot, Devin, Claude Code) is verified in a production-like environment before a PR lands. Signadot installs as a Kubernetes operator and integrates with service meshes (Istio, Linkerd), CI/CD pipelines, and observability stacks. Sandboxes also cover dependencies that run outside Kubernetes, including databases, cloud services, and workloads on VMs, ECS, or serverless, via resource plugins. This file is the full-content markdown export of key pages on www.signadot.com. The link index version is at https://www.signadot.com/llms.txt. Documentation pages are served at https://www.signadot.com/docs/. A separate llms.txt covering the full technical documentation is available at https://www.signadot.com/docs/llms.txt # Core Product Pages ## Homepage Source: https://www.signadot.com/ Summary: Overview of Signadot's platform for agentic development: ephemeral sandboxes, jobs-based test execution, and plans-based validation of code changes from developers and coding agents. *Image: rocket icon* Scalable Agentic Development platform ### AI writes code. We make sure it works. Give developers and coding agents the fastest path from code to merge. Ephemeral environments and automated validation on Kubernetes, built for enterprise scale. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) *Image: Check mark* No credit card required *Image: Check mark* Playground cluster available *Image: Architecture diagram: a browser request flows through an API gateway to cart, user, notification, auth, and config services backed by three databases. A sandboxed copy of user-svc for pull request 42 is spliced into the request path, and an Agent Skills panel shows end-to-end tests, API diff, and contract checks passing.* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Validate every code change Three building blocks that work together: sandboxes give you isolated environments, jobs run your test suites at scale, and plans encode your team's validation expertise. All inside your existing Kubernetes cluster. Sandboxes ##### Ephemeral Environments Lightweight environments that share your existing cluster. Scale to as many parallel environments as your team needs. Kubernetes Cluster Auth Svc Sandbox 12s Pay Svc Sandbox 18s Cart Svc Sandbox 10s Search Svc Sandbox 24s Shared baseline 100s parallel [ Learn more ](https://www.signadot.com/docs/concepts/sandbox) Jobs ##### Scalable test execution Execution infrastructure to run the Playwright, Cypress, or custom suites you already have, massively parallel inside your cluster. Test Frameworks playwright cypress custom run via Job Runner auth-e2e running checkout-flow running Auto-routed to sandboxes CI ready [ Learn more ](https://www.signadot.com/docs/guides/use-cases/run-automated-tests) Plans ##### Your validation logic Compose actions into reusable plans that agents run to validate changes. Actions — primitives http-req run-test custom compose into Plans — validation flows payments auth-e2e custom [ Learn more ](https://www.signadot.com/docs/tutorials/quickstart/plan-based-validation) ##### Trusted by teams shipping faster 10x faster ##### Feedback in seconds Developers and agents spin up sandboxes and get instant feedback on every change. [→ Wealthsimple: faster testing](https://www.signadot.com/case-studies/how-signadot-helped-wealthsimple-speed-up-microservice-testing-and-unblock-developers/) 80% fewer bugs ##### Bugs caught pre-merge Test against real dependencies in your cluster pre-merge. No mocks. [→ Earnest: catching bugs earlier](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) 85% less infra costs ##### Cut infrastructure costs Scale to thousands of sandboxes without duplicating infrastructure. [→ Brex: saved $2M annually](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) #### Fast feedback from local dev to pull request merge One Signadot platform powers two loops: fast functional feedback for agents and developers locally, and comprehensive validation for every PR. Inner Loop Fast functional feedback. Agents close the loop autonomously. 1 + AI Coding Agents ##### Write Code Agents and developers collaborate on features. Rapid iteration on every change. 2 agent · local MCP k8s cluster sb ##### Spin Up a Sandbox Local agent connects to your live cluster via MCP or CLI. Sandbox ready in seconds. 3 ✓ checkout.e2e ✓ auth.e2e ✕ payment.e2e code test debug ##### Closed-Loop Validation Agents run E2E and integration tests against the live cluster, debug failures, and iterate autonomously. One Signadot Platform Promote forward · Iterate back Outer Loop Comprehensive PR validation. Regression, E2E, and non-functional suites. 4 PR #142 opened auto-sb k8s cluster sb ##### A Sandbox for Every PR Every PR auto-provisions its own sandbox in the cluster. Same Signadot platform. 5 Integration E2E Regression Performance ##### Run Comprehensive Tests Plans and Jobs run integration, E2E, regression, and non-functional suites in Kubernetes. 6 Merge Ready All tests No regressions Perf clean ##### Merge with Confidence Validated in both loops. Ship code with high confidence in quality and behavior. #### Built for how your team actually works Different roles, same platform. Signadot fits into your existing workflows. Engineering Leaders ##### For Engineering Leaders You're being asked to adopt AI coding tools and increase developer productivity without increasing headcount or cloud spend. Signadot is the infrastructure layer that makes that possible. Scale validation to match the pace of code generation, without scaling costs. [ Learn more ](https://www.signadot.com/schedule-a-call/) *Image: Phil Burrows* Phil Burrows Head of Platform Engineering at Brex "Signadot for this (preview environments) use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff that we were looking at. And the return on the investment was obvious... just in infrastructure costs, it saves us about $2 million annually." Platform Engineers ##### For Platform Engineers You need infrastructure that fits your existing stack, not another abstraction to manage. Signadot is Kubernetes-native and integrates with your service mesh (Istio, Linkerd), CI/CD pipelines, and observability stack. Give your developers and their agents self-service environments without filing tickets. [ See our docs ](https://www.signadot.com/docs/overview) *Image: Connor Braa* Connor Braa Software Engineering Manager at Brex "On the margin, with the Signadot approach, 99.8% of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not." Developers ##### For Developers Get instant feedback on every change. No more waiting for a shared staging slot. Your coding agents can spin up sandboxes, run tests, and iterate autonomously to give you back the time you'd spend babysitting their output. [ See our docs ](https://www.signadot.com/docs/overview) *Image: Mahesh Uligade* Mahesh Uligade Technical Lead at Sharechat "Staging used to break and affect everyone using downstream or upstream services, including QA and frontend. Now with Signadot, each developer just maintains a single pull request and can keep adding changes there." Brex, SoFi, Wealthsimple, Bitso, and many more #### Start shipping validated code in minutes Spin up your first sandbox on our playground cluster. No credit card, and no Kubernetes of your own required. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### Everything your team needs to ship with confidence. Coding agents generate more code, faster, and in parallel. Signadot gives every developer and agent a lightweight ephemeral environment in your Kubernetes cluster, connected to real services and real dependencies, without duplicating the entire stack. Changes are [validated during development and before merge](https://www.signadot.com/validate-ai-generated-code-kubernetes/), so your team ships to production as fast as code is written. ##### Local development with real services Agents and developers use the MCP Server and CLI to establish a secure, bi-directional tunnel between your local workstation and a remote Kubernetes cluster. Instantly test your local code changes end-to-end from mobile, web, or API frontends. No mocks required. [ Learn more ](https://www.signadot.com/docs/guides/use-cases/set-up-local-testing) Your Machine Agent cart.go Kubernetes Cluster signadot bot Sandbox pr-276-frontend created Routing Key nm2cqkbfxqzml Updated 2 minutes ago Tests Summary ✓ ✓ ✓ ##### Ephemeral environments for every pull request Get a lightweight, ephemeral environment for every pull request, scalable to hundreds of concurrent PRs. Integrate easily with your CI to automate setup for every PR. Preview changes, manually validate, and run both functional and non-functional automated tests before merging code. [ Learn more ](https://www.signadot.com/docs/guides/set-up-pr-sandboxes) ##### Run E2E and integration tests pre-merge Run your Playwright, Cypress or any other tests using Jobs. Signadot Jobs run securely within your Kubernetes cluster and are Sandbox-aware. Shift left end-to-end tests and catch integration issues before merging code. [ Explore test scenarios ](https://www.signadot.com/docs/guides/use-cases/run-automated-tests) Your Tests Signadot Job Sandbox aware Sandbox ✓ ✓ ✓ ✓ Actions K8s primitives Plans Deterministic ##### Signadot Plans Platform teams build secure custom actions inside your Kubernetes cluster. Developers compose actions into deterministic plans that coding agents run to validate changes. All runs are fully deterministic, with no token costs, making plans fast and cost-effective at scale. [ Learn more ](https://www.signadot.com/docs/tutorials/quickstart/plan-based-validation) *Image: chat icon* voice of our customers #### Customer Success Stories [*Image: Brex customer story video* *Image: Brex logo* Brex saved $2M annually using Signadot](#) [*Image: ShareChat customer story video* *Image: ShareChat logo* ](#) #### Your team is only as fast as your validation loop AI coding agents generate code fast. Signadot makes sure every change actually works before it ships. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently Asked Questions How is Signadot different from other solutions? Unlike traditional ephemeral environment solutions that duplicate entire infrastructure stacks, Signadot uses a unique approach using sandboxes. This approach virtualizes environments within a single Kubernetes cluster by only duplicating the services needed, dynamically routing requests between the baseline and the sandbox. This allows you to efficiently run thousands of concurrent isolated environments for developers and agents without contention. Environments spin up in seconds, which is critical to enabling agentic workflows that demand fast feedback loops. What capabilities does Signadot offer? Signadot provides these core capabilities: \- Local Development: Connect local workstations, CDEs, or agent runtimes directly to your Kubernetes cluster via isolated sandboxes so agents can write, run, validate, and debug code against real dependencies and live traffic. \- Preview Environments: Automatically generate preview environments for every human or agent PR to validate changes from Web and Mobile frontends. \- Bring Your Own Automated Tests: Execute your K6, Playwright, Cypress, or other test suites against isolated sandboxes that are generated automatically for every PR. \- SmartTests: Validate PRs to catch regressions before merging with AI-powered auto-diff. \- Autonomous Workflows: Equip AI agents with the ability to provision sandboxes and validate their code autonomously via our MCP server How does Signadot enable agentic development? Signadot provides the runtime context and isolation required for agents to function as autonomous engineers. By connecting agent runtimes directly to your Kubernetes cluster via sandboxes, agents gain access to real dependencies and data without risking stability. This allows them to write code, run it against the live system, analyze errors, and self-correct in a tight feedback loop. Instead of just generating code, agents can deliver fully validated solutions that are ready to merge. What coding agents does Signadot integrate with? Signadot integrates natively with any tool that supports the Model Context Protocol (MCP), including Cursor, Claude Code, and VSCode. This allows your AI agents to provision sandboxes, route traffic, and verify code execution directly within their runtime, turning them into autonomous engineering partners that can validate their own work in a closed loop. What is the Signadot MCP Server? The Signadot MCP Server bridges the gap between your AI agents and your Kubernetes infrastructure. Using the Model Context Protocol standard, it exposes a set of native tools that allow agents to manage ephemeral environments and debug issues using natural language prompts. With the MCP server, coding agents can create and manage Signadot sandboxes and route groups, and fetch cluster context. This enables developers to integrate end-to-end validation with Signadot sandboxes into their autonomous workflows. What are Sandboxes? Sandboxes are lightweight, isolated testing environments that allow you to test changes without interfering with other developers or the base environment. Unlike traditional approaches that duplicate entire infrastructure, Sandboxes only create the specific components you're modifying and use request routing to provide isolation. Where do Sandboxes run? Sandboxes run inside your existing Kubernetes clusters. Signadot installs as an operator in your Kubernetes environment, so all workloads, data, and testing happen within your infrastructure. The Signadot control plane orchestrates the creation and management of these sandboxes, but your code and data never leave your environment. How much effort is it to get started? Getting started with Signadot typically takes less than 15 mins. The minimal setup involves just two steps: 1\. Installing the Signadot operator in your Kubernetes cluster. 2\. Using our CLI to create Sandboxes and run tests. How does Signadot integrate with CI/CD systems? Signadot integrates seamlessly with all major CI/CD systems through our CLI, which can be used as a step in your pipeline. This allows you to automate the creation of preview environments for every PR, ensuring that code generated by AI agents is automatically validated before it reaches a human reviewer. We have examples of integrations for GitHub Actions, GitLab CI, Jenkins, and BitBucket in our [documentation](https://www.signadot.com/docs/guides/integrate-ci). Does Signadot integrate with Service Mesh like Istio, Linkerd? Yes, Signadot works well with service meshes like Istio and Linkerd. While a service mesh is not required to use Signadot, we can leverage existing service mesh capabilities for header-based request routing. Does Signadot support running automated tests? Yes, Signadot provides robust support for automated testing. You can execute tests directly within your cluster, with support for all major testing frameworks including Cypress, Selenium, Playwright, Postman, and custom frameworks. Tests run in pre-warmed pods for faster execution, and results are aggregated in a central dashboard. This is critical for agentic workflows, where agents need immediate feedback from test results to self-correct. What are Signadot SmartTests? SmartTests are AI-powered API tests that automatically detect breaking changes and contract violations. Written in a simple language called Starlark, they run in both your baseline and sandbox environments, comparing API responses to identify meaningful differences without requiring explicit assertions. Is Signadot secure? Security is a core principle in Signadot's design. Our architecture ensures your code and data remain within your infrastructure at all times. The Signadot control plane only receives metadata about tests and environments, never your actual code or sensitive data. We support RBAC for granular access control, and our system has undergone third-party security audits. Additionally, Signadot is SOC 2 Type II compliant, demonstrating our commitment to maintaining rigorous security standards. What types of applications work best with Signadot? Signadot supports cloud-native applications built using a microservices architecture running on Kubernetes. It is particularly valuable for teams with 10+ microservices, where testing becomes complex, and for organizations adopting AI coding agents that require high-velocity validation with concurrency for 50+ agents or developers. While it can work with any application that can run in Kubernetes, the benefits become more pronounced as your architecture grows in complexity. How does pricing work? Signadot offers flexible pricing based on the number of active Sandboxes and testing volume. We provide a free tier for small teams and startups, with paid plans scaling based on usage. For detailed pricing information and to find the plan that best fits your needs, please visit our [pricing page](https://www.signadot.com/pricing/) or [contact us](https://www.signadot.com/schedule-a-call/) for a custom quote. How does Signadot compare to other testing tools like Playwright, Cypress, or Selenium? Signadot complements rather than replaces these tools. While Playwright, Cypress, and Selenium focus on the mechanics of test execution (particularly for UI testing), Signadot provides the isolated environments where these tests can run. You can continue using your existing test frameworks, but run them against Signadot Sandboxes to achieve isolation and parallelism. #### Latest on Scaling Agentic Development [ *Image: LegalOn Technologies' Agent-Ready Golden Path on GKE* ###### LegalOn Technologies' Agent-Ready Golden Path on GKE How a Tokyo-based legal AI company adapted its internal GKE platform for AI agents, connecting local development to the cluster and validating every PR with Signadot preview environments before merge. ](https://www.signadot.com/blog/legalon-technologies-agent-ready-golden-path-on-gke/) [ *Image: OpenSpec + Signadot: Integration Tests Inside the Agent Loop* ###### OpenSpec + Signadot: Integration Tests Inside the Agent Loop Austin Xu wired Signadot sandboxes into his AI coding agent workflow and moved integration testing inside the agent's loop. A high-level look at his journey, the integration, and the results. ](https://www.signadot.com/blog/openspec-signadot-integration-tests-inside-the-agent-loop/) [ *Image: Kubernetes Staging Environments: How to Build, Run, and Share One* ###### Kubernetes Staging Environments: How to Build, Run, and Share One An opinionated guide to staging on Kubernetes: why most companies need exactly one pre-production environment, how to build and operate it like a product with SLOs, and how test tenants let every developer and coding agent share it safely. ](https://www.signadot.com/blog/kubernetes-staging-environment/) --- ## Platform Source: https://www.signadot.com/product/platform/ Summary: The Sandboxes platform. Request-level isolation gives every change a lightweight environment on a shared Kubernetes cluster, with RouteGroups for multi-service changes, context propagation, native message queue support, and resource plugins that bring in dependencies running outside the cluster, such as databases and cloud services. *Image: rocket icon* 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. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Runs in your cluster *Image: Check mark* Playground cluster available Agent-Native Surface Local Development Automated Testing Signadot Sandboxes Your Kubernetes cluster Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* 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. [Sandboxes docs](https://www.signadot.com/docs/concepts/sandbox) [Ephemeral environments →](https://www.signadot.com/solutions/ephemeral-environments/) 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. request service-2 service-1 service-1b FORK service-3 db tagged request shared dependencies request service-2 service-1 service-1b FORK service-3 db tagged request shared dependencies 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. [Request routing docs](https://www.signadot.com/docs/guides/request-routing) [DevMesh →](https://www.signadot.com/docs/guides/request-routing/devmesh) 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. [Context propagation docs](https://www.signadot.com/docs/guides/set-up-context-propagation) 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 OpenTelemetry ``` RouteGroups #### 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. [RouteGroups docs](https://www.signadot.com/docs/reference/route-groups) routing key one preview URL ROUTEGROUP checkout-svc · sandbox a payment-svc · sandbox b cart-svc · sandbox c 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. [Resources docs](https://www.signadot.com/docs/concepts/resources) [Resource plugins →](https://www.signadot.com/docs/reference/resource-plugins/overview) 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 ``` *Image: Brex* “Our Signadot based tooling had a CSAT that was 28 points higher than our older Platform Engineering tech.” JS John Salem Senior Software Engineer, Brex #### 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. [Start for free](https://www.signadot.com/signup/) [Read the Brex story](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) 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. Signadot control plane Signadot SaaS · CLI / API / UI / MCP secure tunnel YOUR ENVIRONMENT · CODE & DATA STAY HERE SIGNADOT OPERATOR Sandbox & RouteGroup controllers Route server DevMesh sidecars Plugin runners resources manages and routes → YOUR SERVICES service-1 service-2 service-1b db FORK [Operator architecture](https://www.signadot.com/docs/concepts/architecture/operator) [Install the Operator →](https://www.signadot.com/docs/installation/signadot-operator) 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. [Data isolation docs](https://www.signadot.com/docs/guides/set-up-data-isolation) 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. [Message queue docs](https://www.signadot.com/docs/guides/set-up-message-queue-isolation) SHARED TOPIC Routes API sandbox consumer processes only its keys shared consumer skips tagged messages 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. Service mesh & routing *Image: Istio* *Image: Linkerd* *Image: OpenTelemetry* [+](https://www.signadot.com/integrations/) CI / GitOps *Image: GitHub Actions* *Image: GitLab CI* *Image: Jenkins* *Image: Bitbucket Pipelines* [+](https://www.signadot.com/integrations/) Test frameworks *Image: Playwright* *Image: Cypress* *Image: k6* [+](https://www.signadot.com/integrations/) Coding agents *Image: Claude Code* *Image: Cursor* *Image: Windsurf* *Image: OpenAI* [+](https://www.signadot.com/integrations/) [Browse all integrations →](https://www.signadot.com/integrations/) #### 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. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Smart Tests Source: https://www.signadot.com/product/smart-tests/ Summary: AI-powered regression detection. Write API calls once in Starlark, and Signadot runs them against both the PR version and the stable version of a service in live sandboxes, using AI to flag real behavioral regressions instead of noise. *Image: rocket icon* Smart Tests ### Find every regression in your pull requests Smart Tests validates every PR in a live Kubernetes sandbox. Write the API calls once and AI compares the PR version against the stable version of your service, flagging real regressions instead of noise. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* No assertions to write or maintain *Image: Check mark* Relevance-scored findings posted to the PR smart-test.star PR version stable version AI DIFF risk score HIGH MED LOW Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* How it works #### Deep validation on every code change A SmartTest is a short script of API calls. Signadot runs it against both versions of your service, captures the behavior, and lets AI decide which differences actually matter. PR #142 opens sandbox YOUR CLUSTER test runner runs twice checkout PR SANDBOX checkout STABLE VERSION AI DIFF signal vs noise findings PR #142 opens sandbox YOUR CLUSTER test runner runs twice checkout PR SANDBOX checkout STABLE VERSION AI DIFF signal vs noise findings 1 ##### Write API calls in Starlark Define the endpoints to exercise in a simple Python-like script. Capture is built in, so there are no assertions or expected values to encode. orders.star resp = http.get( "/api/orders", capture=True) print(resp.status) 2 ##### Trigger on every sandbox Triggers match tests to services, so the moment a PR sandbox is created or updated the right tests run automatically. Git-based tests run from CI too. sandbox created test run automatic 3 ##### AI compares both versions Captured request and response pairs from the PR and stable versions are diffed by models trained on your traffic patterns, scoring each difference by relevance. PR version "id" 4471 "total" missing "status" "paid" "currency" "usd" stable version "id" 4471 "total" 19.99 "status" "paid" "currency" "usd" 4 ##### Findings land in the PR High, medium, and low relevance findings post to the pull request as a risk score, so reviewers see behavioral impact next to the code diff. signadot posted a risk score HIGH MED LOW #### Catch what assertion-based tests miss Traditional tests only check what someone thought to assert. Smart Tests observes the full runtime behavior of your service and flags any change that matters. checkout.star resp = http.get( "/api/orders", capture=True) ##### Calls, not assertions You only describe which endpoints to hit. The comparison against the stable version is the assertion, so compatible API changes never break a test. HIGH ##### Signal, not flakiness Models learn from historical runs which variations are expected, like timestamps and random IDs, and which are genuine regressions worth a human look. orders payments postgres ##### Real services, real data paths Tests execute on managed runner pods in your cluster against sandboxes that share real dependencies, so results reflect production behavior, not mocks. *Image: Bitso* “We basically stopped creating full preview environments and replaced our custom solution with Signadot. The strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” *Image: Marcus Tavares* Marcus Tavares Staff Software Engineer, Bitso #### Behavioral validation on every PR, without the test debt. Bitso gives 250+ engineers an isolated environment per PR on Signadot, the same environments Smart Tests validate against on every change. [Start for free](https://www.signadot.com/signup/) [Read the Bitso story](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) The output #### A risk score you can read at a glance Every execution produces a structured result, not a wall of raw diffs. Findings are scored by relevance and broken down by where they appear in the traffic. ##### Relevance, not raw diffs Each difference between the two versions is scored by how unexpected it is. **High** flags contract-impacting changes like removed fields, type changes, and new error codes. **Medium** marks unusual differences worth a look before merging. **Low** covers expected variation like timestamps and trace IDs. Surfaced, never blocking. ##### Request and response, separated REQ **Request** findings cover the traffic your service sends downstream as it handles the call. RES **Response** findings cover what consumers of your API actually receive, which is where breaking changes live. [Follow the Smart Tests quickstart in the docs](https://www.signadot.com/docs/tutorials/quickstart/smart-tests) get-checkout · execution Succeeded 1 High 0 Medium 5 Low Request Traceparent "00-4c3a…"›"00-e6dd…" X-Request-Id "5a68…"›"5849…" Response order.total 19.99›removed Date "03:09:18"›"03:09:52" checkout-flow 1/1 checks passed #### Give every PR a risk score before review Most teams have their first Smart Tests running in under an hour, on the cluster and staging environment they already operate. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions Is this a contract testing tool like Pact? No. Smart Tests is not a direct alternative to consumer-driven contract testing tools like Pact. Smart Tests is a provider-focused validation tool that gives you a "risk score" for your PR by analyzing its runtime behavior, rather than coordinating contracts between consumer/provider teams. How does the AI system in Smart Tests work? The AI system performs two main functions: First, it analyzes API responses from both versions to identify structural, data type, and content differences. The models determine which differences actually impact compatibility rather than flagging every change. Second, it reduces test flakiness by learning from historical test runs, distinguishing between expected variations (timestamps, random IDs) and genuine breaking changes. The system adapts to your specific APIs over time, improving its accuracy with continued use. What kinds of contract breakages can Smart Tests detect? Smart Tests detects: \- Schema changes: Removed fields, changed data types, altered object structures \- Behavioral changes: Different response codes, new error conditions, altered validation rules ‍ Because Smart Tests observes runtime behavior rather than just validating static schemas, it can identify subtle issues that traditional approaches miss. How can Smart Tests be integrated with my CI/CD pipeline? Integration requires two components: 1) The Signadot CLI integrated into your pipeline to create sandboxes for each PR 2) Smart Test triggers configured to automatically run tests against those sandboxes How long does it take to set up Smart Tests? Most teams have their first Smart Tests running in under an hour: 1) Install the Signadot operator on your Kubernetes cluster (10-15 minutes) 2) Write your first test in Starlark to call your API endpoints (5-10 minutes) 3) Configure triggers to run the test on your sandboxes (5 minutes) 4) Integrate sandbox creation with your CI/CD pipeline (15-30 minutes) Since Smart Tests runs against your existing staging/pre-production environment, you avoid the typically time-consuming process of setting up separate test environments or managing test data. What is the maintenance overhead of Smart Tests when APIs change? Smart Tests minimizes maintenance when APIs evolve: \- When you make compatible API changes (adding fields, extending functionality in backward-compatible ways), Smart Tests automatically recognizes these as non-breaking and doesn't require test updates. \- For intentional breaking changes, you typically only need to update the test code that calls the changed endpoints - not assertions or expectations, since those are handled by the AI comparison system. --- ## Jobs Source: https://www.signadot.com/product/jobs/ Summary: Run existing Playwright, Cypress, k6, or custom test suites on pre-warmed runner pods inside your cluster, automatically routed to the sandbox under test. Logs stream to CI and reports, screenshots, and videos upload as artifacts. *Image: rocket icon* Jobs ### Run your test suites where your services run Jobs execute your existing Playwright, Cypress, k6, or custom suites on pre-warmed runner pods inside your cluster, automatically routed to the sandbox under test. Logs stream back to CI and artifacts upload on completion. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Bring any test framework or container image *Image: Check mark* Test execution stays inside your cluster YOUR CLUSTER playwright e2e login.spec.ts cart.spec.ts checkout.spec.ts runner pod checkout SANDBOX FORK auth cart payments passed Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* How it works #### From CI trigger to test report in one submission A Job is a single unit of test execution. You define the runner environment once, then every submission runs your suite against the right sandbox with no environment setup in the pipeline. YOUR CLUSTER PR #142 opens sandbox checkout.spec.ts runner pod rk: pr-142 checkout SANDBOX FORK auth cart pay e2e PR #142 opens sandbox YOUR CLUSTER checkout.spec.ts runner pod rk: pr-142 checkout SANDBOX FORK auth cart pay e2e 1 ##### Define a runner group Point it at your test image, resource limits, and secrets. The Operator keeps warm pods ready in your cluster so there is no cold start per run. runnergroup: e2e-suite image: e2e cpu: 2 secret: ci warm warm warm warm 2 ##### Submit from CI or the CLI One command submits a script or command with a routing context binding it to the sandbox or route group under test. $ signadot job submit DISPATCHES TO A WARM RUNNER POD 3 ##### Traffic routes itself The routing key is injected into the HTTP traffic your suite emits. Requests hit the forked services under test and shared services for everything else. rk: pr-142 checkout SANDBOX FORK auth, cart, pay SHARED SERVICES 4 ##### Results land in the PR Logs stream back to the CI job in real time. Reports, screenshots, and videos upload as artifacts you can pull from the dashboard or API. e2e / playwright passed report.html video.mp4 Execution infrastructure #### Bring the frameworks you already use Jobs do not replace the tests your teams trust. A runner group points at your own container image with your service accounts and resource limits, and the Operator keeps pre-warmed pods ready so dispatch is fast. *Image: Check mark* Any suite that runs in a container, from Playwright to fully custom harnesses *Image: Check mark* Your image, your service accounts, your resource limits *Image: Check mark* Pre-warmed runner pods, no cold start per run *Image: Playwright* *Image: Cypress* *Image: Grafana k6* *Image: Selenium* *Image: Earnest* “Signadot is a key part of our solution for the most critical parts of our testing pyramid. For integration and end-to-end testing we need to have a sandbox up and running because they need a live service to talk to.” EE Early Ehlinger Dev Experience Lead, Earnest #### The hardest layers of the testing pyramid, covered pre-merge. Earnest runs its integration and end-to-end suites in parallel against live sandboxes on every change, catching problems before they reach staging. [Start for free](https://www.signadot.com/signup/) [Read the Earnest story](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) suite rk: pr-142 sandbox shared Routing #### Auto-routed to the sandbox under test A Job declares a routing context that binds it to a sandbox or route group. Signadot injects the matching routing key into the HTTP traffic the suite emits, so requests reach the forked services under test and shared services everywhere else. *Image: Check mark* Off-the-shelf suites work with no code changes *Image: Check mark* Execution waits for sandbox readiness, so results are coherent *Image: Check mark* The same suite validates any number of sandboxes in parallel Results #### Results where your team already looks Attach from the pipeline and output streams back in real time with a real exit code, so a failing run fails the check. Everything the suite produced is collected automatically when the run completes. *Image: Check mark* Streamed logs and exit codes in the CI job *Image: Check mark* Reports, screenshots, and videos upload as artifacts *Image: Check mark* Run history and downloads in the dashboard and API [Read the Jobs reference in the docs](https://www.signadot.com/docs/reference/jobs) signadot/hotrod pr-220 into master All checks have passed 7 successful checks Go / build (pull\_request) 1m 32s Go / sandbox-router (pull\_request) 48s Go / sandbox-location (pull\_request) Skipped Go / sandbox-driver (pull\_request) Skipped Sandbox: pr-220-route Routing key: gbscspdnzvcc0 12s #### Point your existing suites at every change Run the tests you already have against isolated sandboxes on the cluster you already operate, with results back in the PR in minutes. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) #### Jobs FAQ What test frameworks can Jobs run? Any framework that runs in a container. Teams run Playwright, Cypress, k6, pytest, and fully custom suites by pointing the runner group at their own image. A Job executes a script or command inside that image, so nothing about your existing tests needs to change. Where do Jobs execute? Inside your Kubernetes cluster, on pre-warmed runner pods managed by the Signadot Operator. The Signadot control plane orchestrates scheduling and stores results, while the test traffic itself stays between the runner pod and the services on your cluster. How does a Job target a specific sandbox? Each Job declares a routing context that binds it to a sandbox or route group. Signadot injects the matching routing key into the HTTP traffic the Job emits, so requests flow through the sandboxed versions of changed services and reach shared services for everything else. Off-the-shelf suites work without code changes. How do results get back to my CI pipeline? Submit a Job from CI with the Signadot CLI and attach to it. Stdout and stderr stream back to the CI log in real time, and any declared artifacts such as HTML reports, screenshots, and videos are uploaded when the Job completes and can be downloaded from the dashboard or API. --- ## Plans Source: https://www.signadot.com/product/plans/ Summary: Reusable validation workflows authored from natural language and run against live sandboxes. Platform teams govern an action catalog, and developers and coding agents run tagged plans by name until every check passes before the PR opens. *Image: rocket icon* Plans ### Reusable agent-native validation workflows A Plan is a reusable validation workflow authored from natural language and run against a live Sandbox. Developers and coding agents invoke it by name and get an end-to-end verdict on their change in seconds. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Authored from a prompt, versioned in git *Image: Check mark* Runs against real services in seconds "Validate the ride request flow" plan: ride-request-flow v3 request-http playwright k6 passed in 14s YOUR CLUSTER location-svc rides geo postgres Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* How it works #### From prompt to reusable validation in four steps Plans separate what to validate from how to validate it. The platform team governs the building blocks, and every developer and agent composes them into fast, repeatable checks. Create once "Validate the ride request flow" /signadot-plan author from prompt ACTION CATALOG request-http playwright k6 PLAN LIBRARY checkout-flow ride-request v1 hint: ride flow changes search-api Run on every change diff: location-svc signadot-validate picks and runs plans SANDBOX RUN location-svc fork rides geo all plans pass fail: fix and re-run Create once "Validate the ride request flow" ACTION CATALOG request-http playwright k6 /signadot-plan PLAN LIBRARY checkout-flow ride-request v1 hint: ride flow changes search-api Run on every change diff: location-svc FROM LIBRARY ride-request signadot-validate SANDBOX RUN location-svc fork rides geo all plans pass fail: fix and re-run 1 ##### Govern the Action catalog Actions like request-http, playwright, and k6 are defined in markdown with typed inputs and outputs, versioned in git, and curated by your platform team. request-http.md INPUTS url string method string OUTPUTS status number governed 2 ##### Author from natural language A developer or agent describes what should be validated. The signadot-plan skill compiles the prompt into a plan composed of catalog actions. "validate ride request" ride-request request-http playwright k6 3 ##### Tag it into the library Plans are immutable, tagged, and carry a selection hint that tells agents when to use them. The library grows into shared coverage of your user flows. ride-request v1 tag ride flow changes LIBRARY checkout-flow ride-request search-api 4 ##### Run on every change The signadot-validate skill picks the right plan for a diff and runs it in a Sandbox against real services. The agent fixes what broke and re-runs until the change passes. diff: location-svc ride-request v3 all plans pass passed in 14s *Image: Bitso* “We basically stopped creating full preview environments and replaced our custom solution with Signadot. The strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” *Image: Marcus Tavares* Marcus Tavares Staff Software Engineer, Bitso #### Validation that keeps up with agent-speed development. Bitso scaled branch-based development for 250+ engineers and 200+ microservices on Signadot, with coding agents validating changes the same way. [Start for free](https://www.signadot.com/signup/) [Read the Bitso story](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Agent skills #### Two skills close the loop for coding agents Agents interact with Plans through skills, discovering capabilities the moment they need them. One skill writes the validation, the other runs it on every change and keeps iterating until the change actually works. SKILL signadot-plan Authors the validation once A developer or agent describes what should be validated in plain language. The skill reads the action catalog, drafts the plan, runs it against your live services to confirm it works, then tags it with a selection hint and commits it alongside the code. SKILL signadot-validate Runs and iterates on every change The agent does not just get feedback it can act on. It gets feedback and iterates. The skill reads the diff, picks the matching plan, spins up a Sandbox with the change wired in, runs the plan, fixes what broke, and re-runs until the change is validated working against the real system. claude - ~/location-service (sandbox) [Install the agent skills from the docs](https://www.signadot.com/docs/integrations/coding-agents/agent-skills) [See the full agentic development workflow](https://www.signadot.com/solutions/agentic-development/) #### Governed by platform teams, used by everyone Plans give agents and developers an expressive validation vocabulary without giving up control over what runs inside the cluster. request-http playwright k6 run-anything ##### Platform-governed catalog The action catalog defines what validation is allowed and what it can touch. Agents compose plans from a vocabulary you control, not arbitrary scripts. 14s validate iterate ##### Fast enough for the inner loop Plans run in seconds against a live Sandbox, so agents validate every iteration as they work instead of waiting for a pipeline at the end. ride-request v1 v2 v3 selectionHint ##### Versioned and rediscoverable Tagged plans with selection hints are rediscovered and rerun across sessions and teams, so validation is written once instead of rebuilt every time. #### Validate against your real system before the PR opens Ship working, agent-generated code at scale with lightning-fast, deterministic validation that runs before the PR opens. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) #### Plans FAQ What is a Signadot Plan? A Plan is a small, reusable validation workflow. It is authored from a natural language prompt, compiled into a sequence of typed action invocations, and stored as a versioned artifact that developers and coding agents invoke by name. Running a plan validates a change end to end against live services in a Sandbox. What are Actions? Actions are the typed, deterministic building blocks Plans are composed from. The catalog includes actions like request-http for API checks, playwright for browser flows, and k6 for load scenarios. Each action is defined in markdown with declared inputs and outputs, checked into a git repo your platform team controls, and synced into the action registry. How do coding agents use Plans? Through two agent skills. The signadot-plan skill authors a new plan from a prompt, tags it, and gives it a selection hint. The signadot-validate skill reads a code diff, picks the matching plan by its selection hint, runs it in a Sandbox against real services, and iterates on failures until the change passes. Both work with the Signadot MCP server or fall back to the CLI. Where do Plans execute? Plan steps run in isolated, rootless execution environments on Plan Runner Group pods inside your Kubernetes cluster. The control plane compiles and schedules the plan, resolves parameters and secrets, and collects outputs and artifacts, while the validation traffic itself stays on your cluster. --- ## Pricing Source: https://www.signadot.com/pricing/ Summary: Flexible pricing based on active sandboxes and testing volume. Free tier for small teams, paid plans scaling with usage. ### Signadot Pricing Sandboxes plus a validation layer of SmartTests, Jobs, and Plans, priced to scale as your team and your coding agents ship more changes. One platform, bundled pricing that grows with you. #### How pricing works Sandboxes are billed per creation. Updates to existing Sandboxes don't count toward billing. Test Invocations are billed each time you run your complete test suite in any Sandbox, regardless of suite size, whether that's E2E tests, integration tests, or SmartTests. We track concurrent devboxes. A devbox is either a local workstation or a Cloud Development Environment (CDE) that integrates with Sandboxes. Sandboxes created per Month 100 Concurrent Devboxes 15 Test Invocations per Month 200 ##### Starter Free Ideal for individual developers. 50 sandboxes/month 100 Test invocations/month 10 Concurrent devboxes 1 Kubernetes cluster 1 Resource Plugin Local Development and Debugging AI Powered Contract Testing Pull Request Previews Run E2E Tests pre-merge Community Slack Support [ Get started *Image: arrow icon*](https://www.signadot.com/signup/) ##### Business $250 /month **Sandboxes created per month** The number of new sandboxes your team creates in a typical month. The Business plan includes 100 sandboxes. Extra sandboxes are billed in blocks of 50. **Concurrent Devboxes** The maximum number of devboxes running at the same time. The Business plan includes 15 concurrent devboxes. Extra capacity is billed in blocks of 5. **Test Invocations per Month** The number of test runs you trigger in a month. The Business plan includes 200 test invocations. Extra tests are billed in blocks of 100. 10% discount for yearly subscription Perfect for small development teams 100 sandboxes/month 200 Test invocations/month 15 Concurrent devboxes Everything in free plus 3 Kubernetes clusters 5 Resource plugins SSO Add On (+$250/month) Community Slack and Email Support _Pricing is a la carte, so you can buy more sandboxes, concurrent devboxes, and test invocations. Excluding the SSO add-on, the maximum monthly spend allowed under this tier is $2,050 per month._ [ Get started ](https://www.signadot.com/signup/) 30 day free trial ##### Enterprise Custom For teams that need support as they grow and want help scaling their testing workflow Custom sandboxes, Test invocations & Concurrent devboxes Unlimited Clusters and Plugins Multi-cluster RouteGroups SSO Integration & SOC2 Report Premium Support (Dedicated Slack) Custom Contracts and Multi-year Discounts Influence on Product Roadmap Dedicated white-glove Pilot [ Contact sales *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* "Signadot for the preview environments use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff that we were looking at. And the return on the investment was obvious... just in infrastructure costs, it saves us about $2 million annually." *Image: Phil Burrows* Phil Burrows Head of Platform Engineering at Brex "Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome." *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer, Wealthsimple #### Savings calculators developer bandwith savings infrastructure cost savings quality savings Developer Bandwidth Savings Calculator Calculate developer time saved from faster cycles with local and PR testing vs. post-merge cycles involving slow CI/staging. Thank you! Your submission has been received! Oops! Something went wrong while submitting the form. annual savings Assumes 48 weeks in a year $1,560,000 Infrastructure Savings Calculator Calculate cost savings from lightweight Sandboxes vs. full environment duplication. Thank you! Your submission has been received! Oops! Something went wrong while submitting the form. Estimated Annual infrastructure Cost Savings Costs when duplicating environments for each developer = #devs x #services x resource per service Costs with Sandboxes  = (#devs + #services) x resource per service $0 Shift left Testing ROI Calculator Calculate savings from catching integration bugs before they reach staging and production. Thank you! Your submission has been received! Oops! Something went wrong while submitting the form. yearly Savings by catching issues pre-merge Estimated costs: Staging bugs $1,500 each, production incidents $10,000 each. $780,000 #### How teams use Signadot AI coding agents and developers use Signadot to validate code changes rapidly in production-like environments. ##### Ad-hoc Testing for Agents & Developers Coding agents and developers spin up lightweight sandboxes to test changes instantly, with no shared staging environment needed. Instant sandbox creation from IDE or CI Works with Cursor, VS Code, and AI coding agents Test against real dependencies in your Kubernetes cluster [ Learn more *Image: arrow icon*](https://www.signadot.com/docs/guides/developer-environments) ##### Automated Testing Pre-merge Run API tests, end-to-end tests, and integration tests in isolated sandboxes on every pull request. Debug issues by inspecting API traffic and cluster data. API, integration, and end-to-end tests in sandboxes Inspect API traffic and cluster data for debugging AI-powered regression detection pre-merge [ Explore testing features *Image: arrow icon*](https://www.signadot.com/product/smart-tests/) #### Frequently asked questions Where is Signadot hosted? The Signadot operator runs securely in your Kubernetes cluster. The Signadot Dashboard and API are hosted in our cloud which runs in AWS. What is the Pricing model? Our pricing is usage-based: you pay for Sandboxes created, Test Invocations, and Concurrent Local Connections. Running signadot job submit or signadot smart-test run counts as one Test Invocation, regardless of how many individual tests execute. You can track your usage in real-time through the dashboard. What are Test Invocations? Test Invocations are a suite of automated tests run by the Signadot operator to compare the behavior of Sandboxed and baseline Microservices. For example, Test Invocations can automatically detect API regressions in Pull Requests using AI models that continuously learn the baseline behavior. How do I estimate the number of Sandboxes and Test Invocations? Start with your monthly pull request volume, but remember you control which PRs get Sandboxes - not every PR needs one. For Test Invocations, it depends on your testing frequency: if you run tests once per PR, expect roughly 1x your Sandbox count. If you run tests on every commit, expect 3-5x your Sandbox count since PRs typically have multiple commits. Concurrent local connections can be estimated at ~ 70-100% of users. How do I pay? For the Business Plan you can pay by credit card or ACH. Please contact us for flexible payment options for the Enterprise plan. What is a Sandbox? Sandboxes represent shadow deployments of Microservices associated with a routing key. Sandboxes enable isolated testing of branch versions of Microservices via selective routing of test traffic. Do you offer a free trial? Yes! We offer a 30 day free trial of the Business plan. The Starter plan is free forever. What security standards does Signadot follow? We follow the best practices around privacy and security. Signadot is SOC 2 Type 2 certified. All data at rest is encrypted and TLS used for network communication. What does Professional Services cover? We offer Professional Services to help with various tasks like Installation & Configuration, CI integration, OpenTelemetry instrumentation and much more. Email us at [info@signadot.com](mailto:info@signadot.com) to learn more. #### Your team is only as fast as your validation loop AI coding agents generate code fast. Signadot makes sure every change actually works before it ships. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) --- # Solutions ## Local Development Source: https://www.signadot.com/solutions/local-development/ Summary: Connect local workstations, CDEs, or agent runtimes directly to your Kubernetes cluster via isolated sandboxes. Develop against real databases, message queues, and microservices instead of mocks. ### Local development for the agentic era Connect local machines or CDEs directly to your Kubernetes cluster. Empower developers and agents to write, run, and verify code against real cloud dependencies without leaving the IDE. "On the margin, with the Signadot approach, 99.8% of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not." *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager, Brex [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Architecture diagram: a browser request flows through an API gateway to cart, user, notification, auth, and config services backed by three databases. A sandboxed copy of user-svc for pull request 42 is spliced into the request path, and an Agent Skills panel shows end-to-end tests, API diff, and contract checks passing.* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Hot reloads for your backend Your agents can generate code in seconds. But validating it still takes 20 minutes in CI. Signadot Local gives developers and agents a fast, high-fidelity feedback loop against real infrastructure. Change code. See it live. Move on. [ Read the docs *Image: arrow right white color*](https://www.signadot.com/docs/tutorials/quickstart/local-development) *Image: Hot reload workflow diagram* #### Standardize the inner loop Empower developers and agents with a uniform way to connect, route, and debug across local and cloud environments. 1 ##### **Connect to your cluster** Run signadot local connect to establish a secure tunnel between any workspace and the cluster. Access cluster services via their DNS names locally. Works from laptops, CDEs, and agent runtimes. *Image: Cluster connection illustration* 2 ##### Define your sandbox Define a simple YAML config that maps traffic from a remote Kubernetes deployment port to your local service port. Agents can interact with our MCP server to manage these definitions dynamically. *Image: Sandbox definition illustration* 3 ##### Start your service locally Run your microservice locally using your preferred setup: Docker, IDE, or native execution. Signadot automatically routes cluster traffic to your local instance for you or your agent to debug. *Image: Local service startup illustration* 4 ##### Hot reload & validate Change code locally and see it live in seconds. Give your coding agents autonomous validation loops against the sandbox to verify end-to-end flows. Find and fix integration issues in seconds, not 20-minute CI cycles. *Image: Hot reload and validation illustration* #### Talk to an engineer Hop on a call with one of our engineers. No slides, no sales pitch. Just you, us, and a whiteboard session. [ Book a technical consult *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) #### **Inspect live traffic. Override any API.** Enhanced debugging with powerful observability and granular control over cluster traffic directly from your laptop or agent workspace. ##### **Record & inspect HTTP/gRPC traffic** Stop guessing based on stale API docs. Record and inspect live request/response payloads between any cluster service. Give your agents the context to understand complex interactions and debug integration issues against systems that nobody wrote documentation for. *Image: Traffic recording and inspection illustration* ##### **Surgically override APIs** Make your code resilient. How does it handle a 5-second latency spike or a 500 error from a dependency? Surgically override any API endpoint to return exactly what you want. Test edge cases, simulate failures, and validate resilience locally in seconds. *Image: API override illustration* #### **Turn agents into validated shippers** Code generation is the easy part. The bottleneck is validation. Give your agents the infrastructure to verify their work end-to-end, so they stop being expensive autocomplete and start actually shipping. *Image: Close the loop illustration* ##### **Close the loop** Give your coding agents the ability to provision environments where they can run, validate, and debug their code end-to-end in a closed loop. *Image: Safe concurrency illustration* ##### **Safe concurrency** Let hundreds of agents explore and iterate autonomously in parallel in safely isolated environments with zero staging-breaking contention. *Image: Flow state illustration* ##### **Maintain flow state** Iterate on AI-generated code as fast as you can prompt. Get instant feedback in your IDE instead of context-switching to wait for a 20-minute CI pipeline. #### **The Signadot MCP Server** Forget learning new YAML. Equip your agents with native tools to manage sandboxes, route traffic, and verify code using natural language. No kubectl. No custom scripts. No ticket to the platform team. The Signadot MCP (Model Context Protocol) Server plugs directly into AI coding tools like Cursor, Claude and Windsurf. [ Read the docs *Image: arrow right white color*](https://www.signadot.com/docs/tutorials/quickstart/local-development) *Image: prompt icon* ##### **Infrastructure as prompts** Agents can provision high-fidelity environments, update image tags, and inject environment variables using natural language commands. *Image: debugging icon* ##### **Autonomous debugging** Have agents inspect live traffic, override API responses, or reproduce production issues to debug autonomously. *Image: multi-agent system icon* ##### **Advanced routing** Enable your agents to create route groups to combine multiple sandboxes, enabling complex integration testing across services. #### **Do it all in local** *Image: Debug complex issues illustration* ##### **Debug complex issues** Reproduce staging or production issues on your local machine. No more "it works on my machine". Get full access to logs, debuggers, and breakpoints against live data to fix human or agent-generated code. *Image: Schema migration validation illustration* ##### **Validate schema migrations safely** Run schema changes locally while connecting to real downstream services to catch integration issues before deployment. *Image: Collaboration illustration* ##### **Unlock true collaboration** Frontend developers, other teams, or autonomous agents can validate against your local backend changes instantly. No deployments, no coordination, and no "is staging free?" messages. #### Standardize once. Rollout everywhere. Signadot Local works with your existing Kubernetes clusters and integrates seamlessly with your IDE, debugger, and local development tools for fast integration testing. [ Read the docs *Image: arrow right white color*](https://www.signadot.com/docs/tutorials/quickstart/local-development) *Image: Local development workflow diagram* Comparing your options first? Read our complete guide to [local development on Kubernetes](https://www.signadot.com/guide-to-local-development-kubernetes/). #### **Unlock developer velocity. Get started in 5 minutes.** [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Book a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) --- ## Preview Environments Source: https://www.signadot.com/solutions/preview-environments/ Summary: Automatically generate shareable preview environments for every pull request. Sandboxes virtualize your cluster by routing traffic to only the changed services, spinning up in seconds. *Image: rocket icon* Preview Environments ### Preview environments on Kubernetes, one per pull request. Give every PR its own preview environment on the Kubernetes cluster you already run. Signadot deploys only the services a change touches and shares the real dependencies around them, so previews spin up in seconds and scale with the PR volume your developers and coding agents create. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Runs on the cluster you already operate *Image: Check mark* A preview URL for every PR, no infra duplication PR #142 checkout service PR #143 payments service PR #144 search service YOUR CLUSTER checkout · fork pr-142.preview ✓ payments · fork pr-143.preview ✓ search · fork pr-144.preview ✓ auth orders db queue cache Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Previewing a change shouldn't mean cloning your whole stack. On Kubernetes, the two usual options both break down: a full environment per PR is too slow and expensive, and one shared staging environment turns into a queue. Coding agents only widen the gap, pushing more PRs than either model can serve. $ $ $ $ $ $ $ $ $ $ $ $ ##### Duplicating doesn't scale Duplicating every service for every PR is slow to provision and expensive to run. Cost climbs with each service and each open PR, so teams ration who gets an environment. PR #142 PR #143 Staging ! ##### Shared staging is a bottleneck When everyone shares one environment, changes queue for their turn, and one bad deploy breaks it for the whole team. Reviewers wait, and integration bugs hide behind each other. PR PR PR ##### Coding agents multiply PRs Agents open changes faster than people ever did. Heavyweight environments can't keep pace, so agent-written code merges with little validation and bugs surface downstream. The Signadot approach #### Fork what changed, share everything else. A Signadot preview forks only the services a change touches and routes everything else to the shared, real dependencies around them. Each PR runs against a complete, production-like system, without copying your stack. PR #142 routing key service-2 checkout checkout PR FORK service-3 db tagged PR request shared cluster PR #142 routing key service-2 checkout checkout PR FORK service-3 db tagged PR request shared cluster 1 Deploy only the delta The preview forks the one or two services the PR modifies. There is nothing to clone and no full stack to rebuild, so it is ready in seconds. 2 Route by request header A routing key travels in the request header across every service call. Keyed requests reach the change; everything else uses the shared cluster. 3 Test against real dependencies The fork plus the shared services present as one complete, production-like stack. For stateful needs, a Resource Plugin can give a PR its own isolated database. 4 Scale to thousands Because every preview reuses the same shared dependencies, thousands run side by side on the cluster you already operate, each torn down when its PR closes. End-to-end previews #### Preview from your real web and mobile apps. A preview is a real, routable environment, not just a backend URL. Point your web frontend or mobile app at it by carrying the preview's routing key, and walk the whole flow end to end against the change while every other dependency is served by the shared cluster. Web app Mobile app API client routing key Preview runs your change SHARED CLUSTER The preview workflow #### From pull request to preview URL, automatically. Every PR gets a preview without a ticket, a queue, or a human in the loop. Your CI applies a sandbox from a template in the repo, the Signadot GitHub App posts the preview URL as a comment, and the environment tears down the moment the PR closes. - **No manual steps**, the same flow for developers and agents - **Preview URL on the PR**, with the routing key to reach it - **Auto-teardown** on merge or close, with a TTL backstop [Set up PR previews in the docs](https://www.signadot.com/docs/guides/set-up-pr-sandboxes) A developer or agent opens a PR push to any service CI applies the sandbox template $ signadot sandbox apply Preview URL posted to the PR pr-142.preview · tests pass PR closes, preview torn down infra reclaimed automatically #### Thousands of previews. On the cluster you already run. Signadot virtualizes preview environments onto your existing Kubernetes cluster. Each one deploys only the services a PR changed and routes everything else to shared real dependencies. Previews spin up in parallel, in seconds, and scale with the PR volume your developers and coding agents create. A preview for every PR Per-PR and per-task previews run side by side, with no queue, no scheduling, and no contention for a shared environment. Seconds to spin up Only the changed services deploy. Everything else routes to shared real dependencies, so there is nothing to clone and no full stack to rebuild. Production-like fidelity Services, message queues, databases, and caches, every layer a change touches, exercised exactly as it runs in production. *Image: Bitso* “We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” *Image: Marcus Tavares* Marcus Tavares Staff Software Engineer, Bitso #### A preview environment per PR, at a fraction of the cost. Bitso replaced its homegrown full-environment-per-PR system with Signadot, giving 250+ engineers and 200+ microservices a lighter, faster preview for every change. [Start for free](https://www.signadot.com/signup/) [Read the Bitso story](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) What you get #### Previews that fit how your team already ships. No hosted platform to migrate to and no SDK to adopt. Previews run on your cluster, with your tools, for both the people and the agents opening PRs. Cross-PR previews with RouteGroups Compose several PRs into a single preview with one URL to test how changes across services behave together, before any of them merge. Bring your own tests Point your existing Playwright, Cypress, or k6 suites at a preview with Signadot Jobs. No framework to migrate and no code changes required. Real dependencies, not mocks Changed services run against the real services, databases, and queues on your cluster, so you validate against production reality instead of an approximation. Runs on your cluster Previews use your existing Kubernetes cluster and ingress. There is no hosted platform and no new URLs to manage, and you reach a preview by request header or the browser extension. Built for coding agents too Each agent task or PR gets its own preview, created through the Signadot MCP server or CLI, so agents validate against real services and open PRs you can trust. Automatic teardown A preview lives while its PR is open and reaps on merge or close, with a global TTL backstop so nothing is left running. Zero orphaned resources. #### Plug into the CI you already run. Pre-built integrations for every major CI and GitOps tool. Add a few lines to your pipeline and your team has per-PR preview environments by the end of the day. Routing works through the built-in DevMesh or your existing service mesh. *Image: GitHub Actions* GitHub Actions Drop in the Signadot Action. Per-PR previews, preview URLs posted as PR comments, auto-teardown on merge. *Image: GitLab CI* GitLab CI Pipeline templates for per-MR previews that tear down on merge or close. *Image: Jenkins* Jenkins Shared library plus CLI calls. Existing pipelines pick up preview provisioning in a few lines. *Image: Bitbucket Pipelines* Bitbucket Pipelines Pipe definitions for per-PR previews. Works with self-hosted and cloud runners. CircleCI Orbs and CLI integration. The same per-PR lifecycle, wired into your existing workflows. ArgoCD Manage previews as Signadot Sandboxes alongside your GitOps workflow. [Browse all CI and GitOps integrations](https://www.signadot.com/integrations/) #### A preview environment for every change, built for the scale of agentic development. Give every developer and every coding agent a lightweight preview for every PR, scalable to thousands running in parallel on the cluster you already run. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) #### Preview Environments FAQ What is a preview environment? A preview environment is an on-demand, isolated deployment created automatically for a pull request, so the change can be reviewed and tested before it merges. With Signadot, each preview deploys only the services the PR changed and routes everything else to the real services and dependencies already running on your cluster. It spins up in seconds and tears down when the PR closes. How does Signadot create a preview environment for each pull request? When a PR opens, your CI applies a sandbox from a template stored in the repo. Signadot forks only the changed workload onto your existing Kubernetes cluster and assigns it a routing key. Requests carrying that key, in a standard request header propagated across service calls, reach the changed service; every other request falls through to the single shared environment with real dependencies. Nothing else is copied, so the preview is ready almost immediately. How is this different from spinning up a full environment or namespace per PR? Cloning the whole stack into a namespace or cluster per PR is faithful but slow and expensive, and the cost grows with every service and every open PR. Signadot deploys only the diff and shares the rest of the cluster, so each preview stays lightweight, starts in seconds, and thousands run side by side on the cluster you already operate. How do preview environments fit into CI/CD and GitHub? Add a few lines to your pipeline to apply a sandbox on PR open. The Signadot GitHub App posts the preview URLs and routing key as a PR comment, and deletes the environment automatically when the PR merges or closes. Pre-built integrations exist for GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines, CircleCI, and ArgoCD, with a TTL backstop so nothing is left running. Can preview environments keep up with the PR volume coding agents create? Yes. Coding agents push far more PRs than a queue of full-stack environments can serve. Because each Signadot preview is just a diff on a shared cluster rather than a full copy, previews scale with PR volume without scaling infrastructure. Each agent task or PR gets its own preview, created through the Signadot MCP server or CLI, so developers and agents share the same fast, lightweight workflow. Can I run my existing tests against a preview environment? Yes. There is no SDK to adopt and no framework to migrate to. Point your existing Playwright, Cypress, or k6 suites at a preview using Signadot Jobs, or open the preview URL directly. Tests run against the changed services and the real dependencies on your cluster, not mocks or stubs. New to the model? Read our complete guide to [preview environments in Kubernetes](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/). --- ## Microservices Testing Source: https://www.signadot.com/solutions/microservices-testing/ Summary: Run end-to-end tests (Cypress, Playwright, Selenium) against isolated sandboxes on every commit. Each sandbox contains only the changed services within your existing cluster. *Image: rocket icon* Microservices Testing Platform ### Microservices testing, solved for the agentic era. Shift integration, end-to-end, performance, chaos, and security tests left, into the inner loop. Every developer and every coding agent validates their changes against real services before code lands. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* No credit card required *Image: Check mark* Playground cluster available coding agent PR #423 coding agent PR #424 coding agent PR #425 KUBERNETES CLUSTER shared ENV · pr-423 isolated integration 24 / 24 ENV · pr-424 isolated e2e 18 / 18 ENV · pr-425 isolated regression 42 / 42 Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### **Why traditional microservices testing fails at scale** Microservices multiply the things that can go wrong between services. The harder the system gets to test, the more teams fall back on shared staging, brittle mocks, and merge-and-pray. None of that survives the agent era. unit.test 12 passed mocked production real svc broken ##### Mocks lie, integration bugs hide Unit tests with mocked dependencies pass locally and break in production. Cross-service issues only surface when services talk to each other for real, which is too late if you only find out post-merge. STAGING queue: 12 waiting ##### Shared staging is the bottleneck When every developer, every PR, and every CI run hits the same staging cluster, tests fail because of collisions, not real bugs. Engineers spend more time triaging environments than reading diffs. cluster · dev-1 CLOUD COST $$$$ per dev × every developer ##### Full-stack copies do not scale Replicating a hundred-service stack for every engineer and every PR is impossible. The cloud bill alone kills the idea before you finish the design doc. review queue ##### Coding agents make the gap worse Agents generate microservices changes faster than humans can review them. Without a way to run integration and end-to-end tests against real services on every change, the reviewer becomes the verification layer and the queue keeps growing. #### Agents can only validate what they can run. Static checks like unit tests, types, and lint are easy to shift left. The runtime tests that catch real microservices bugs only run when developers and agents can hit real services. Signadot brings the full runtime test surface into the inner loop on every change. Static analysis Runtime Without Signadot Agents fall back to local checks unit tests types lint integration e2e contract performance chaos security With Signadot Real dependencies, every change unit tests types lint integration e2e contract performance chaos security #### How Signadot solves microservices testing Shift integration, end-to-end, performance, contract, chaos, and security tests left into the inner loop for developers and coding agents, and into pre-merge gates for every PR. 1 ##### **Shift left across the full test surface** Run integration, end-to-end, performance, contract, chaos, and security tests on every change instead of waiting for staging. Catch the cross-service bugs that only show up against real dependencies in the inner loop, not after merge. SHIFT LEFT integration e2e contract performance chaos security inner loop pre-merge staging prod 2 ##### **Plans: composable, agent-native validation** Platform teams define reusable Actions: deploy a Sandbox, run a test suite, capture and replay traffic, gate a merge. Developers and agents compose them into Plans for repeatable, agent-native validation workflows. PLAN payment-validation deploy Sandbox run integration + e2e capture and replay traffic gate merge 3 ##### **Jobs: managed test execution** Jobs is Signadot's managed test execution framework. Each Job runs in its own Kubernetes pod and exercises the APIs and frontends routed through your Sandboxes. Bring Playwright, Cypress, k6, or any custom runner. Signadot handles scheduling, isolation, and CI integration. Playwright Cypress k6 custom SIGNADOT JOB managed test execution hits Sandbox *Image: Wealthsimple* “Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome.” *Image: Tyler Marien* Tyler Marien Senior Software Developer, Wealthsimple #### Give your agents more autonomy. Let every coding agent validate microservices changes end to end in its own ephemeral environment, against your real cluster. Reviewers see code that has already passed your tests. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### Microservices testing, built for coding agents. Coding agents like Claude Code, Cursor, Codex, and Copilot generate microservices changes faster than humans can review them. Signadot gives every agent the same inner-loop feedback your developers get, against real dependencies on your own cluster. agent task #7 ENV task-7 integration ok e2e ok regression rerun iterate ##### Inner-loop validation for agents Each agent spins up its own ephemeral environment, runs integration and end-to-end tests against real microservices, and iterates on failures before it ever opens a pull request. agent agent agent MCP SERVER CREATE ROUTE QUERY ##### Native MCP server Any MCP-compatible agent can create, manage, and route to ephemeral environments through natural language. The agent drives its own environment, your platform team keeps the guardrails. feat: add idempotency to payment #423 · opened by agent integration · 24 / 24 passed e2e · 18 / 18 passed regression · 42 / 42 passed all checks passed MERGE ##### Validated pull requests, not draft code Every change an agent submits has already cleared your integration, end-to-end, and regression tests against real services. Reviewers spend time on judgment, not triage. [See the docs](https://www.signadot.com/docs/integrations/mcp) #### Microservices Testing FAQ What is microservices testing and why is it hard? Microservices testing is the practice of validating that each service in a distributed system behaves correctly on its own and in combination with the services around it. It is hard because the bugs that matter most live in the seams between services. Unit tests with mocked dependencies cannot catch them, and replicating the full stack for every engineer or every pull request is too expensive to be practical. How is microservices testing different from monolithic testing? In a monolith, end-to-end testing is mostly a single deployment and a test suite. In microservices, end-to-end testing requires running your service alongside dozens or hundreds of real dependencies, with stateful resources like databases and queues behaving the way they do in production. The infrastructure problem is the testing problem. Can I do microservices testing without a full staging environment? Yes. Signadot gives you lightweight ephemeral environments that share a single baseline cluster. Only the services you changed are deployed into the new environment. Every other service stays on the shared baseline. You get production-like fidelity without duplicating the stack. How does Signadot handle databases and message queues in tests? Signadot provides resource plugins for spinning up temporary databases on demand and multi-tenancy support for shared message queues like Kafka and SQS. You get realistic state and realistic async behavior without rewriting your application to know about test mode. How do coding agents use Signadot? Coding agents connect through the native MCP server or the Signadot CLI. The agent spins up its own ephemeral environment per task, runs integration and end-to-end tests against your real services, and iterates on failures inside its own loop. The pull request that lands on a reviewer's desk has already cleared your validation logic. Does Signadot replace human review? No. Signadot widens what an agent or a developer can verify on their own before review. Reviewers still own merge decisions. The difference is that the work landing on their queue has already been validated end to end, so review time gets spent on judgment instead of triage. How fast can I get started? Signadot runs on your existing Kubernetes cluster. The Playground cluster is available for free with no credit card. Most teams have their first ephemeral environment running in their own cluster within an afternoon. #### Ship microservices code at agent speed. Give your coding agents an ephemeral Kubernetes environment per task and let them validate every change end to end before a human ever opens the PR. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) --- ## Agentic Development Source: https://www.signadot.com/solutions/agentic-development/ Summary: Enable autonomous coding agents to provision sandboxes, run tests, and validate the code they write via the Signadot MCP server. Supports Cursor, Claude Code, VSCode, and any MCP-compatible tool. *Image: rocket icon* Coding Agents ### Your coding agent writes, tests, and fixes in a closed loop. Signadot gives coding agents everything they need to validate microservices code in their inner loop: ephemeral environments, agent-callable Plans and Skills, and a native MCP server. [Create a Sandbox](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* No credit card required *Image: Check mark* Playground cluster available Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Agents generate code. They can't verify it. Without infrastructure to test against real dependencies, developers become the verification layer and AI productivity gains vanish. unit.test mocked integration.test no services e2e.test no services ##### Limited to unit tests Without real services to run against, agents can verify functions in isolation but never end-to-end behavior across your stack. Agent · PRs PR #142 awaiting PR #143 awaiting PR #144 awaiting Review queue +12 ##### Slower code reviews Agents push PRs with minimal validation, leaving reviewers to confirm the code actually works. code PR merge bug ##### Bugs surface post-merge Integration issues only appear after merge, creating slow feedback cycles and disruptive fixes. #### Signadot closes the loop Give your coding agents the tools to write, test, and debug against real dependencies until their code is correct. retry on test fail 1 Spin up env 2 Write code 3 Build & run 4 Run tests 5 Debug Validated PR ##### Spin up environment The agent uses Signadot's MCP server to provision an ephemeral environment in your Kubernetes cluster. Local services are wired to live remote dependencies in seconds. ##### Write code The agent generates code to make a change to a service. ##### Build and run locally Code is built and run on the developer's machine, with traffic routed through the ephemeral environment so the local process talks to real cluster services. ##### Run E2E / integration tests Integration and end-to-end tests execute against the ephemeral environment, hitting real services. No mocks, no flakes from missing dependencies. ##### Debug When tests fail, the agent reads logs, captures traffic, and inspects environment state to diagnose the issue, then loops back to write the fix. Once tests pass, it publishes a validated PR. Ephemeral env Your Machine Local services MCP K8s Cluster Remote services ServicesStatus api-gatewaybaseline payments-svcactive auth-svcbaseline ✓ Environment **pr-431-payments** ready in 2.1s handler.go 14func HandlePayment(w http.ResponseWriter, r \*http.Request) { 15 key := r.Header.Get("Idempotency-Key") 16 if cached, ok := store.Get(key); ok { 17 json.NewEncoder(w).Encode(cached) 18 return 19 } 20 if store.IsExpired(key) { 21 http.Error(w, "key expired", 409) 22 return 23 } 24 result := processPayment(r) 25 store.Set(key, result, 24\*time.Hour) 26} ~/payments-service $ go build ./cmd/payments → 12 packages compiled in 1.4s → binary: ./bin/payments-svc $ ./bin/payments-svc --env=pr-431 \[info\] listening on :8080 \[info\] traffic routed via env/pr-431 \[info\] connected → postgres@db.svc \[info\] connected → redis@cache.svc \[info\] connected → kafka@bus.svc ● ready, receiving routed traffic Test Results ✓checkout.e2epass ✓auth.e2epass ✕payment.e2efail Assertion Error POST /payments (expired key) returned 500 Expected: 409 Conflict 2 passed · 1 failed · 4.2s debug · pr-431 ◆ Inspecting captured request for payment.e2e... → tail -f logs/payments-svc | grep idem 10:42:01 store.Get(key) → nil, ttl=expired 10:42:01 processPayment() called, missing IsExpired() guard → signadot capture --env pr-431 --route /payments req POST /payments Idempotency-Key: k\_842 (expired) res 500 internal server error ◆ Root cause: expiry check runs after processing. Reordering checks and looping back. #### One cluster. Thousands of agent environments. Signadot virtualizes environments onto your existing Kubernetes cluster. Every agent gets its own isolated stack, spinning up in seconds. No duplicated infrastructure, no coordination, no contention. Thousands of agents Every agent gets an isolated sandbox. Run them in parallel with no coordination or contention. Seconds to spin up Virtualized environments share stable dependencies in the cluster. No Docker builds. No cluster duplication. Full-stack fidelity Services, message queues, databases, caches - every layer an agent's code touches. Signadot Plans #### Validation, reimagined for coding agents. Plans give coding agents fast, governed validation in their inner loop, against the real services your code ships into. 01 ##### Define the Actions catalog. Actions are atomic, deterministic validation building blocks, like `request-http`, `playwright`, and `k6`. The platform team governs which Actions are made available. [Actions catalog on GitHub](https://github.com/signadot/actions) signadot/actions request-http playwright k6 check 02 ##### `signadot-plan` builds a Plan from Actions. Plans are small validation workflows an agent composes from the available actions. Commit and version them so the same validation is reused across the org. [Skills documentation](https://www.signadot.com/docs/integrations/coding-agents/agent-skills) agent session \> signadot-plan create a plan that walks the checkout flow and verifies the payment is captured drafting from the action catalog… ✓ created plan "checkout-flow" actions: playwright, request-http committed to .signadot/plans/ Run it now against a sandbox? (y/n) 03 ##### `signadot-validate` scans the library and runs the right one. `signadot-validate` reads the diff, picks the matching plan by its selection hint, and runs it in a Sandbox against real services. The agent fixes whatever broke and re-runs until it passes, before any human sees the code. [Plan-based validation quickstart](https://www.signadot.com/docs/tutorials/quickstart/plan-based-validation) DIFF signadot-validate picks the matching plan PLAN checkout SANDBOX playwright runs against real services ✓ passed · PR ready for review Platform-governed action catalog Platform teams curate the actions available to coding agents, giving them a safe, expressive vocabulary to compose tests from. Blazing fast, inner-loop ready Plans run in seconds, fast enough for coding agents to validate every change as they iterate, not at the end of a long pipeline. Tagged and reusable Validated plans are tagged with selection hints that tell agents when to run them, so the same validation is rediscovered and rerun across sessions instead of rebuilt every time. #### Same prompt. Very different outcomes. Two agents given the same task. One validates with unit tests and linter. The other validates against live services on a Signadot sandbox, and catches what the first one misses. Without Signadot Unit tests & linter claude - ~/location-service Ships broken consumers Unit tests pass. But downstream services crash on the schema change. Agent never sees the failures. With Signadot Real validation against live services claude - ~/location-service (sandbox) Ships verified code Caught 3 consumer breakages. Iterated until every downstream service passed. PR ready for review. Works with every coding agent *Image: Claude Code logo* *Image: Cursor logo* *Image: OpenAI logo* *Image: Windsurf logo* *Image: Zed logo* *Image: Claude Code logo* *Image: Cursor logo* *Image: OpenAI logo* *Image: Windsurf logo* *Image: Zed logo* *Image: Claude Code logo* *Image: Cursor logo* *Image: OpenAI logo* *Image: Windsurf logo* *Image: Zed logo* Native MCP Server #### Signadot MCP Server Native Model Context Protocol server that any MCP-compatible agent can use. Agents reach for Sandboxes, route traffic, and inspect cluster state through natural language, alongside the Plans and Skills they call out to. Sandbox Operations Create, list, update, and manage sandboxes. Add fork workloads, configure local mappings, and resolve preview endpoints. Discovery & Infrastructure List clusters, discover in-cluster workloads and service endpoints, browse available resource plugins and devboxes. Route Group Management Create and manage route groups, configure sandbox labels for targeting, and resolve preview endpoints for multi-sandbox routing. [ MCP server docs *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp) Coding Agent Claude Code, Cursor, etc. MCP SERVER Model Context Protocol Sandboxes Create & manage Fork workloads Preview endpoints Discovery List clusters Find workloads Service endpoints Routing Route groups Sandbox labels Multi-sandbox routing KUBERNETES CLUSTER sb #### Coding Agents FAQ What is a coding agent environment? A coding agent environment is the runtime where an AI coding agent does its work: the codebase, the services it calls, the dependencies it tests against, and the routing that lets it operate alongside production-shape infrastructure without breaking anything else on the cluster. Signadot provides this environment as a per-task overlay on your existing Kubernetes cluster. How do I give Claude Code access to real services? Claude Code connects to Signadot through the native MCP server or the Signadot CLI. The agent calls a single command to create a per-task environment that includes the services it changed plus access to every real service in your cluster. From Claude Code, the agent can run tests, hit real endpoints, and inspect responses against production-shape data. How does Cursor background agents work with Signadot? Cursor background agents that run remotely need a real environment to test in. Signadot gives each background agent its own ephemeral environment with full cluster access. The agent spins up the environment, exercises it, and tears it down without contending with developers or other agents. Does this replace local development for agents? No. Agents can still run code locally for fast iteration. Signadot sits underneath as the integration target: the place an agent reaches when it needs to talk to a database, hit a downstream service, or run an end-to-end test. Local development and the Signadot environment share the same routing model. How is this different from giving agents a sandbox VM? A sandbox VM gives an agent a sealed-off box with no real services. Signadot environments are connected: the agent runs in your real Kubernetes cluster, reaches the real services and dependencies it would hit in production, and tests against production-shape topology. The agent is isolated from other tasks, not from production-shape infrastructure. Which agents are supported? Anything that speaks the Model Context Protocol or can shell out to a CLI. Claude Code, Cursor, Codex, Windsurf, Aider, Continue, Zed, and custom in-house agents all work. The MCP server exposes Signadot environment operations as tools the agent can call directly through natural language. Can a platform team govern what agents can do? Yes. Environment creation and routing happen through the Signadot control plane, which supports RBAC, audit logs, per-cluster quotas, and resource limits. Platform teams keep the guardrails. Agents get autonomy inside them. #### Review verified code, not AI drafts. Give your coding agents the environments, Plans, and Skills they need to close the loop. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Coding Agent Environments Source: https://www.signadot.com/solutions/coding-agent-environments/ Summary: Production-shape Kubernetes environments for Claude Code, Cursor background agents, Codex, and Windsurf. Real services and dependencies with per-task isolation. *Image: rocket icon* Coding Agent Environments ### A real environment for every coding agent. Production-shape Kubernetes environments for Claude Code, Cursor background agents, Codex, and Windsurf. Real services, real dependencies, per-task isolation. The code your agent ships has been validated against your real infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Native MCP server *Image: Check mark* Per-task isolation \+ your agent MCP YOUR CLUSTER PER-TASK ENV payment fork auth orders search notify price ship Postgres · Kafka · Stripe Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### **Coding agents are flying blind.** Agents building microservices and cloud-native software need real services to call. Without an environment that mirrors production, an agent can write code but can't exercise it. It falls back to mocks, opens a PR, and the burden of review lands on the engineers around it. ›\_ auth api pay ord ship ntfy cat srch prc Postgres Kafka ##### No services to call Running locally or in a sealed sandbox VM, the agent can't reach the real services and dependencies the production system runs on. The code compiles. Whether it actually works in a microservices topology is anyone's guess. STAGING conflict ##### Shared staging doesn't scale One staging cluster can't host every developer and every background agent at once. Agents queued against staging spend their day blocked, retrying, or breaking each other's tests. PR ##### Review burden lands on engineers When an agent can't exercise its own code, engineers absorb the work in review. PR queues grow faster than humans can clear them, and the rollback rate climbs with the volume. #### **Kubernetes environments built for coding agents.** An ephemeral environment for every task. Real services on every call, thousands of environments on the cluster you already run, validation that happens before review. ›\_ auth api pay ord ship ntfy cat srch prc Postgres Kafka ##### Real services on every call When the agent needs to exercise its code, Signadot exposes the real services and dependencies the production system runs on. The agent validates against the same topology it will face in production, not a mock layer that drifts. YOUR CLUSTER env-1 env-2 env-3 env-4 env-5 … env-6 env-7 env-8 env-9 env-10 … env-11 env-12 env-13 env-14 env-15 … SHARED STABLE DEPENDENCIES ##### Thousands of environments, one cluster Each task gets its own environment. Only the services the agent changed run as forks, and everything else stays on shared stable dependencies. Thousands of tasks run in parallel on the same cluster. ENV agent PR #427 ##### Validation before review Inside its environment, the agent runs broad validation and debugs failures with skills. PRs land already cleared end-to-end, so reviewers spend time on judgment, not triage. *Image: Bitso* “We basically stopped creating full preview environments and replaced our custom solution with Signadot. The strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” *Image: Marcus Tavares* Marcus Tavares Staff Software Engineer, Bitso #### Plug your agents into your real cluster. Connect any MCP-compatible agent in minutes. Your agents reach real services, run real tests, and ship code that has already been validated against production-shape infrastructure. [Start for free](https://www.signadot.com/signup/) [Read the Bitso story](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) *Image: rocket icon* How it works #### Realistic runtime, without duplicating the cluster. Each task runs in its own ephemeral environment. Only the services the agent changed run as forks inside the environment. Traffic from the agent's code traverses real services end-to-end, landing on the fork where one exists and on shared stable dependencies everywhere else. - **One cluster, many environments.** Tasks share the same stable dependencies, and only the services the agent changed run as forks. - **Per-task isolation.** Each agent sees the changes it made, not the changes other agents are testing in parallel. - **Real services on every call.** Validation runs against the topology and data shapes the agent will face in production. - **Seconds to provision.** The agent calls MCP, gets an environment, and is exercising real services in seconds. agent A task-7 edits: payment agent B task-8 edits: search YOUR CLUSTER auth orders task-7 fork payment +diff notify Post- gres auth catalog task-8 fork search +diff orders Kafka SHARED STABLE DEPENDENCIES (WHITE) · TASK FORKS (HIGHLIGHTED) #### Whichever agent you pick, Signadot is the environment. Same MCP-driven environment, every major coding agent. No lock-in, no per-tool integration. *Image: Claude Code logo* *Image: Cursor logo* *Image: Codex logo* *Image: Windsurf logo* *Image: Zed logo* Bring your own agent Connect any agent through the documented MCP tool surface or the Signadot CLI. No agent-specific lock-in. *Image: rocket icon* Agent-native tooling #### Built for agents to drive end to end. Signadot exposes the cluster through MCP & CLI, composable Actions and Plans, and a library of agent skills. Together they let agents autonomously provision environments, run broad validation on their changes, and debug failures without a human in the loop. Your platform team keeps the guardrails through the same control plane developers use. [Read the docs](https://www.signadot.com/docs/integrations/mcp) MCP & CLI Direct interfaces the agent drives end to end. Provision environments, route traffic, ship Jobs, and inspect state through natural language or scripts. Actions & Plans Actions are reusable units of work: run a test Job, seed a fixture, flip a feature flag, hit a smoke endpoint. Platform engineers and developers author Actions once. Developers and agents compose them into Plans that match the workflow for a given change. Plans run on every task and stream results back into the agent loop. Agent skills Packaged capabilities for provisioning, validation, and debugging. Reused by the agent across every task so behavior stays consistent. #### Coding Agent Environments FAQ What is a coding agent environment? A coding agent environment is the runtime where an AI coding agent does its work: the codebase, the services it calls, the dependencies it tests against, and the routing that lets it operate alongside production-shape infrastructure without breaking anything else on the cluster. Signadot provides this environment as a per-task overlay on your existing Kubernetes cluster. How do I give Claude Code access to real services? Claude Code connects to Signadot through the native MCP server or the Signadot CLI. The agent calls a single command to create a per-task environment that includes the services it changed plus access to every real service in your cluster. From Claude Code, the agent can run tests, hit real endpoints, and inspect responses against production-shape data. How does Cursor background agents work with Signadot? Cursor background agents that run remotely need a real environment to test in. Signadot gives each background agent its own ephemeral environment with full cluster access. The agent spins up the environment, exercises it, and tears it down without contending with developers or other agents. Does this replace local development for agents? No. Agents can still run code locally for fast iteration. Signadot sits underneath as the integration target: the place an agent reaches when it needs to talk to a database, hit a downstream service, or run an end-to-end test. Local development and the Signadot environment share the same routing model. How is this different from giving agents a sandbox VM? A sandbox VM gives an agent a sealed-off box with no real services. Signadot environments are connected: the agent runs in your real Kubernetes cluster, reaches the real services and dependencies it would hit in production, and tests against production-shape topology. The agent is isolated from other tasks, not from production-shape infrastructure. Which agents are supported? Anything that speaks the Model Context Protocol or can shell out to a CLI. Claude Code, Cursor, Codex, Windsurf, Aider, Continue, Zed, and custom in-house agents all work. The MCP server exposes Signadot environment operations as tools the agent can call directly through natural language. Can a platform team govern what agents can do? Yes. Environment creation and routing happen through the Signadot control plane, which supports RBAC, audit logs, per-cluster quotas, and resource limits. Platform teams keep the guardrails. Agents get autonomy inside them. #### Give your agents a real place to work. Spin up production-shape Kubernetes environments per task. Claude Code, Cursor, Codex, Windsurf, or your in-house agent reach the same cluster, the same services, and the same dependencies you ship to production. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) --- ## Ephemeral Environments Source: https://www.signadot.com/solutions/ephemeral-environments/ Summary: Lightweight per-change environments that virtualize your Kubernetes cluster. Real services and dependencies, ready in seconds and gone when the change ships. *Image: rocket icon* Ephemeral Environments ### An ephemeral environment for every change. Give every developer and every coding agent a lightweight per-change environment that virtualizes your Kubernetes cluster. Real services, real dependencies, ready in seconds and gone when the change ships. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Runs on the cluster you already operate *Image: Check mark* Plugs into any CI and any coding agent ephemeral environment live auth orders db queue shared stable dependencies payments YOUR CHANGE \- order.ProductId \+ order.ProductCode validation Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* The Signadot approach #### A full-stack environment per change, without the full-stack price. Signadot virtualizes your stack. It deploys only the services a change touches and routes everything else to the shared stable dependencies already running. Each change gets a real, full-stack environment that stays lightweight because nothing else is copied. Cloning the cluster per change is faithful but slow and costly. A shared staging environment is cheap but turns into a queue. Signadot gives every change its own environment while thousands share one staging cluster, with no contention. [Read the architecture in the docs](https://www.signadot.com/docs/concepts/sandbox) The traditional options Clone the cluster per change $$$ Faithful, but slow to spin up and far too expensive to give everyone one. One shared staging environment queue Cheap, but every change competes for the same environment and waits its turn. Signadot replaces both A new approach Signadot scalable A virtualized full-stack environment per change. Lightweight, isolated, and ready in seconds, with no queue. How it works #### Fork what changed, share everything else. A Signadot Sandbox is an ephemeral environment. It doesn't rebuild your stack. You fork only the few services your change touches. Everything else runs on your existing integration/staging cluster. Isolation fits the dependency: requests route to the forked service, while a stateful one like a database can get its own ephemeral copy. Your change runs against a real, full-stack system. request service-2 service-1 service-1b FORK service-3 db tagged request shared dependencies request service-2 service-1 service-1b FORK service-3 db tagged request shared dependencies 1 Deploy only the delta A change forks the one or two services it modifies. There is nothing to clone and no full stack to rebuild, so the environment is ready in seconds. 2 Route the rest to shared deps Every request the fork does not own falls through to the shared stable dependencies already running, including services, databases, queues, caches, and third-party APIs. 3 Virtualize the full stack The fork plus the shared dependencies present as one complete, production-like stack. The change is exercised end to end, not against mocks or a drifting copy. 4 Scale to thousands Because each environment reuses the same shared dependencies, thousands run side by side on the cluster you already operate. Each tears down when its change ships. #### Thousands of full-stack environments, virtualized onto your cluster. Signadot virtualizes ephemeral environments onto the Kubernetes cluster you already run. Each one duplicates only the services that changed and routes everything else to shared stable dependencies. Thousands spin up in parallel, in seconds. Thousands in parallel Per-PR, per-task, and per-developer environments run side by side, with no queue, no scheduling, and no contention. Seconds to spin up Only the changed services deploy. Everything else routes to shared stable dependencies, so there is nothing to clone and no Docker builds to wait on. Full-stack fidelity Services, message queues, databases, caches, and third-party APIs. Every layer a change touches, exactly like production. *Image: Brex* “Signadot for this use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff we were looking at. Just in infrastructure costs, it saves us about $2 million annually.” *Image: Phil Burrows* Phil Burrows Head of Platform Engineering, Brex #### Every environment your team needs, on the cluster you already run. Replace cluster clones and staging queues with ephemeral environments that share your existing stack. Most teams have their first one running in an afternoon. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### One primitive, every workflow. The same ephemeral environment serves the whole team: a developer's inner loop, a coding agent's validation run, and the final check before merge. Coding agents #### Give agents a real cluster to validate against. Coding agents need real services to test against. Each agent task gets its own ephemeral environment, isolated from every other task and created through the Signadot MCP server in natural language. The agent runs end-to-end, fixes what breaks, and opens a PR you can trust. - **One environment per task**, isolated and reaped fast - **Native MCP server** for agent-driven provisioning - **Same governance** as developer environments: RBAC, audit, quotas [Agent-native platform](https://www.signadot.com/solutions/agentic-development/) [Coding agent docs](https://www.signadot.com/docs/integrations/coding-agents) agent env · task-7 TTL: 1h agent env · task-8 TTL: 30m agent env · task-9 TTL: 2h $ signadot local connect your laptop hot reload YOUR CLUSTER your service auth orders db queue shared stable deps Local development #### Code locally, run against the real stack. Run the service you are changing on your laptop and route it into an ephemeral environment on the cluster. Your local code talks to real dependencies, with hot reload and no image builds, and without running the full stack on your machine. - **No full-stack on your laptop**, just the service you own - **Live traffic and API overrides** for fast debugging - **Real dependencies**, not mocks or a drifting local copy [Local development](https://www.signadot.com/solutions/local-development/) [Local development docs](https://www.signadot.com/docs/guides/local-development) Pre-merge PR validation #### Catch integration bugs before merge. When a PR opens, your CI provisions an ephemeral environment for the change. Reviewers open a live URL, end-to-end tests run against real services, and the environment tears down automatically when the PR merges or closes. The integration break shows up on the PR, not three steps downstream in staging. - **A preview URL per PR**, posted as a comment - **E2E against real dependencies**, not mocked stubs - **Auto-teardown** on merge or close, with TTL backstop [Preview environments](https://www.signadot.com/solutions/preview-environments/) [CI/CD integration docs](https://www.signadot.com/docs/guides/integrate-ci) PR opens, CI provisions an environment $ signadot sandbox apply Preview URL posted to the PR pr-423.preview · reviewers click E2E runs against real dependencies 42 passed · 0 failed PR merges, environment torn down infra reclaimed automatically #### Plug into the CI you already run. Pre-built integrations for every major CI and GitOps tool. Add a few lines to your pipeline and your team has per-PR ephemeral environments by the end of the day. Routing works through the built-in devmesh or your existing service mesh. *Image: GitHub Actions* GitHub Actions Drop in the Signadot Action. Per-PR environments, preview URLs as PR comments, auto-teardown on merge. *Image: GitLab CI* GitLab CI Pipeline templates for per-MR environments that tear down on merge or close. ArgoCD Manage ephemeral environments as Signadot Sandboxes alongside your GitOps workflow. *Image: Jenkins* Jenkins Shared library plus CLI calls. Existing pipelines pick up environment provisioning in a few lines. *Image: Bitbucket Pipelines* Bitbucket Pipelines Pipe definitions for per-PR environments. Works with self-hosted and cloud runners. CircleCI Orbs and CLI integration. The same per-PR lifecycle, wired into your existing workflows. [Browse all CI and GitOps integrations](https://www.signadot.com/integrations/) #### Lightweight ephemeral environments built for agentic scale. Give every developer and every coding agent a full-stack environment for every change and every PR, scalable to thousands running in parallel on the cluster you already run. [Start for free](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) #### Ephemeral Environments FAQ What is an ephemeral environment? An ephemeral environment is a short-lived, full-stack environment that exists for the lifetime of a single change. With Signadot, it is a lightweight per-change environment that virtualizes your Kubernetes cluster. Only the services that changed are deployed, and every other request routes to shared stable dependencies. The environment spins up in seconds and tears down when the change ships. Are Signadot Sandboxes the same as ephemeral environments? Yes. A Signadot Sandbox is an ephemeral environment. It is the core primitive the platform is built on, used for local development, pull request validation, integration testing, and coding agent runs. How is this different from cloning a cluster per change? Cloning the whole cluster for every change is slow and expensive, and it caps out long before a team can give every change its own environment. Signadot takes a different path. Each environment duplicates only the changed services and routes the rest to shared stable dependencies, so thousands run in parallel on the cluster you already operate. How do ephemeral environments work with coding agents? Each agent task gets its own ephemeral environment, isolated from every other task, created through the Signadot MCP server in natural language. The agent runs end-to-end against real dependencies, fixes what breaks, and opens a PR that is already validated. Per-task environments reap quickly when the run finishes. How do they fit into CI and GitOps? When a PR opens, your CI calls Signadot to create the environment, posts a preview URL, and tears it down on merge or close. Pre-built integrations exist for GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines, and CircleCI. With ArgoCD, you can manage environments as Signadot Sandboxes alongside your GitOps workflow. How does request routing work? Signadot routes requests for a change into that change's environment and sends everything else to shared stable dependencies. It uses the built-in devmesh for HTTP and gRPC, or your existing service mesh (Istio or Linkerd), with standard header propagation. See the docs for the routing details. How long do ephemeral environments live? As long as the change they represent. A PR environment lives while the PR is open. An agent task environment lives for the run. Platform teams can set a global TTL so anything left behind is reaped automatically. --- ## Kubernetes Test Environments Source: https://www.signadot.com/solutions/kubernetes-test-environments/ Summary: Give every developer, PR, and coding agent a real Kubernetes test environment on the staging cluster you already run, with no contention. *Image: rocket icon* Kubernetes Test Environments ### Kubernetes test environments for every change. Lightweight ephemeral environments on the staging cluster you already run. Every developer, every PR, and every coding agent gets a real Kubernetes test environment with no contention. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Check mark* Runs on your existing cluster *Image: Check mark* Scales to hundreds of envs KUBERNETES CLUSTER env-1 pass env-2 run env-3 pass env-4 run env-5 pass env-6 run env-7 pass env-8 run env-9 pass env-10 env-11 env-12 Tests running in parallel integration end-to-end regression Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### **Testing on Kubernetes requires a real runtime.** The bugs that matter live between services. Catching them requires a realistic runtime with the real services, queues, and databases your app depends on. ##### The bugs live between services In a microservices system, the failures that reach production tend to live at the seams between services: contract drift, timing races, partial outages, retry storms. Unit tests do not surface them and shared staging rarely reproduces them. See the [complete guide to staging environments](https://www.signadot.com/staging-environments/) for why. STAGING queue: 12 waiting ##### Shared staging is a queue, not an environment When every developer, every PR, and every agent task lands in one shared cluster, tests fail because of collisions, not real bugs. Triaging environments eats the day. ##### The validation surface is wide Real microservices runtimes mix dozens of services with databases, queues, and external APIs. Covering that surface in tests means running against a realistic Kubernetes stack, not a mocked one. #### Full-cluster duplication vs Signadot Sandboxes. The traditional path to a real Kubernetes test environment is duplicating the cluster per developer or per PR. Signadot reaches the same fidelity by virtualizing only what changed. Full-cluster duplication Signadot Sandboxes Full stack dependencies Isolated per developer, PR, or agent task Spins up in seconds Scales to thousands of environments Coding-agent-ready *Image: Brex* “A typical deploy in our Signadot based tooling, end-to-end, is less than five minutes versus the 30-60 minute deploy times we would see with preview environments. Local sandboxes allow us to take that down to almost instantaneous testing.” JS John Salem Senior Software Engineer, Brex #### Every change validated against real Kubernetes dependencies. Every developer and every coding agent gets a real Kubernetes test environment to run integration, end-to-end, and regression tests before code lands. [Start for free](https://www.signadot.com/signup/) [Read the Brex story](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) #### How Signadot solves Kubernetes testing Four product capabilities that turn the staging cluster you already run into a realistic Kubernetes test environment for every developer and every coding agent. 1 ##### **Signadot Sandboxes** Sandboxes are lightweight ephemeral environments that virtualize the full stack: only the services that changed are deployed, and traffic for everything else routes to the shared dependencies on staging. Sandboxes work for in-cluster workloads and for services running on a developer's laptop or an agent's development environment, so the inner loop and CI share the same fidelity. CHANGE service + diff in-cluster or local SHARED DEPENDENCIES service service queue db real 2 ##### **Native service mesh routing** Signadot routes Sandbox traffic through the service mesh your cluster already runs. Istio, Linkerd, and the Kubernetes Gateway API are supported natively. HTTP-header routing handles paths that aren't mesh-managed, so the same routing model works whether the service runs in the cluster or on a developer's laptop. request MESH ROUTING Istio Linkerd Gateway API \+ HTTP headers Sandbox forked service baseline shared 3 ##### **Signadot Jobs** Bring your own test framework. Each Job runs in its own Kubernetes pod and exercises the APIs and frontends routed through your Sandboxes. Playwright, Cypress, Postman, or your own runner. Hundreds of pre-merge runs in parallel with no contention. Playwright Cypress Postman SIGNADOT JOB runs in its own Kubernetes pod hits Sandbox routes 4 ##### **Plans and Skills** Plans extend the validation surface in a structured, composable way: run tests, capture and replay traffic against a Sandbox, gate a merge. Skills give coding agents control and validation tools they call directly to work with more autonomy, like /signadot-validate. agent session \> /signadot-validate test the new payment flow against staging → invoking Plan: payment-validation ✓ deploy Sandbox with service +diff ✓ run integration + e2e suite ⠋ replay captured traffic against Sandbox #### Ship reliable code on Kubernetes at agent scale. Validate every change against a real microservices runtime. Catch bugs early, ship faster, and unblock coding agents to test their own code in Kubernetes. Agent scale thousands of envs in parallel Every developer and every coding agent gets their own ephemeral environment on the staging cluster you already run. No coordination, no waiting for a slot. Seconds to validate every change Spin-up is fast enough that agents iterate against real services inside their own loop. The verification step stops being the bottleneck. Reliable code shipped faster Every PR arrives at review having already passed integration, end-to-end, and regression tests against real Kubernetes dependencies. Reviewers spend time on judgment, not triage. [Start for free](https://www.signadot.com/signup/) [View pricing](https://www.signadot.com/pricing/) #### Kubernetes Test Environments FAQ What is a Kubernetes test environment? A Kubernetes test environment is a cluster (or a slice of one) where you run integration, end-to-end, and regression tests against the same kinds of services and dependencies you run in production. With Signadot, every developer, PR, and coding agent gets a lightweight ephemeral environment that virtualizes the full stack on the staging cluster you already run. How is this different from kind, minikube, or vcluster? kind and minikube run a Kubernetes instance on your laptop. They are great for hello-world iteration but cannot host the real microservices, queues, and databases your app depends on. vcluster gives you a virtual control plane inside a host cluster, which still duplicates the workloads you want to test. Signadot virtualizes only the services that changed and routes traffic for everything else to the shared dependencies on staging, so each test environment is a few extra pods instead of a full clone. Can I run integration testing in Kubernetes without contention? Yes. Every PR and every coding agent opens its own isolated ephemeral environment on the shared staging cluster. Test traffic routes into the changed services. All other traffic hits the shared dependencies. No collisions, no queue, no second cluster to maintain. Does this scale to hundreds of concurrent test environments? Yes. Because only the changed services are duplicated and everything else is shared, hundreds of environments fit comfortably in a single staging cluster. Brex runs the equivalent of hundreds of pre-merge environments on Signadot and saved roughly $2M per year on infrastructure relative to duplicating staging. How does multi-tenant test isolation work? Signadot uses request-level routing on top of your service mesh (Istio, Linkerd) or HTTP headers. Each test environment has a routing key. Requests with that key go to the changed services in the environment. All other requests hit the shared dependencies. State-bearing resources like Kafka, SQS, and databases use per-environment tenancy through resource plugins. What test frameworks does Signadot support? Anything that runs in a container. Playwright, Cypress, Postman, and custom runners all work today through Signadot Jobs. Each Job runs in its own Kubernetes pod and hits the APIs and frontends routed through your Sandboxes, so tests get full access to the real services without sharing the Sandbox pod. Does Signadot work with my CI? Yes. The Signadot CLI plugs into GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines, and any CI that can run a shell. The typical pipeline builds the changed services, calls the CLI to create the environment, runs your tests against it, and tears it down. #### Kubernetes test environments built for coding agents. Lightweight ephemeral environments mean every developer, every PR, and every coding agent gets a real Kubernetes test environment, sharing the staging cluster you already run. No queue. No contention. [Start for free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) --- # Guides ## The Complete Guide to Microservices Testing Source: https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/ Summary: Testing microservices across the lifecycle: local development, pull request validation, CI/CD, staging, and production, with strategies built for Kubernetes at scale. Includes the four types of microservices tests and a categorized comparison of the best microservices testing tools. ### The Complete Guide to Microservices Testing: From Local Development to Production What is microservices testing? A complete guide to testing microservices across the lifecycle: local development, pull request validation, CI/CD, staging, and production, with strategies built for Kubernetes at scale. Type Guide Reading time 27 min Published February 28, 2026 Updated August 31, 2026 **Microservices testing** is the practice of validating individual services and their interactions across a distributed system, from a developer’s local machine through pull request, CI/CD, staging, and production. Because behavior in a microservices architecture emerges from how services talk to each other, effective testing depends less on mocks and more on validating each change against real dependencies in a production-like environment. This guide covers microservices testing across the entire lifecycle, the strategies that scale on Kubernetes, and where teams most often get stuck. #### Introduction: The Million-Dollar Testing Crisis The transition to microservices was meant to unlock engineering velocity and team autonomy. Instead, for many organizations, it has inadvertently created a developer productivity crisis, a multi-million-dollar operational drag hidden within engineering budgets. The problem isn’t that testing is inherently difficult; it’s that the traditional testing models designed for monoliths are fundamentally incompatible with the distributed, asynchronous nature of modern architectures. [Recent research reveals a stark reality](https://www.atlassian.com/blog/developer/developer-experience-report-2024): 97% of developers report losing significant time to inefficiencies, with a staggering 69% losing eight or more hours every week. This lost time translates directly into a financial crisis. For an engineering organization with 200 developers, this inefficiency can equate to over $400,000 in squandered productivity every single month, a figure derived from [real-world analysis](https://www.signadot.com/blog/the-million-dollar-problem-of-slow-microservices-testing/) of teams grappling with integration failures. This isn’t a minor inconvenience; it’s a systemic drain on innovation, morale, and the bottom line. The root of this crisis lies in a simple fact: [testing complexity doesn’t grow linearly with the number of services, it grows exponentially](https://www.signadot.com/blog/why-scaling-makes-microservices-testing-exponentially-harder/). An approach that works for five services becomes an unmanageable bottleneck at 50. This exponential growth is driven by a trifecta of compounding factors: the rapid multiplication of integration points between services, the unsustainable maintenance burden of mock data and virtualized services, and the spiraling infrastructure costs of duplicating environments for testing. *Image: Diagram showing integration points growing exponentially from 5 services to 50 services* This leads to the [**microservices testing paradox**](https://medium.com/capital-one-tech/the-microservices-paradox-e55d5af2fda5): the very attributes that make the architecture so appealing, independence, scalability, and team autonomy, are precisely what make testing it exponentially harder. Each independently deployable service adds a new node to a complex web of dependencies, creating a [combinatorial explosion of test scenarios that must be validated](https://medium.com/@shaikshaji05/performance-testing-in-the-microservices-era-challenges-and-best-practices-bceefca6ae96). The result is a system where individual components are simple, but the whole is infinitely complex, with multiple versions, communication paths, and failure points coexisting in production. The productivity loss felt by developers is merely a lagging indicator of this deeper architectural mismatch. The pain points they cite, [technical debt, complex build processes, and constant context switching](https://shiftmag.dev/developers-waste-8-hours-weekly-on-inefficiencies-like-technical-debt-3956/), are symptoms of a fundamental strategic error: applying monolithic testing patterns to a post-monolith world. This pressure is now compounding. A growing share of code is written by AI coding agents like Claude Code, Codex, and Cursor, and they produce changes far faster than any team can hand-review them. Writing the change is no longer the hard part. Knowing whether it is safe to merge is. The bottleneck has shifted from authoring code to validating it, and for cloud-native applications that validation is exactly the work this guide is about: every change has to be exercised against real dependencies before it can ship. With [cloud-native adoption now at 89%](https://www.cncf.io/wp-content/uploads/2025/04/cncf_annual_survey24_031225a.pdf), it’s clear that traditional approaches are not just inefficient; they are fundamentally broken. This guide serves as the definitive resource to bridge the gap between testing theory and practical, scalable implementation, detailing a new paradigm that resolves the million-dollar problem of slow microservices testing. For more background on the financial impact, see “[The Million-Dollar Problem of Slow Microservices Testing.](https://www.signadot.com/blog/the-million-dollar-problem-of-slow-microservices-testing/)” #### How to Test Microservices: Strategies for Each Stage Testing microservices is not one activity but a sequence of validations, each matched to a stage of the delivery lifecycle. The strategies that scale share one principle: test every change against real dependencies as early as possible, rather than trusting mocks now and discovering the truth in staging later. 1. **Local development:** run only the service you are changing and connect it to a shared cluster with request-level isolation, so it participates in a real environment instead of a simulation. 2. **Pull request:** spin up an isolated sandbox for the change and compare its behavior against the baseline with automated diffing, catching contract and behavioral regressions before merge. 3. **CI/CD:** run integration and end-to-end suites against per-PR sandboxes in parallel, so validation never queues behind other teams. 4. **Staging:** keep one shared baseline in sync with the main branch and give each change request-level isolation on top of it, instead of cloning full environments. 5. **Production:** finish with progressive delivery, canary deployments, feature flags, and chaos engineering, focused on the emergent issues only production can reveal. The rest of this guide walks through each stage in depth: the traditional approaches that break at scale, and the microservices testing strategies used by teams like Brex, DoorDash, and Earnest. #### The Four Types of Microservices Tests Every microservices testing strategy combines four types of tests, each covering a different slice of the system. *Image: Diagram showing a group of connected microservices, with colored areas representing the different types of tests* - **Unit tests** validate a small chunk of code with a single area of functionality. They are fast and cheap and should remain the largest layer of the pyramid, but they cannot tell you whether services work together. - **Component tests** exercise an individual microservice in isolation, usually mocking its external calls. They unambiguously attribute a failure to one service, at the cost of trusting that the mocks still resemble the real dependencies. - **Integration tests** validate communication between services. This is the layer that matters most in a microservices architecture, because behavior emerges from interactions, and it is also the layer where mocks drift and shared environments become bottlenecks. - **End-to-end tests** treat the whole system as a black box and verify user-visible outcomes. They give high-quality feedback but are traditionally slow and expensive in distributed systems, which is why many teams ration them. Two practical rules follow. First, weight your investment toward integration tests, since service interactions are where microservices actually break; component tests confirm each unit, and end-to-end tests stay a thin final check. Second, keep dependencies current: tests that run against stale versions of other services miss bugs that exist in the deployed system and flag bugs that were already fixed. Request-level isolation addresses both rules at once, because integration and end-to-end tests run against the live baseline version of every dependency instead of mocks or stale copies, which is what makes end-to-end testing affordable again at scale. #### Local Development Phase: Breaking Free from Localhost Limitations The long-held dream of running a complete, production-like environment on a developer’s laptop is officially over. For any modern cloud-native application, which can easily comprise 10 to 50 distinct microservices, running the entire stack locally is impractical due to resource constraints. This reality forces developers into a compromised position, where they must rely on simulations and stubs that create a dangerous gap between the local development experience and production reality, leading to a cascade of downstream failures. This gives rise to the “works on my machine” fallacy, where code that passes local checks fails catastrophically during integration. The traditional approaches used to bridge this gap are themselves deeply flawed, especially at scale. - **Docker Compose:** While a useful utility for simple applications, Docker Compose fails to scale for complex microservices development. It cannot replicate sophisticated cloud infrastructure like managed databases (e.g., RDS), service meshes, or serverless functions. This forces teams to maintain a separate docker-compose.yml configuration that inevitably drifts from the production Kubernetes manifests, leading to configuration-related bugs that only appear post-deployment. - **Service Virtualization and Mocks:** This approach attempts to simulate the behavior of dependent services. However, these [simulations](https://www.ust.com/en/insights/service-virtualization-tool-selection-advantages-and-disadvantages-of-the-simulation-service) are brittle, require immense maintenance overhead, and are based on assumptions that quickly become outdated as real services evolve. A mock can confirm that your service called a dependency correctly, but it cannot validate the _actual interaction_ or emergent behavior. This leads to a false sense of security, with [tests passing against mocks but failing against the real service](https://www.lambdatest.com/learning-hub/service-virtualization).**‍** - **Testcontainers:** Testcontainers represents an improvement by allowing developers to programmatically spin up dependencies in Docker containers for integration tests. However, for large-scale systems, [this approach still has limitations](https://openliberty.io/guides/reactive-service-testing.html). It can lead to slow test startup times, high local resource consumption, and doesn’t solve the challenge of testing against complex, stateful cloud services that cannot be easily containerized. Furthermore, it can introduce its own [set of complexities](https://news.ycombinator.com/item?id=39531536) when interacting with other containerized workflows on a developer’s machine. The true goal of local development is not merely to write code but to validate _interactions_. The critical feedback loop for a microservice developer is not just “does my code compile?” but “does my service interact correctly with its dependencies?” Traditional methods fail to provide this feedback reliably. A paradigm shift is required: from attempting to _replicate_ the cloud on a laptop to enabling a local service to _participate_ in a shared cloud environment. This is achieved through [**request-level isolation**](https://www.signadot.com/blog/transforming-kubernetes-developer-environments-the-shift-to-request-level-isolation/). In this model, a developer runs only the single service they are actively working on locally. A lightweight tool then intelligently routes specific test requests from the shared Kubernetes cluster to their local machine. All other requests for downstream dependencies are seamlessly routed to the live, up-to-date services running in that shared cluster.20 This same property is what an AI coding agent needs to do useful work. An agent does its best work when it can close the loop itself: make a change, run it against real dependencies, read the result, fix, and repeat, without waiting on a human or a contended shared environment. That requires an environment that is quick and cheap to create but still high fidelity, which is precisely what request-level isolation provides and what local environments and stale staging cannot. For a deeper look at applying this to agent output, see [Validating AI-Generated Code Against Real Kubernetes Dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/). This approach transforms both developer experience and cost structures. Instead of hours spent debugging configuration drift, developers get connected to a high-fidelity environment in seconds. The cost model shifts dramatically as well. [Traditional full-stack duplication](https://www.signadot.com/blog/why-90-of-microservices-still-ship-like-monoliths/) for each developer can cost anywhere from $10,000 to $50,000 per month. The sandbox model, which leverages a shared baseline, eliminates this redundant infrastructure spend. As Martin Fowler notes, the [test pyramid](https://martinfowler.com/bliki/TestPyramid.html) for distributed systems requires a more robust and reliable integration test layer. By bringing high-fidelity interaction testing into the developer’s inner loop, this modern approach finally delivers on that need. For more information on this approach, explore “[Local Development](https://www.signadot.com/solutions/local-development/)” and our hub guide to [local development on Kubernetes](https://www.signadot.com/guide-to-local-development-kubernetes/). #### Pull Request & Code Review Phase: Shift-Left with Intelligence The pull request (PR) is the most critical quality gate in the software development lifecycle. It’s the last line of defense before a change is merged into the main branch. Yet, testing at this stage has long been a frustrating trade-off between speed and fidelity. Full end-to-end tests are too slow, taking hours to run, while tests using mocks are fast but unreliable. The future of PR testing lies in a new approach: AI-powered analysis that delivers fast, high-fidelity feedback without the crushing maintenance burden of traditional contract testing. The goal is clear: provide a developer and their reviewer with production-like feedback on a change within 5-10 minutes. Anything longer breaks the flow of the review process and pushes critical validation downstream, where [fixing bugs is exponentially more expensive](https://www.signadot.com/blog/why-scaling-makes-microservices-testing-exponentially-harder/). Traditional consumer-driven contract testing, popularized by tools like Pact, was an early attempt to solve this. The idea is to have a “contract” that defines the expected interactions between a service consumer and a provider. While valuable in principle, [this approach suffers from significant drawbacks at scale](https://www.signadot.com/comparison/pact/): - **High Maintenance Burden:** Contracts are essentially another form of code that must be manually written, versioned, and maintained. A single API change in a provider service can trigger a cascade of required updates across dozens of consumer codebases, creating a significant maintenance tax.25 - **Tests Specification, Not Behavior:** Pact validates that a service adheres to a predefined _specification_. It doesn’t inherently test the actual, emergent behavior of the service when interacting with its live dependencies in a real environment. This means subtle but breaking behavioral changes can be missed.25**‍** - **Developer Complexity:** The “white-box” nature of Pact requires developers to have a deep understanding of the implementation and can be difficult to debug when tests fail due to complex data setup requirements.25 The breakthrough comes from evolving beyond manual contract definition to AI-powered behavioral analysis. With a solution like Signadot’s [**SmartTests**](https://www.signadot.com/product/smart-tests/), the workflow is fundamentally simplified. Instead of writing complex contracts, a developer writes a simple test in a language like Starlark to invoke an API endpoint. This test is then automatically executed against both the existing baseline version of the service and the new version running in an isolated sandbox. The core innovation is the **”** [**Smart Diff**](https://www.signadot.com/docs/reference/smart-tests/traffic-capture-diffs)**”** technology. An AI model analyzes and compares the responses from the two versions. Crucially, it has been trained to distinguish meaningful, breaking changes, such as a removed field, a changed data type, or a different status code, from benign “noise” like updated timestamps, newly generated IDs, or a different ordering of elements in an array. This intelligent filtering eliminates the false positives and test flakiness that plague traditional systems. The value of AI here is not just automation, but _attention filtering_. It automates the cognitive load of sifting through irrelevant data, focusing the developer’s scarce attention only on the changes that truly matter. This represents a shift from static contract validation to dynamic behavioral validation. By observing the service’s actual runtime behavior against real dependencies, this method catches subtle issues that static analysis misses. The results are transformative. Teams using this approach have achieved **10x faster feedback cycles**. DoorDash, for instance, used this model to [slash their feedback time](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/) on changes from over 30 minutes to less than two minutes. This turns the PR from a simple code review into a comprehensive, automated integration validation gate. To learn more about this technology, see this guide on “[AI-powered Contract Testing](https://www.signadot.com/product/smart-tests/).” #### CI/CD Pipeline Integration: Parallel Execution at Scale For most organizations that have adopted microservices, the CI/CD pipeline, once the engine of velocity, has become the primary bottleneck. The traditional pipeline model, designed for monoliths, forces system-wide integration tests into a slow, sequential, post-merge process. This creates the infamous “[staging bottleneck](https://www.signadot.com/blog/your-ci-cd-pipeline-wasnt-built-for-microservices/),” a perpetual queue of developers waiting for a stable window to test their changes, which kills productivity and strangles the very agility microservices promised. The problem lies in an unsustainable scaling model. In a traditional setup, the cost and complexity of test environments follow a painful equation: Cost∝(#of Developers×#of Services). Each new developer and each new service multiplies the need for dedicated test infrastructure, leading to runaway cloud bills and operational overhead.4 This forces a false choice between exorbitant costs for many environments or a productivity-killing bottleneck with just a few. The modern solution is to break this model by leveraging sandboxes to enable parallel execution at scale. This introduces a revolutionary new cost equation: Cost∝(#of Developers+#of Services). This is an architectural breakthrough that [decouples infrastructure costs from team and service growth by intelligently sharing resources](https://www.signadot.com/blog/why-90-of-microservices-still-ship-like-monoliths/). This new paradigm redefines the CI/CD workflow and the purpose of the pipeline itself. 1. A developer opens a pull request. 2. The CI pipeline automatically triggers the creation of a lightweight, isolated sandbox. This sandbox contains _only_ the service(s) modified in the PR. 3. The pipeline then executes a full suite of integration and end-to-end tests against this sandbox. Because the sandbox is isolated at the request level, these tests can run in **parallel** with dozens of other PRs being tested simultaneously, without any interference. 4. The pipeline’s job is no longer to be a slow, sequential integration queue. Its purpose shifts from being the _integration tester_ to being the _integration verifier_ and _component promoter_. It simply confirms that the sandbox tests passed and then handles the mechanics of merging the code and promoting the container image. This transformation has a direct and measurable impact on the four key [**DORA metrics**](https://www.signadot.com/blog/how-to-do-dora-metrics-right/), the industry standard for measuring DevOps performance. - **Deployment Frequency (DF):** By enabling safe, parallel, pre-merge testing, sandboxes allow teams to merge smaller, validated changes more often, directly increasing deployment frequency. - **Lead Time for Changes (LT):** The feedback loop on integration issues shrinks from hours or even days in a shared staging environment to just minutes within the PR process. This drastically reduces the time from commit to deployment. - **Change Failure Rate (CFR):** Catching integration bugs _before_ they are merged into the main branch means fewer defects reach production. This directly lowers the change failure rate. For example, fintech company Earnest reported an [**80% reduction in production incidents**](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) after adopting this model.**‍** - **Mean Time to Restore (MTTR):** With higher confidence in each change and smaller deployment batches, rollbacks are faster and less risky, improving recovery times. This approach is not a niche solution; it is a platform engineering best practice for the modern enterprise. With 89% of organizations now using cloud-native technologies and [93% using or evaluating Kubernetes](https://www.cncf.io/wp-content/uploads/2025/04/cncf_annual_survey24_031225a.pdf), solving the CI/CD bottleneck is a central challenge for the vast majority of engineering teams. For more details, explore guides on [our docs](https://www.signadot.com/docs/guides/integrate-ci). #### Staging & Integration: Why Environment Replication Doesn’t Work The concept of a persistent, shared “staging” environment is a relic of the monolithic era. In a world of distributed microservices, it has become a costly, inefficient, and fundamentally flawed model for integration testing. The future is not about building more perfect replicas of production; it’s about eliminating the need for replication altogether through a paradigm shift towards dynamic, on-demand, request-level isolation. The staging environment has become a crisis point for many engineering organizations. Imagine a scenario where 20 teams collectively need 80 hours of testing time per week, but the shared staging environment only offers 40 hours of stable uptime due to constant deployments, data corruption, and breakages. The result is a [perpetual traffic jam of developers waiting in line to validate their changes](https://www.signadot.com/blog/why-scaling-makes-microservices-testing-exponentially-harder/). This stage gets a guide of its own in [Staging Environments: The Complete Guide](https://www.signadot.com/staging-environments/), which compares the four ways out of the shared copy. This bottleneck is not just a productivity issue; it’s a massive financial drain. [The model of full environment duplication](https://www.signadot.com/comparison/release/), cloning the entire production stack for testing, is astronomically expensive. A 50-developer team can easily spend over **$561,000 annually** just to maintain a single, full-sized staging environment. In a high-growth company like [Brex](https://www.signadot.com/blog/how-brex-transformed-developer-experience-and-slashed-infrastructure-costs-with-signadot/), the homegrown preview environment system that replicated the stack for each developer grew so expensive that replacing it with request-level isolation now saves the company **about $2 million annually** in infrastructure costs. This sentiment is echoed by industry leaders like [Kelsey Hightower](https://www.getambassador.io/podcasts/kelsey-hightower-on-developer-experience-paas-and-testing-in-production), who has noted that staging environments are, at best, a pale and untrustworthy imitation of the real production environment. The solution lies in a fundamental paradigm shift from **Infrastructure-Level Isolation** to **Request-Level Isolation**. - **Infrastructure-Level Isolation:** The traditional approach. You create a complete, physical or virtual clone of your entire infrastructure stack (all services, databases, message queues) for each test environment. This is slow, expensive, and difficult to keep in sync with production.**‍** - **Request-Level Isolation:** The modern approach. You use a single, shared, production-like cluster. Isolation is achieved at the application layer by intelligently routing individual test requests. This is enabled by a technology called **header-based context propagation**. When a test begins, a unique context identifier (e.g., a specific HTTP header) is injected into the initial request. As this request travels through the microservices ecosystem, a service mesh or lightweight SDK in each service inspects the header. Based on the context, it dynamically routes the request to either a sandboxed version of a service (for the code under test) or the shared, baseline version of its dependencies. The advantages of this approach become clear when compared directly with traditional methods. Approach Isolation Model Spin-up Time Infrastructure Cost Production Fidelity Scalability Traditional Staging None (Shared) N/A (Always on) Very High Low (Stale data/config) Poor (Bottleneck) Mocking/Virtualization N/A (Simulation) Milliseconds Very Low Very Low (Drifts from reality) N/A Full Duplication (Okteto/Qovery) Infrastructure-level Minutes to Hours High (Cost ∝ Devs × Services) Medium (Hard to sync data) Poor (Cost prohibitive) Signadot Sandboxes Request-Level Seconds Low (Cost ∝ Devs + Services) High (Live dependencies) Excellent (Parallel) The return on investment (ROI) from this shift is not theoretical. It’s proven by leading technology companies: - [**Brex**](https://www.signadot.com/blog/how-brex-transformed-developer-experience-and-slashed-infrastructure-costs-with-signadot/)**:** By moving from full duplication to request-level isolation, they save **about $2 million annually** in infrastructure costs and saw developer satisfaction scores jump by 28 points. - [**DoorDash**](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/)**:** They achieved **10x faster feedback** on code changes, cutting deployment validation time from over 30 minutes to under two minutes, and ultimately deprecated their legacy staging environment entirely. - [**Earnest**](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/)**:** The fintech company empowered its developers with early, high-fidelity testing, leading to an **80% reduction in production incidents** and significantly more reliable releases. To learn more, see this [Guide to Ephemeral Environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) and explore our [case studies](https://www.signadot.com/customers/). Test every change against real dependencies Signadot uses request-level isolation so you can run high-fidelity integration tests for every pull request on your existing cluster, in parallel and in seconds. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Production Testing & Monitoring: Beyond Traditional Boundaries In the world of complex, distributed systems, the idea that all bugs can be caught before deployment is a dangerous fiction. The boundary between testing and production is blurring, and mature engineering organizations embrace this reality. They understand that production is the ultimate testing ground. This philosophy, often called “[testing in production](https://www.honeycomb.io/blog/testing-in-production),” is not about recklessness; it’s about systematically and safely validating changes in the only environment that truly matters, the one serving live users. As technologist [Kelsey Hightower](https://www.getambassador.io/podcasts/kelsey-hightower-on-developer-experience-paas-and-testing-in-production) has pointed out, “Organizations are always testing in production, whether they deliberately choose to or not”. The critical difference lies in doing so accidentally and reactively versus intentionally and proactively. The most resilient companies have adopted a suite of practices to test in production with confidence. - **Chaos Engineering:** Pioneered by **Netflix** with their “[Chaos Monkey](https://www.geeksforgeeks.org/system-design/what-is-netflixs-chaos-monkey/),” this practice involves deliberately injecting failures into a production system to uncover weaknesses before they cause widespread outages. By randomly terminating production instances, Netflix forces its engineers to design services that are inherently resilient and fault-tolerant. The goal is not to prove a service will never fail, but to prove [the system can gracefully handle it when it does](https://newrelic.com/blog/best-practices/chaos-engineering-explained). - **Canary Deployments:** This technique involves rolling out a new version of a service to a small subset of production traffic. **Amazon**, for example, uses [canary deployments](https://aws.amazon.com/blogs/compute/performing-canary-deployments-for-service-integrations-with-amazon-api-gateway/) extensively to validate changes to its API Gateway. By monitoring the behavior of the new version with a limited audience (e.g., 1% of users), teams can detect performance regressions or errors and quickly roll back with minimal blast radius before a full deployment. - **Feature Flags:** Feature flags decouple code deployment from feature release. This allows teams to deploy new code to production in a “dark” state, hidden from users. [**Uber’s** sophisticated “Flipr” platform](https://launchdarkly.com/trajectory/flipr-ubers-dynamic-configuration-platform/) is a prime example, enabling them to manage dynamic configurations, turn features on for specific user segments (internal employees, beta testers), and conduct incremental rollouts safely in production. These advanced production practices do not replace pre-production testing; they depend on it. This is where a robust sandbox strategy becomes a critical enabler. The purpose of modern testing is not to prevent all failure, which is impossible in a complex system, but to build the confidence to ship changes and recover quickly when failures inevitably occur. When a team has already validated a change in a high-fidelity sandbox, they have high confidence that it doesn’t break API contracts or core integrations, these are the “known unknowns.” This rigorous pre-production check de-risks the initial deployment, allowing production testing techniques like canaries and chaos experiments to focus on discovering emergent, at-scale issues, the “unknown unknowns” like cascading failures, performance degradation under specific load patterns, or unexpected user behaviors. This entire lifecycle is orchestrated by a modern platform engineering team, which provides a unified toolchain for testing, monitoring, and debugging. The feedback loop becomes continuous: insights from production observability, traces, metrics, and logs, are used to create more effective sandbox tests, creating a virtuous cycle of improvement. This observability-driven testing is the hallmark of a mature, high-performing engineering organization. #### The Best Microservices Testing Tools Microservices testing tools fall into a few distinct categories, and most teams combine one tool from each layer rather than picking a single winner. Tool Category Best for [Signadot](https://www.signadot.com/) Sandbox environments and integration testing High-fidelity integration, PR, and end-to-end testing with per-change sandboxes on one shared cluster, plus SmartTests behavioral diffing and agent-driven validation over MCP Testkube In-cluster test orchestration Running existing test suites (Postman, k6, Cypress, JUnit) as Kubernetes-native workflows with centralized results [Pact](https://www.signadot.com/comparison/pact/) Contract testing Enforcing consumer-driven API contracts between service pairs when both sides commit to maintaining the contracts [Telepresence and mirrord](https://www.signadot.com/blog/the-ultimate-guide-to-telepresence-alternatives-in-2025/) Local development bridges Connecting a locally running process to a remote cluster during inner-loop development WireMock and MockServer API mocking Fast, deterministic unit and component tests where isolation matters more than fidelity k6 Load and performance testing Validating latency and throughput behavior, standalone or scripted in CI The categories are complementary rather than competing. Mocking tools make the unit layer fast but [drift from real service behavior over time](https://www.signadot.com/blog/why-developers-shouldnt-write-mocks-a-guide-to-modern-testing/). Contract tools enforce specifications but not emergent behavior. Orchestration tools run your suites inside the cluster but still need a trustworthy environment to run them against. That is why the environment layer is the deciding investment: once every change gets an isolated, production-like sandbox, every other tool in the stack produces more reliable signal. For a deeper comparison of the environment-layer options, see [the best microservices testing solutions for Kubernetes](https://www.signadot.com/articles/best-microservices-testing-solution-for-kubernetes-in-2025/). #### The Future of Microservices Testing: A Paradigm Shift The evolution of microservices testing is not about making incremental improvements to outdated tools. It represents a fundamental paradigm shift toward an integrated, intelligent, and developer-centric platform. This transformation is being driven by three powerful forces: the organizational shift to platform engineering, the technological shift to AI-driven validation, and the cultural shift that recognizes developer experience (DevEx) as a primary competitive advantage. First, the operating model of engineering is changing. The old world of siloed Dev, QA, and Ops teams is giving way to a centralized **platform engineering** model. In this model, a platform team is responsible for providing self-service tools, automation, and standardized “golden paths” that enable product teams to deliver value quickly and safely. This trend is accelerating rapidly, with **53% of organizations having started their platform engineering journey in 2024**. This organizational structure demands a unified, platform-based solution for testing, not a fragmented collection of point tools. Second, the technology of testing is becoming intelligent. The future is not just about automating test execution but about automating analysis and insight. [**Signadot’s SmartTests**](https://www.signadot.com/product/smart-tests/) are at the vanguard of this movement. By using AI to analyze the behavior of services and distinguish meaningful changes from benign noise, it eliminates the test maintenance and flakiness that plague traditional contract testing. This is the technological leap that makes scalable, low-friction testing a reality. Finally, the industry has recognized that the “Million-Dollar Testing Crisis” is, at its core, a [**developer experience (DevEx) crisis**](https://thenewstack.io/why-do-developers-lose-1-day-a-week-to-inefficiencies/). Slow feedback loops, brittle environments, and constant context switching lead to developer frustration, burnout, and attrition. A superior testing platform that provides self-service capabilities, sub-second environment creation, and production-fidelity feedback is no longer a luxury. It is a [critical tool](https://develocity.io/key-takeaways-from-the-2024-state-of-developer-experience-report/) for attracting and retaining elite engineering talent and maximizing their productivity and satisfaction. The decision-making process for testing tools is therefore elevating from a tactical, team-level choice to a strategic, platform-level investment. To make the business case for this transformation, organizations can use a [simple ROI framework](https://scaleupally.io/blog/roi-for-software-development/) to calculate their own “Cost of Inefficiency.” - **Cost of Wasted Developer Time:** Calculate the productivity drain from testing bottlenecks. _Costwasted​=(Number of Developers)×(Hours Lost per Week)×(52)×(Fully Loaded Hourly Cost) ‍_ - **Cost of Infrastructure Waste:** Calculate the savings from eliminating redundant environments. A [90% reduction](https://www.signadot.com/) in infrastructure costs is achievable in cases where teams are duplicating full environments for each test or developer workflow. In scenarios where multiple static environments exist (dev, QA, staging, etc.), consolidation into a shared pool of ephemeral environments can still yield over 50% cost savings. _Costsavings​=(Annual Cost of Staging/Preview Environments)×0.90 ‍_ - **Beyond infrastructure savings**, teams see significant quality improvements. By catching defects earlier, Signadot can prevent bugs from ever reaching staging (saving roughly $1,500 per bug) and production (avoiding incidents that can cost [$10,000](https://www.celerity.com/insights/the-true-cost-of-a-software-bug) or more each). These reductions compound over time, lowering both direct remediation costs and the downstream impact on velocity. ‍ - **Opportunity Cost of Slow Velocity:** While harder to quantify, this is often the most significant factor. It represents the lost revenue or strategic advantage from features that are delayed due to testing friction. There is now a fourth force, and it raises the stakes on all of this. As AI coding agents write a larger share of changes, the volume of code that needs validating climbs faster than any team can keep up with by hand, and validation across the lifecycle becomes the binding constraint on shipping. Meeting it takes both halves of the problem at once: an environment layer that gives every change, human or agent, a high-fidelity place to run, and a validation layer on top of it. Signadot sandboxes provide the first half, and SmartTests, Jobs, and Plans provide the second, covering functional and non-functional checks. Together they let agents produce verified code and pull requests rather than unverified ones, which is what turns a flood of generated changes into genuine continuous delivery. The journey from the exponential pain of traditional microservices testing to a new paradigm of request-level isolation, AI-powered validation, and platform-driven workflows is complete. The choice is no longer a trade-off between speed and quality; modern testing platforms are designed to deliver both. The million-dollar problem is real, and the solution is here. It is time to evaluate your testing strategy and calculate your own cost of delay. Put microservices testing on autopilot Spin up isolated sandboxes for every change, run your existing tests against real services, and catch integration bugs before they merge. Start free on the cluster you already run. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Related Articles - [Validating AI-Generated Code Against Real Kubernetes Dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/) - [Guide to Ephemeral Environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) - [Kubernetes Development Environments: Local, Remote, and Production-Like Options](https://www.signadot.com/blog/local-kubernetes-dev-environments/) - [The Million-Dollar Problem of Slow Microservices Testing](https://www.signadot.com/blog/the-million-dollar-problem-of-slow-microservices-testing/) - [Why Scaling Makes Microservices Testing Exponentially Harder](https://www.signadot.com/blog/why-scaling-makes-microservices-testing-exponentially-harder/) - [Transforming Kubernetes Developer Environments: The Shift to Request-Level Isolation](https://www.signadot.com/blog/transforming-kubernetes-developer-environments-the-shift-to-request-level-isolation/) - [Why 90% of Microservices Still Ship Like Monoliths](https://www.signadot.com/blog/why-90-of-microservices-still-ship-like-monoliths/) - [Your CI/CD Pipeline Wasn’t Built for Microservices](https://www.signadot.com/blog/your-ci-cd-pipeline-wasnt-built-for-microservices/) - [How to do DORA Metrics Right](https://www.signadot.com/blog/how-to-do-dora-metrics-right/) #### Frequently asked questions What is microservices testing? Microservices testing is the practice of validating individual services and their interactions across a distributed system, from local development through pull request, CI/CD, staging, and production. Because behavior emerges from how services talk to each other, it depends on validating each change against real dependencies rather than mocks. How do you test microservices? Stage by stage: run the service you are changing against real dependencies during local development, validate each pull request in an isolated sandbox with automated behavioral diffing, run integration suites against per-PR sandboxes in parallel in CI, keep one shared baseline instead of cloned staging environments, and finish with canary deployments and feature flags in production. What are the main microservices testing strategies? Unit tests for service logic, contract or behavioral-diff tests for API compatibility, integration and end-to-end tests against real dependencies, and progressive delivery techniques in production. At scale, the deciding strategy is request-level isolation, which lets every change get a high-fidelity environment without duplicating infrastructure. Why is testing microservices hard? Integration points grow exponentially with the number of services, mocks drift from the real services they imitate, and duplicating full environments for every change is slow and expensive. The result is that individual services are easy to test but the system's emergent behavior is not. What are the best microservices testing tools? The right tool depends on the layer: WireMock or MockServer for isolated unit and component tests, Pact for consumer-driven contract testing, Testkube for orchestrating test suites inside a Kubernetes cluster, Telepresence or mirrord for connecting a local process to a remote cluster, and Signadot for high-fidelity integration and end-to-end testing using isolated sandboxes on a shared cluster. Most teams combine a fast mock-based unit layer with sandbox-based integration testing rather than relying on any single tool. How do you test microservices in Kubernetes? Give every change an isolated sandbox on a shared Kubernetes cluster instead of cloning environments. The sandbox deploys only the services the change touches, requests carrying the sandbox's routing key reach the new version while everything else uses the live baseline, and integration tests run against real dependencies in parallel across teams. This keeps fidelity high and cost low at any number of services. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Best Microservices Testing Tools for Kubernetes in 2026 Source: https://www.signadot.com/articles/best-microservices-testing-solution-for-kubernetes-in-2025/ Summary: A categorized comparison of microservices testing tools: API and contract testing (Postman, Pact), end-to-end and performance (Cypress, JMeter, k6), and the Kubernetes-native environment platforms (Signadot, Testkube) they run against. ### Best Microservices Testing Solutions for Kubernetes in 2026 Author Arjun Iyer Published July 17, 2025 Updated July 17, 2026 The adoption of microservices architectures, orchestrated by Kubernetes, has become a standard for building scalable and resilient applications. While this architectural style offers significant advantages in development velocity and service independence, it introduces considerable complexity into the testing process. Effectively validating the behavior of distributed services within a dynamic Kubernetes environment requires a sophisticated strategy and a carefully selected set of tools. This article provides a technical overview of the leading microservices testing solutions available in 2026, categorized by their primary function within the development lifecycle. For the full lifecycle context behind these tools, see our complete guide to [microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). #### The Unique Testing Challenges in a Kubernetes Environment Testing applications in Kubernetes is fundamentally different from testing monolithic systems. The distributed and ephemeral nature of containers, coupled with the complexity of network policies, service discovery, and configuration management, presents unique obstacles. A successful testing strategy must account for the entire cloud-native ecosystem, including container orchestration, service meshes, and CI/CD pipelines. Key challenges include: - **Environment Provisioning:** Creating realistic, isolated, and cost-effective test environments that accurately replicate production is a major bottleneck. - **Service Dependencies:** A single microservice often depends on numerous other services. Testing a service in isolation requires mocking or stubbing these dependencies, while integration testing requires a running instance of the entire dependency chain. - **End-to-End Validation:** Verifying a complete business workflow that traverses multiple services is complex to set up, execute, and debug. - **Observability:** Pinpointing the root cause of a failure in a distributed system requires robust logging, metrics, and distributed tracing capabilities. #### API and Integration Testing Tools Integration testing is critical for ensuring that microservices interact with each other correctly, validating data flow and communication protocols. - **Postman:** Originally an API client, Postman has evolved into a comprehensive API development and testing platform. It is highly effective for microservices, allowing teams to create, share, and automate test collections. Its support for environment variables, automated test scripts, and CI/CD integration makes it a staple for validating API endpoints and basic service integrations. - **WireMock:** For true unit and integration testing of a single service, its dependencies must be simulated. WireMock is a leading tool for service virtualization, enabling developers to create mock HTTP-based APIs. By simulating dependent services, teams can test a microservice in isolation, ensuring its logic is correct without needing a fully deployed environment. #### Contract Testing Tools Contract testing addresses a common failure point in microservices: unintended breaking changes introduced when a provider service updates its API. It verifies that an API provider adheres to a “contract” expected by its consumers. - **Pact:** Pact is a widely used tool for consumer-driven contract testing. The consumer service defines a contract specifying its expectations of a provider. This contract is then used to verify that the provider service meets those expectations. This approach allows services to evolve independently while providing a fast and reliable feedback mechanism to prevent integration failures. #### End-to-End (E2E) Testing Tools E2E testing validates entire user workflows from start to finish, ensuring all integrated services work together as a cohesive system. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) - **Selenium:** As a long-standing standard for browser automation, Selenium remains a powerful tool for E2E testing of web applications built on microservices. It supports cross-browser testing in multiple programming languages and can be integrated with other tools to achieve comprehensive test coverage. However, its tests can be brittle and require significant maintenance. - **Cypress:** A modern alternative to Selenium, Cypress is favored for testing JavaScript-based frontends. It runs directly in the browser, providing faster feedback, time-travel debugging, and built-in mocking capabilities. These features make it highly effective for testing the user-facing components of a microservices architecture. - **[Shiplight](https://www.shiplight.ai/):** Shiplight adds a browser layer to coding-agent workflows. It gives an agent a real browser to exercise UI changes during development, then turns those flows into readable, self-healing E2E tests that live in the team’s repository. The tests are Playwright-compatible and run locally or in CI, so browser coverage stays close to the code while still running against Kubernetes-based preview, staging, and test environments. Coverage is limited to browser-facing flows, so it sits alongside API, contract, and service-level testing in a microservices stack. #### Performance and Load Testing Tools Performance testing is essential for microservices to ensure the system can handle production-level traffic and maintain responsiveness under load. - **Apache JMeter:** A versatile open-source tool, JMeter is widely used for load and performance testing of APIs, web applications, and other network services. It supports a wide range of protocols, offers distributed testing capabilities to simulate heavy loads, and integrates seamlessly into CI/CD pipelines for continuous performance validation. - **LoadRunner:** For enterprise-grade performance engineering, LoadRunner provides a robust solution for simulating complex, real-world user traffic. It supports a vast array of protocols and technologies and offers in-depth analysis and monitoring features to identify performance bottlenecks across a distributed architecture. #### Kubernetes-Native Test Orchestration and Environments The tools listed above are essential, but their effectiveness in a Kubernetes environment is often limited by the challenge of test execution and environment management. Kubernetes-native solutions are designed to address this gap directly. *Image: __wf_reserved_inherit* - **Testkube:** Testkube is a test execution and orchestration framework built specifically for Kubernetes. It allows developers and testers to execute tests using their preferred tools (like Cypress, Postman, or k6) directly within the cluster. By managing tests as Kubernetes resources, it decouples testing from the CI/CD system and enables more scalable, cloud-native testing workflows. - **Signadot:** A primary challenge in microservices testing is creating fast, isolated, and production-like environments. **Signadot** addresses this by providing a platform to create on-demand, ephemeral testing environments—called Sandboxes—within an existing Kubernetes cluster. Instead of duplicating an entire stack of services, a Sandbox deploys only the container for the service under test (e.g., from a pull request). Intelligent request routing directs test traffic to this new version, while all other requests for dependent services are routed to the stable baseline services in the shared cluster. This approach reduces infrastructure costs and provides developers with a high-fidelity test environment in seconds. Signadot can orchestrate existing test suites from frameworks like Playwright, Selenium, and Postman within these Sandboxes, bridging the gap between powerful testing tools and the complex Kubernetes environment they must run in. #### Conclusion: Building a Holistic Solution There is no single “best” microservices testing tool. An effective strategy for Kubernetes environments in 2026 relies on a combination of solutions that cover the entire testing pyramid, from API and contract tests to full end-to-end and performance validation. The selection of tools like Postman, Pact, and Cypress should be driven by the specific needs of the application and the team. However, the foundational element that enables all these tools to function efficiently is the test environment itself. The complexity and cost of maintaining traditional staging environments are significant impediments to agile development. The most impactful solution is one that solves the environment problem. Platforms like **Signadot** provide this critical capability, enabling teams to run any type of test in a fast, isolated, and cost-effective manner directly within Kubernetes. By integrating a robust environment management platform, organizations can unlock the full potential of their testing tools and accelerate development velocity without compromising on quality. #### Frequently asked questions What are the best microservices testing tools for Kubernetes? It takes a combination: Postman or Hoppscotch for API testing, Pact for contract testing, Cypress or Playwright for end-to-end flows, JMeter or k6 for performance, and a Kubernetes-native environment platform such as Signadot or Testkube to give those tools isolated, production-like environments to run against. Do I need an environment platform in addition to testing tools? Usually, yes. Most testing tools assume a stable, realistic environment to run against, which is exactly what is missing in shared staging setups. Kubernetes-native platforms create isolated, production-like test environments per change, so the rest of the toolchain produces trustworthy results. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: Why Signadot Outperforms Other K8s Testing Solutions* microservices-testing ##### Why Signadot Outperforms Other K8s Testing Solutions April 30, 2025 *Image: Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency* microservices-testing ##### Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency April 10, 2025 *Image: Stop Breaking Your Microservices with SmartTests: AI Powered Contract Testing* contract-testing ##### Stop Breaking Your Microservices with SmartTests: AI Powered Contract Testing June 18, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## What Are Ephemeral Environments? The Complete Kubernetes Guide Source: https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/ Summary: The four ways to build ephemeral environments in Kubernetes and how to choose, plus ephemeral vs static environments, what they cost, and how sandboxes handle databases, Kafka, and service meshes. ### What Are Ephemeral Environments? The Complete Kubernetes Guide What are ephemeral environments? Learn the four ways to build ephemeral environments in Kubernetes, the tradeoffs of each, and how to test microservices against real dependencies without duplicating infrastructure. Type Guide Reading time 16 min Published February 28, 2026 Updated August 31, 2026 **Ephemeral environments** are short-lived, on-demand environments created to test a specific code change, then torn down once it ships. In Kubernetes, they let teams validate microservices against real dependencies without standing up a full staging copy for every change or pull request. They go by several names, ephemeral test environments, ephemeral development environments, sandboxes, or [preview environments](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/), and they are how high-velocity teams replace the shared-staging bottleneck with isolated, production-like testing for every change. This guide compares the four main ways to build Kubernetes ephemeral environments, the tradeoffs of each, and how to choose the right model for your team’s scale, branching strategy, and budget. If you are weighing them against long-lived staging setups, the ephemeral vs static comparison later in this guide breaks down where shared environments fall short. Ephemeral environments are gaining popularity among development teams who want to accelerate testing and streamline their continuous integration/continuous deployment (CI/CD) pipelines. That pressure has intensified now that a large share of code is written by AI coding agents like Claude Code, Codex, and Cursor. The volume of changes has jumped, and the hard part has moved from writing code to validating it. For cloud-native applications the constraint is the environment itself: local setups are resource-constrained and low-fidelity, while shared staging is slow and contended. If you are using Kubernetes then there are many ways to create ephemeral environments for fast releases and testing new features or changes. By creating isolated, ephemeral environments, you can test code changes, experiment with new features, and reproduce issues without affecting your production systems. Check out [_Scaling Quality: The Industry’s Shift Towards Ephemeral Environments in 2024_](https://www.signadot.com/blog/scaling-quality-the-industrys-shift-towards-ephemeral-environments-in-2024/)  to discover how teams are using these environments to improve code quality and streamline microservices testing.  Today we will go through various methods for creating ephemeral Kubernetes environments, including microservices in-a-box, namespaces, separate clusters, and shared clusters. We will discuss the pros and cons of each approach, along with different factors that will influence the right selection for your needs. Let’s start by understanding the first option, which is deploying all services in an ephemeral environment on a single powerful machine or a virtual machine. #### Option 1. Microservices In-a-Box (All-in-One Machine) In this approach to creating ephemeral environments, all microservices are deployed together on a single, powerful machine or virtual machine (VM). Services are containerized and orchestrated using tools like Docker Compose or a single-node Kubernetes cluster. All the containers run side by side on one large EC2 instance with large CPU and memory resources. It is a relatively simple solution but has its disadvantages. Let’s go through the pros and cons of this approach: - **Advantages:** - **Quick Setup:** It is best for small teams or simpler applications where you can get all ephemeral environments up and running quickly without the complexity of managing multiple clusters. - **Simplified Development Environment:** With all ephemeral environments running on the same machine, debugging and testing interactions between services is straightforward. - **Considerations:** - **Limited Scalability:** As all microservices are deployed on a single instance, it can be challenging to scale the environment horizontally. This makes it less suitable for larger applications with high traffic or resource demands. - **Resource Contention:** If one microservice consumes too much CPU or memory, it might impact the performance of other services running on the same instance. **Cannot be a Production Replica:** Running all services on a single node does not accurately mimic a distributed production setup, which can lead to unexpected issues when deploying to a multi-node production cluster. *Image: Microservices in-a-box: four microservice environments running as Docker containers on a single VM, orchestrated with Docker Compose* #### Option 2. Deploy in Namespace With this approach, each ephemeral environment is isolated using Kubernetes namespaces within a shared cluster. This is a form of logical isolation where all ephemeral environments are in separate namespaces with each namespace having its own resource quota and limits.   - **Advantages**: - **Decent Isolation**: Although part of the same cluster, namespaces still provide a decent layer of isolation between environments. You can manage resource quota and limits separately for each ephemeral environment in its own namespace. - **Centralized Management**: As all the ephemeral environments are part of the same cluster, so management of the ephemeral environments is centralized. - **Considerations**: - **Management Complexity:** With a large number of namespaces, managing and maintaining them can become complex, especially if all you want to do is to test a small change in just one of the microservices. Note that you have to manage not just the setup and policies, quotas, but access controls for each ephemeral environment too. - **Resource Overhead:** Each namespace can introduce additional resource overhead, especially if they have their own resource quotas and limits. This can lead to inefficient resource utilization. - **Performance Impact:** A high number of namespaces can impact the performance of the Kubernetes control plane, as it has to manage and keep track of all the namespaces and their associated resources. - **Security Risks:** The more the namespaces, the larger the attack surface, which increases the security risk. - **Synchronization Complexity:** Keeping all the separate microservices copies up to date with the master can be challenging, especially as release velocity increases. For a deeper look at where this model works and where it breaks down, see [Kubernetes namespace vs cluster: pros and cons for test environments](https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/). *Image: Namespace-based ephemeral environments: a single staging cluster where each environment is isolated in its own Kubernetes namespace* #### Option 3. Deploy in Separate Clusters This approach involves deploying each ephemeral environment within its own Kubernetes cluster. As a result, you get ephemeral environments that are highly isolated and completely independent from each other. Here are some of the pros and cons of this strategy: - **Advantages**: - **Total Isolation:** Each cluster operates independently, so any issue in one environment, like crashes, will not affect others. - **Customizable Configurations:** You can customize each cluster for specific testing needs, such as network policies or Kubernetes versions. With the individual customization for each cluster, teams can experiment and replicate production environments without affecting others. - **Considerations**: -  **High Resource Costs:** Deploying each ephemeral environment in its own cluster requires substantial resources, driving up cloud costs. This is because each feature branch needs its own cluster requiring more CPU, memory, and storage. - **Added Complexity:** Managing multiple clusters adds operational overhead. For each cluster, you will need to manage its own configuration, security policies, and maintenance. This might be an overkill for small or simple applications, e.g. a monolith MVP application.  - **Longer Setup Times:** The greater the number of clusters, the longer it will take to set up each one. This will potentially slow down the overall development time. **Synchronization Complexity:** Each microservice in separate clusters needs to be kept synchronized with the master branch, which can be difficult as the number of services and release velocity increases. This becomes especially challenging as each microservice is deployed independently. *Image: Separate-cluster ephemeral environments: each environment runs in its own dedicated Kubernetes cluster* #### Option 4. Deploy in a Shared Cluster with Tunable Isolation In this model, all ephemeral environments exist within a single shared cluster, where isolation levels can be adjusted to fit different needs, such as controlling how requests are routed to specific environments. This approach typically involves using a baseline environment, which acts as the core shared environment, and sandboxes that isolate changes from each code change. A [sandbox](https://www.signadot.com/kubernetes-sandbox/) is an ephemeral environment created on top of the baseline. It allows developers to test changes independently without disrupting the core environment. Below, we explore how this method ensures efficient resource usage and testing without interference:  *Image: Shared cluster with tunable isolation: sandboxed versions of services A and B route requests through the shared baseline environment* This shared cluster can be used collaboratively by multiple developers and QA teams. It uses minimal resources and is ideal for situations where cost efficiency is a high priority. - **Advantages**: - **Efficient Use of Resources**: Optimizes existing resources, lowering the overall infrastructure cost. - **Encourages Team Collaboration**: Teams can work in parallel within the same cluster instead of spinning up new ones. - **Centralized Operations**: Easier to maintain and manage as all environments are within a single cluster. - **Considerations**: - **Keeping the baseline environment stable**: It is important to ensure that the baseline is well tested and stable, as instability can interfere with testing of other microservices. A strong CI/CD process with sufficient checks can help maintain stability. - **Need for a strong data isolation strategy**: If deploying in a production environment, a robust data isolation strategy is necessary to avoid conflicts. However, in staging environments, the data isolation bar may not be as high. **Signadot: Best of Both Worlds** Signadot implements tunable isolation in a shared environment strategy  and provides all the cost benefits of a shared staging cluster while still providing the required isolation by uniquely routing to isolated sandboxes. This allows you to deploy your bug-fixed microservice in its own ephemeral environment. As a result, you avoid the common issues associated with shared clusters, such as one service breaking the application being tested by another team. This approach ensures scalable microservices testing without compromising cost efficiency. This combination of quick, cheap, and high-fidelity is also what makes the shared-cluster model the right fit for AI-driven development. An agent does its best work when it can close the loop on its own: make a change, run it against real dependencies, read the result, fix, and repeat, without waiting on a human or queuing for a shared environment. Sandboxes give the agent that isolated environment layer. On top of it, Signadot adds a validation layer with SmartTests, Jobs, and Plans for functional and non-functional checks, so the agent can [validate AI-generated code against real Kubernetes dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/) and open verified pull requests rather than unverified ones. See tunable isolation in action Spin up your first Kubernetes sandbox on your existing cluster in minutes. No duplicated infrastructure, no staging queue. The free tier is open to every developer. [Start free for your team](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) *Image: Signadot operator routing one user's requests to an isolated sandbox while other users share the staging cluster's baseline environment* #### Factors Influencing Your Ephemeral Environment Strategy Let’s go through some of the factors that will impact your decision on which option to adopt. ##### Branching Strategies **Trunk-Based Development** For teams practicing trunk-based development, where small and frequent commits get integrated straight into the main branch, the **Microservices In-a-Box** and **Deploy in Shared Cluster** models tend to be the most practical options: - **Microservices In-a-Box** lets developers do quick and straightforward testing of incremental changes right on their local machines. As there is minimal effort required for the setup, you can achieve rapid feedback cycles.  - **Deploy in a Shared Cluster** is well-suited for scenarios that demand rapid deployments. This model supports quick provisioning and de-provisioning of environments within a shared cluster. That way, you can commit code frequently, and your builds will align with trunk-based workflows. **Feature Branches** When it comes to teams using feature branch workflows, where every feature gets its own branch, we have following choices: - **Deploy in Namespace** strikes a balance by offering isolated environments for each feature branch, all within a single cluster. This approach helps maintain separation while keeping resources efficiently shared. - **Deploy in Separate Clusters** is the go-to model if you prefer isolation over cost. It’s especially helpful for teams working on features that require strict separation due to compliance or security requirements.  - **Deploy in Shared Cluster with Routegroups:** While traditionally the shared cluster approach may not be ideal for feature branches due to isolation concerns, tools like routegroups (see [Signadot Routegroups](https://www.signadot.com/docs/reference/route-groups/spec)) enable routing between feature branches more efficiently. This makes it a viable third option that offers tunable isolation without requiring completely separate clusters. ##### Deployment Velocity **High Deployment Frequency** For teams with high deployment frequency, the **Deploy in Shared Cluster** model is often the best match: - This option makes it easy to provision and remove environments quickly, which is vital for continuous integration and deployment pipelines. - Shared resources and smart routing help minimize setup time, which is ideal for teams that need to deploy fast and frequently. **Moderate to Low Deployment Frequency** Teams with a more moderate deployment cadence might consider the **Deploy in Namespace** model: - This approach provides a good balance between resource use and environment isolation, making it well-suited for regular (but not necessarily rapid) deployments. - For lower deployment frequencies, **Microservices In-a-Box** may be sufficient for smaller applications, whereas **Deploy in Separate Clusters** works better if complete isolation is worth the cost. ##### Resource Efficiency When optimizing resource usage is a key goal, **Microservices In-a-Box** and **Deploy in a Shared Cluster** offer the most efficient solutions depending on the number of microservices: - **Microservices In-a-Box** minimizes resource consumption by running all services on a single machine, best for small-scale projects. For more ways to slim down dev and test setups, see our guide to [lightweight Kubernetes environments](https://www.signadot.com/articles/the-ultimate-guide-to-lightweight-kubernetes-environments/). - **Deploying in a Shared Cluster** lets you run multiple environments within a single cluster. This maximizes resource efficiency as the number of environments grows. However, as the number of microservices increases, resource contention may occur and requires careful management to prevent performance bottlenecks. ##### Scalability and Growth When more ephemeral environments are added, scalability becomes a key factor in determining which approach is best. Depending on how easily you can manage multiple copies of services and ensure efficient resource use, some methods will scale better than others. Let’s take a look at which strategies perform best in terms of scalability. - **Deploy in Separate Clusters:** This option provides the best scalability since you can add more clusters without affecting existing ones. Each cluster operates independently, offering complete isolation. This allows teams to develop and test in parallel without resource contention. It also enables customized configurations per cluster to suit specific needs. However, this approach significantly increases complexity and cost due to the need for multiple copies of services across clusters. - **Deploy in a Shared Cluster with Tunable Isolation:** This option is cost-efficient and can scale well with the addition of more microservices. It allows multiple ephemeral environments to coexist within a single cluster by adjusting isolation levels as needed. This maximizes resource utilization and simplifies management since all environments are centralized. Managing the baseline environment becomes crucial as more ephemeral environments are added and requires strong coordination to keep services synchronized. #### Ephemeral vs Static Environments A static environment such as shared staging runs continuously and serves every team at once. The [complete guide to staging environments](https://www.signadot.com/staging-environments/) covers that model on its own terms, including where it is still the right answer. For microservices it breaks down in three ways: - **Resource contention:** multiple teams competing for one shared environment creates queues that stretch development cycles by days or weeks. - **Test interference:** overlapping deployments collide, and test failures become nearly impossible to attribute to a root cause. - **Configuration drift:** long-lived environments diverge from production, producing the familiar “it works in staging” failures at release time. Audits regularly find shared staging idle 60 to 80 percent of the time while still consuming resources around the clock, so teams pay continuously for an environment that also blocks them. As one engineering leader at a Fortune 500 fintech put it: “When developers spend more time waiting for environments than writing code, you’re not just paying for infrastructure inefficiency; you’re paying for lost opportunities.” The measurable gains from switching are consistent across teams that publish numbers: infrastructure cost reductions of 85 to 90 percent when duplicated environments are replaced with request-level isolation, roughly 80 percent fewer production incidents from testing against real dependencies before merge, and order-of-magnitude faster feedback. [Brex saves about $2 million annually](https://www.signadot.com/blog/how-brex-transformed-developer-experience-and-slashed-infrastructure-costs-with-signadot/) after replacing per-developer environment copies with sandboxes, and [DoorDash cut feedback loops from over 30 minutes to under two](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/). Coding agents raise the stakes further. Agents open pull requests in parallel and around the clock, so the number of changes in flight jumps well past what a single shared environment can absorb. Even the conventional fix, duplicating the stack per change, fails at that volume on both cost and spin-up speed. Request-level isolation is the model that holds up: one shared baseline, only the changed services deployed per sandbox, and a marginal cost per environment close to zero, so hundreds of agent and pull-request environments fit on one cluster. #### Rolling Out Ephemeral Environments Without the Common Pitfalls Teams that make the transition smoothly tend to follow the same sequence. Start with an audit of current environments: how often teams queue, where configuration drift bites, and what the always-on footprint costs. Pick a pilot team with frequent pull requests, real service dependencies, and an existing CI pipeline rather than attempting a big-bang migration. And decide deliberately between building and buying: homegrown ephemeral-environment systems typically absorb 6 to 12 months of platform engineering effort before they are dependable, which is time most teams would rather spend on product. Four pitfalls account for most failed rollouts: - **Stateful and asynchronous dependencies.** Databases, Kafka, SQS, and third-party APIs need a plan. Share the baseline’s stateful resources where tests tolerate it, use per-sandbox ephemeral resources where they do not, and use [message-level isolation with per-sandbox consumer groups](https://www.signadot.com/blog/kafka-step-by-step-tutorial/) for queues. - **Observability.** Environments that disappear take their evidence with them. Persist logs and traces centrally beyond teardown, and rely on distributed tracing to follow requests across sandboxed and baseline services. - **Culture and process.** Teams used to long-lived environments, QA especially, need training, documentation, and early wins rather than a mandate. - **Security and compliance.** Regulated teams should design RBAC, secrets management, and audit trails into the environment model from the start rather than retrofitting them. #### Conclusion Choosing the right ephemeral environment strategy in Kubernetes depends on factors such as scalability, isolation, cost efficiency, branching strategy, deployment frequency, and budget constraints. For teams prioritizing rapid deployment and cost-effectiveness, models like Microservices In-a-Box or Deploy in Shared Cluster are ideal. If your focus is on isolation due to security or compliance needs, Deploy in Namespace or Separate Clusters offers stronger separation at the cost of added complexity and resource usage. At the end of the day, it is your technical and business needs that will drive the selection of the most suitable model. That choice matters more now than it used to. As agents write a growing share of the code, the environment is where validation either happens or stalls. Environments that are fast and cheap to create but still high fidelity are no longer just a developer-velocity nicety, they are what lets agents verify their own changes against real dependencies and keep continuous delivery moving. The shared-cluster model with tunable isolation is the one that holds up under that load. Give every change its own environment Signadot brings tunable isolation to your shared Kubernetes cluster, so teams test in parallel against real dependencies at a fraction of the cost of duplicating environments. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions What are ephemeral environments? Ephemeral environments are short-lived, on-demand environments created to test a specific code change, then torn down once it ships. In Kubernetes they give each change an isolated, production-like place to run against real dependencies without standing up a full staging copy. What is an ephemeral test environment? An ephemeral test environment is a temporary environment spun up for a single test run or pull request and destroyed afterward. It can take the form of a namespace, a virtual cluster, a separate cluster, or a sandbox on a shared cluster with request-level isolation. How do ephemeral environments work in Kubernetes? There are four common models: running all services on a single machine, isolating each environment in its own namespace, provisioning a separate cluster per environment, or sharing one cluster and isolating each change at the request level. Each model trades off cost, fidelity, spin-up speed, and maintenance differently. What is the difference between ephemeral and static environments? A static environment such as shared staging is long-lived and shared by every team, so it drifts from production and becomes a bottleneck. An ephemeral environment exists only for the change it validates, which keeps it clean, current, and free of contention. How much do ephemeral environments cost? It depends entirely on the isolation model. Duplicating the full stack per change scales cost with services times concurrent changes, which is why homegrown preview systems get expensive. Request-level isolation on a shared cluster deploys only the changed services, so the marginal cost of another environment is close to zero. Teams replacing duplication with this model report 85 to 90 percent lower infrastructure cost, and Brex saves about $2 million annually. How do ephemeral environments handle databases, Kafka, and other stateful dependencies? Three patterns cover nearly every case: share the baseline environment's databases and queues when tests tolerate shared state, attach per-sandbox ephemeral resources such as a temporary database when they do not, and isolate message queues at the message level, where producers tag messages with a routing key and each sandbox's consumers process only their own messages through dedicated consumer groups. Do ephemeral environments work with Istio and other service meshes? Yes. Request-level isolation composes naturally with a mesh: the platform propagates a routing key in request headers and the mesh routes each request to the sandboxed or baseline version of a service. Signadot integrates with Istio, including ambient mode, and also works without a mesh by handling routing through its own lightweight sidecars. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Staging Environments: The Complete Guide Source: https://www.signadot.com/staging-environments/ Summary: What a staging environment is for, why the single shared copy becomes a bottleneck at microservices scale, and the four alternatives compared on isolation, fidelity, spin-up time, and cost. ### Staging Environments: The Complete Guide A staging environment is where a change meets the real versions of its dependencies before release. This guide covers what it is for, why the single shared copy becomes a bottleneck at microservices scale, and the four fixes that work, compared. Type Guide Reading time 28 min Published September 3, 2026 A staging environment is the last stop before production: a copy of the system, built from the same artifacts and configuration, where a change runs against the real versions of its dependencies before real users see it. Unit tests and mocks check a service against assumptions about its neighbors. Staging checks it against the neighbors themselves, which is why nearly every team that ships software runs one. Staging comes from the era of the monolith and the release train. One application, one database, one deployable and a release every few weeks meant a single pre-production copy was cheap to run and rarely wanted by two people at once. The practice carried over unchanged into microservices, where the system is now dozens or hundreds of independently deployed services and the release is continuous. That is where the standard model stops scaling. The standard model is one staging environment that every developer deploys their changes into, so it can hold one integrated state of the system at a time. As teams grow, changes queue behind each other, the environment fills with half-finished work, and results stop being trusted. Coding agents multiply the number of changes that need validation: a 50-engineer team whose pipeline was built for 100 to 150 pull requests a day now faces closer to 1,000, and [average delivery throughput rose 59 percent in a year](https://www.signadot.com/blog/circleci-2026-report-agent-validation-gap/). A queue that was tolerable at human speed becomes the constraint on delivery. The stage is still necessary. What has to change is the assumption that staging means one environment everyone deploys into. This guide covers what staging is for, where it sits in the delivery pipeline, why that model breaks under load, what coding agents change about it, the fixes that do not work, and the four architectures that do, followed by how to run the staging environment you keep. Staging is one stage in the longer path covered by [The Complete Guide to Microservices Testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). #### What is a staging environment, and what is it actually for? A staging environment is a pre-production environment that mirrors production closely enough that a change passing there is expected to be safe to deploy. It is built from the same deployment artifacts and configuration as production, and it answers one question: does this change behave correctly against the real versions of everything it depends on. Tests that pass there are treated as a release gate. Staging exists because unit tests and mocked integration tests check a service against an assumption about its neighbors. Staging checks it against the neighbors themselves: the current version of the auth service, the actual schema of the orders database, the real message broker with its retry behavior, and third-party integrations in their sandbox modes. What staging is for: - Integration of many services at their current versions, including contract changes that mocks hide. - Configuration and infrastructure parity: the same ingress rules, network policies, secrets, resource limits, and Kubernetes version as production. - Release rehearsal: database migrations, rollout strategy, rollback. - Performance and load checks that need production-shaped data and real network hops. - Validation of agent-generated changes against real dependencies before a person reviews them. - Review of a complete feature by product owners or QA before it ships. What staging is not for: - Unit-level bugs. Those belong in the developer’s loop and in CI. - Individual iteration. A shared environment cannot host one engineer, or one coding agent, trying a change ten times an hour. - Proving a change is correct in isolation. Staging proves it is correct in company. Staging server, staging site, pre-prod, preprod, and pre-production environment are the other names for the same thing, with one distinction covered in the next section: some teams keep preprod as a separate, stricter final gate. Two different setups get called a shared staging environment, and the difference is the subject of this guide. In the first, every developer and agent deploys their change into the same environment, so it holds everyone’s work in progress at once and everyone competes for it. In the second, one environment holds the stable version of every service, each change deploys only the services it touches, and only that change’s test traffic sees them. The first stops scaling somewhere past a few dozen services. The second is what replaces it, and it is still one staging environment. #### Where staging sits: development, staging, and production Staging is the pre-production environment: the last place a change runs before it reaches production, and the first place it runs against the real versions of everything it depends on. Most teams run three kinds of environment. Development is where a change is written and run on its own, staging is where it meets the integrated system, and production is where real users hit it. Each step up trades speed for fidelity. The other environment names a reader will meet, test, integration, QA, UAT, pre-prod, and lower environments, are usually either another name for staging or an extra pre-production environment a team has split out of it. Environment What it is Tests that run there Dependencies Who uses it Development A developer's laptop or a cloud development environment (CDE), and now the working environment of every coding agent Unit tests, running and debugging the one service being changed Mocked, stubbed, or a handful of neighbors run alongside Individual developers and their agents Staging (pre-production) A deployed, production-like copy of the whole system Integration and end-to-end tests, QA and exploratory testing, user acceptance, performance checks, release rehearsal Real versions of every internal service, third-party integrations in sandbox mode Developers, CI pipelines, QA, product owners, release managers Production The system real users hit Canary and progressive rollout, synthetic checks, monitoring and alerting Real Everyone, indirectly The pattern in the table is the problem the rest of this guide is about. Everything before staging tests a service against assumptions about its neighbors. Staging is the first place it meets the neighbors themselves, so every test that needs real dependencies lands there: the suites CI kicks off, the branch a developer or agent wants to try before merge, QA’s exploratory pass, the product owner’s sign-off. One environment carries all of it, for every team at once. Some teams run more than one pre-production environment: a QA copy testers own, a UAT copy business users accept against, a pre-prod that takes only release candidates at production scale. These are all the same kind of environment as staging, and the names describe who uses the copy rather than what it is. Each one is another full dependency graph to run, sync and load with data, which is why most teams stop at one or two. ##### Staging vs production The difference is where the traffic comes from. Production serves real users with real data, and a failure there costs money and trust. Staging serves the team’s own test traffic against the same code and configuration, so a failure there costs only the time to fix it. Staging is usually scaled down in replica counts and node sizes, never in configuration or dependency fidelity. Is pre-prod the same as staging: at most companies, yes. Pre-prod and pre-production environment are simply other names for staging. Where a team keeps both, pre-production is the stricter one. It runs at production capacity, takes only release candidates rather than individual branches, and may be the target of a final production data clone or a canary rehearsal. DevelopmentStagingProductionunit, component(mocked)integration, end-to-end,QA, UAT, performancecanary,monitoring Every test that needs real dependencies lands on one staging environment. Developmentunit, component(mocked)Stagingintegration, end-to-end,QA, UAT, performanceProductioncanary, monitoring Every test that needs real dependencies lands on one staging environment. The [comprehensive guide to microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/) treats each type of test environment as an architecture choice rather than a label. #### Why shared staging becomes a bottleneck Shared staging, as the term is used here, means one staging environment that every developer and every coding agent deploys work in progress into. That environment can hold one integrated state of the system at a time, so every change in the organization has to pass through it in series. As service counts and change volume grow, three failures appear together and feed each other, and coding agents amplify all three. ##### Everyone deploys to it at once Shared staging has no admission control. Any team, or any agent, can deploy any branch to it at any time, and at scale every one of them does. CI adds its own load: the integration and end-to-end suites in the pull request pipeline have nowhere else to run, so every pipeline points them at staging, and each run’s result depends on whatever happened to be deployed there at the time. The environment fills with a mixture of half-finished changes from different teams, none of which is in production and most of which will never ship together. One team deploys a checkout change, another deploys an inventory change, and a third team’s test fails on an interaction between the two. Test results stop meaning anything. A red run might be your bug, someone else’s bug, or a collision between two changes that are both fine on their own, so engineers rerun, override, or skip failing tests. ShareChat hit this at more than 100 microservices and more than 300 engineers, with no way to test features independently before production short of building an in-house system. The [ShareChat case study](https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/) documents what changed once each change got its own isolated view of the cluster: more frequent deployments with fewer rollbacks. ##### Teams block each other waiting to test The alternative to deploying over each other is taking turns, and turn-taking makes shared staging a queue. Only one team’s change can be validated cleanly at a time, so everyone else waits. [Little’s law](https://en.wikipedia.org/wiki/Little%27s_law) describes the result: the number of changes waiting equals the rate at which changes arrive multiplied by the time each spends in the environment. Doubling the team doubles arrivals, and the time each change occupies staging does not fall, so the queue grows until people route around it. The visible signs are booking spreadsheets, a Slack channel named staging-lock, and “is anyone using staging” messages. The real cost is engineer time, and [Why Shared Staging Is the Most Expensive Tool You’re Not Accounting For](https://www.signadot.com/deep-dives/why-shared-staging-is-expensive/) works the arithmetic from a conservative one lost hour per developer per day, about 12.5 percent of engineering capacity. The mechanics of the staging bottleneck, and what Uber and Lyft built to escape it, are covered in [Staging Environment Challenges: The Bottleneck and How to Fix It](https://www.signadot.com/blog/the-staging-bottleneck-why-your-engineering-team-is-slow-and-how-to-fix-it/). ChangesStagingProduction One shared staging environment is a single queue every change has to pass through. ##### Staging is never actually like production The third failure is drift. Staging is supposed to be production-like, and a shared staging environment that is always full of unmerged branches is production-like in name only. It represents no real state of the system. A change that passes there has been validated against a configuration that will never exist, and a change that fails there may be reacting to someone else’s work in progress. Drift compounds through configuration and data as well. A manual fix applied to unblock a release never reaches the manifests, a dependency pinned for one team is never unpinned, and test data ages. Each is small, and together they make “it passed in staging” a weaker guarantee every month. Drift is also why the obvious fix, adding more staging copies, fails. Every copy drifts independently from main and from the others, so more copies means more environments that are each wrong in a different way. #### What AI coding agents change about staging environments Agents change staging on both sides: how many changes arrive, and how often each one needs the environment. A staging environment sized for human throughput is the first thing that breaks. Start with volume. CircleCI’s 2026 delivery data, covered in [the agent validation gap](https://www.signadot.com/blog/circleci-2026-report-agent-validation-gap/), puts average throughput up 59 percent year over year, with the top 5 percent of teams nearly doubling theirs while the bottom 25 percent saw no improvement at all. Around 30 percent of merge attempts still fail and median recovery has stretched to 72 minutes, up 13 percent. The teams absorbing a tenfold surge in pull request volume are the ones whose validation infrastructure scaled with it. [The agent PR flood](https://www.signadot.com/blog/the-agent-pr-flood-is-here-if-you-run-istio-youre-halfway-to-solving-it/) gives the shape of that surge: a 50-engineer team at two to three pull requests a day per person built its pipeline for 100 to 150 a day and now faces closer to 1,000. Then the loop. A person opens a pull request once and waits. An agent writes, tests, reads the failure and tries again, so it needs an environment on every attempt rather than once per feature. Claude Code, Cursor, Codex and Copilot all run that loop, and none of them can wait for a slot in a staging-lock channel. That moves where validation sits. Testing AI-generated code in a staging environment has to happen before a person reviews it. Otherwise the reviewer becomes the verification layer, and the review queue absorbs the flood the pipeline was supposed to. The mechanics of that shift are covered in [validating AI-generated code against real Kubernetes dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/). Per-run isolation matters more at this volume, not less. Batching agent changes into one staging deploy turns every failure into a search through dozens of candidates for the one that caused it, and an agent cannot act on a result it cannot attribute. Each run needs its own view of the system, tagged so logs and traces point back to it. Cost and cleanup become policy rather than habit. Hundreds of runs a day only stay affordable if a run deploys the services it changed and nothing else, and if environments carry a time to live that reclaims them without anyone remembering to. An environment per pull request that survives until someone notices it is how an agent-era staging bill doubles. Last, the path in. An agent needs to create and destroy its environment through the same interface it uses for everything else, which in practice means a CLI or an MCP server rather than a console someone clicks. [The Staging Trap: How to Unblock AI Coding Agents in Enterprise Kubernetes](https://www.signadot.com/blog/scaling-coding-agents-enterprise-kubernetes/) covers what that validation path looks like at this volume. #### Do you need a staging environment at all? You need the stage. You do not necessarily need a single environment that everyone deploys into to provide it. Every team needs a place where a change, whether a developer or an agent wrote it, meets the real versions of its dependencies before real users do. Whether that place is one environment everyone deploys into, one environment per change, or an isolated view of a shared cluster is an architecture decision, and the right answer depends on how many services and how many concurrent changes the team has. For a monolith, or a small system of a handful of services, one staging environment that everyone deploys into is the correct answer. It is cheap to run, easy to keep current with the main branch, and the number of people who want it at the same time is small enough that a short queue is tolerable. Do not over-engineer this case. For a microservices system with dozens of services and many teams and agents shipping independently, that model stops providing the stage it was built for. The sections after this one cover what replaces it. There is also an argument for skipping staging and testing in production, where feature flags, canary releases and progressive delivery expose a change to a slice of real traffic and roll back on the first bad signal. That works for changes whose failure is observable and reversible in seconds. It does not work for schema migrations, payment flows, or anything regulated, and it moves the cost of a wrong guess onto real users. The case for it, and its limits, is made in [It’s Time To Kill Staging: The Case for Testing in Production](https://www.signadot.com/blog/its-time-to-kill-staging-the-case-for-testing-in-production/). The stronger form of that argument is that the isolation staging used to provide can be recreated per change inside production-like infrastructure, which is the model the rest of this guide arrives at. #### Fixes that do not work, and why The first fixes most teams try treat the symptom rather than the cause. Each of the four below is reasonable on its face, and each fails for a reason worth understanding, because the reason points at what a working fix has to do differently. **Adding more staging copies.** If one staging environment is contended, run three, or one per team. Cost scales linearly with the number of copies, since each is a full duplicate of the dependency graph, and drift multiplies, because several environments now each need to be kept current with main and with each other. Data is the hardest part: every copy needs its own datastores, and third-party integrations end up shared anyway. [Environment Replication Doesn’t Work for Microservices](https://www.signadot.com/blog/environment-replication-doesnt-work-for-microservices/) puts the inflection point around 50 engineers and 25 services. **Feature flags as isolation.** Wrapping every in-progress change in a flag so it can sit in staging without affecting other testers gates behavior, but it does not isolate state or dependencies. A flagged change that alters a schema, writes to a shared queue, or changes a response format still affects everyone the moment it runs. They also accumulate in the codebase and were designed for controlled production rollout rather than testing. [The pitfalls of feature flagging in shared staging](https://www.signadot.com/blog/pitfalls-of-using-feature-flagging-for-testing-in-shared-staging-environments/) covers the failure modes, and [feature flags versus preview environments](https://www.signadot.com/blog/microservices-testing-feature-flags-vs-preview-environments/) covers where flags do belong. **Booking calendars and Slack locks.** Turn-taking makes contention orderly. It does not reduce it. The same number of changes arrive and each occupies the environment for the same time, so the queue is the same length, only better documented. Locks also fail in the common cases: a test runs longer than its slot, a developer forgets to release the lock, or two teams’ changes need to be in staging at the same time to test an interaction. Locks also assume a person is holding them: a coding agent in a build-test-fix loop cannot wait for a reply in a channel, so it either blocks or skips validation. **Mocking the way out of integration.** If staging is unreliable, mock every dependency and run integration tests in CI instead. Mocks keep the loop fast, but each mock encodes one team’s understanding of another team’s contract at one point in time, and the two drift apart as the real service changes. The result is the failure every microservices team recognizes: integration tests pass with mocks and staging still breaks. [Integration tests pass with mocks but staging still breaks](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/) lays out the ladder from contract tests to real-dependency tests that closes the gap. What the four have in common is that none of them changes the unit of isolation. Each still assumes a change has to be validated inside a whole environment. The fixes that work change that assumption. #### What are the alternatives to a shared staging environment? The alternatives all give each change its own isolated view of the system instead of a turn at an environment everyone deploys into. They differ in how much infrastructure that isolation costs per change, which is what people are asking for when they search for lightweight staging environments. Ordered from most to least infrastructure per change, the four are a full ephemeral environment per pull request, a namespace per developer or pull request, a preview environment for frontend and stakeholder review, and request routing on a shared cluster. **Full ephemeral environment per pull request.** Every pull request gets a complete copy of the system, provisioned when the PR opens and destroyed when it merges. This is the model [Release](https://release.com/), [Bunnyshell](https://www.bunnyshell.com/), [Shipyard](https://shipyard.build/), and [Qovery](https://www.qovery.com/) offer as a product. Fidelity per copy is the highest, because nothing is shared. So is cost, which scales with services multiplied by open PRs: a 40-service system with 30 open PRs runs 1,200 service instances. Spin-up grows with the size of the copy. The tradeoffs in detail are on the [Signadot vs Release comparison](https://www.signadot.com/comparison/release/). **Namespace per developer or pull request.** The same idea built from Kubernetes primitives: a namespace per environment, with resource quotas and network policies for isolation, sharing one cluster’s control plane and nodes. It is cheaper than a cluster per environment and uses tools the team already has, but it still duplicates every service into every namespace. Data has to be loaded per namespace, nothing keeps namespaces in sync with main, and startup time grows with the application. [Kubernetes Namespace vs Cluster: Pros and Cons for Test Environments](https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/) compares both options. A virtual cluster sits between this tier and a full environment: its own API server on shared nodes buys a harder boundary than a namespace at close to namespace cost, and still duplicates the workloads. **Preview environments for frontend and stakeholder review.** A preview environment gives a branch its own URL so a reviewer can click through a change before merge, and for frontend work it is often one build pointed at shared backend services, which makes it cheap and fast. Whether it is also a valid integration test depends on what sits behind the URL: a full copy, a namespace, or a routed slice. [What Are Preview Environments? The Complete Kubernetes Guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) covers that distinction. **Request routing on a shared cluster.** One staging environment still exists and is still shared, but what is shared is the set of stable service versions, not the place everyone deploys into. Each change deploys only the service or services it touches, alongside those stable versions. Tag test requests with a routing key in a header, and have each hop send a tagged request to the changed version when one exists and to the shared stable version when it does not. Isolation happens in the routing layer rather than by duplicating the environment, so every change gets an isolated staging environment of its own and hundreds can be under test on one cluster at once. A change costs the one or two services it deploys, and spin-up is seconds, because there is nothing else to provision. Full environment per PRPR 1PR 2PR 3Namespace per PRns 1ns 2ns 3one clusterPreview environmentUI 1UI 2UI 3shared backendRequest routingshared serviceschange Achange Bchange Cper change Purple marks what each change has to deploy for itself. Full environment per PRPR 1PR 2PR 3Namespace per PRns 1ns 2ns 3one clusterPreview environmentUI 1UI 2UI 3shared backendRequest routingshared serviceschange Achange Bchange Cper change Purple marks what each change has to deploy for itself. Approach Isolation Production fidelity Spin-up time Cost per change Best fit Full environment per PR Complete, nothing shared Highest per copy Minutes to tens of minutes, grows with stack size Full stack per open PR Under about ten services, or where hard isolation is required Namespace per developer or PR Namespace boundary on a shared cluster Medium, drifts between syncs Minutes, grows with application size Every service per namespace Small to mid-size teams already fluent in Kubernetes Preview environment (frontend) The frontend only Backend is shared Seconds to minutes One build UI review, stakeholder demos Request routing on a shared cluster Routing-based, per change High, real shared dependencies Seconds Only the changed services Dozens to hundreds of services, many concurrent changes The request-routing approach has four prerequisites: - Every service has to propagate the routing header on outgoing calls. This is application-layer work a service mesh alone cannot do for you, usually handled through [OpenTelemetry baggage](https://opentelemetry.io/docs/concepts/signals/baggage/) or [B3 propagation](https://github.com/openzipkin/b3-propagation). - Asynchronous flows need the key carried in message metadata and consumers that honor it, which is its own piece of work for [Kafka, SQS and other message queues](https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/). - Changes that alter a schema or write destructively need their own ephemeral datastore rather than the shared datastore. Bitso does this per branch with [Signadot and Neon](https://www.signadot.com/blog/how-bitso-is-scaling-branch-based-development-with-signadot-and-neon/). - The shared stable versions have to be kept green. The approach shrinks staging to a shared set of dependencies but does not remove the need to operate one. Large engineering organizations built this internally before it existed as a product. Lyft built Onebox on [Envoy](https://www.envoyproxy.io/) sidecars, Razorpay built Devstack on a [Traefik](https://traefik.io/) ingress with context in OpenTelemetry baggage. Both are described in [how Lyft and Razorpay share development environments with hundreds of devs](https://www.signadot.com/blog/how-lyft-and-razorpay-share-development-environments-with-hundreds-of-devs/). Signadot provides this mechanism as a product, on the staging cluster you already run. A Sandbox deploys only the changed services next to the shared stable versions and receives a unique routing key: requests carrying that key reach the sandboxed versions at every hop, everything else falls through. Every developer, pull request and coding agent gets its own view of one staging environment, and hundreds coexist on it with no contention. That is what the [Kubernetes test environments](https://www.signadot.com/solutions/kubernetes-test-environments/) solution delivers, the four options above are compared in depth in the [guide to ephemeral environments on Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), and the mechanism itself is defined on the [Kubernetes sandbox](https://www.signadot.com/kubernetes-sandbox/) page. requestservice-2service-1service-1bFORKservice-3dbtagged requestshared dependencies The tagged request reaches the forked service and then calls the same shared dependencies as everything else. requestservice-1service-1bFORKdbtagged requestshared dependencies The tagged request reaches the forked service and then calls the same shared dependencies as everything else. #### If you keep a staging environment, run it like a product A staging environment with no owner is the one that is always broken. Request routing does not remove this environment. It changes what is shared: the environment stops being the place everyone deploys into and becomes the set of stable services every isolated change tests against, which makes its health more important, not less. In practice that means four commitments: scale down capacity but never fidelity, deploy every merge to main automatically through GitOps so the environment is never more than one merge behind, give it a named owner with a rotation and published SLOs for time green and time-to-test, and share it through routing rather than turn-taking. [Kubernetes Staging Environments: How to Build, Run, and Share One](https://www.signadot.com/blog/kubernetes-staging-environment/) has each of those as a full reference architecture, with the Argo CD wiring. ##### Running a Kubernetes staging environment A Kubernetes staging environment is its own cluster running the same Kubernetes version, add-ons, ingress rules and network policies as production, fed by the same manifests. Staging environment testing means exercising a change there, against those dependencies, before it reaches users. The split most teams land on is one cluster each for dev, staging and production, with staging scaled down in replicas and node sizes and identical in everything else. Namespaces inside that cluster separate concerns, not environments: a namespace per team or per change still duplicates every service, which is the cost the [namespace versus cluster comparison](https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/) works through. Keeping Kubernetes staging and production aligned is most of the job, and staging testing is only as trustworthy as the configuration drift between the two. Track that drift as a number rather than an intention: how many merges behind main the environment is, and how many manifest differences exist between the two clusters that are not replica counts or node sizes. Both belong on the same dashboard as the smoke checks. ##### How QA and stakeholders get access Access decides whether a centralized staging environment stays useful once more than engineers depend on it. QA engineers, product owners and support need a URL that reaches a specific version of the system, not a turn at the whole environment. A shared environment offers only the second, which is why QA access usually degrades into a booking channel. Routing solves it the same way it solves contention. A tester opens the environment with a routing key attached, through a preview URL or a browser extension that sets the header, and sees that change against the shared stable services. Nobody redeploys and nobody else notices. For frontend review, [preview environments](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) cover what sits behind the URL. Developers get the same treatment from the other direction: run the one service you are changing locally and connect it into the shared environment, so your process answers tagged requests while every dependency stays real. That closes the gap behind the complaint that QA finds bugs in staging nobody can reproduce locally. [Local development on Kubernetes](https://www.signadot.com/guide-to-local-development-kubernetes/) covers the mechanics. Data deserves its own decision, and the workable strategy runs in three tiers: synthetic seed data for most functional testing, an anonymized subset of production refreshed on a schedule where behavior depends on real data distributions, and an ephemeral per-change database for schema migrations and other destructive work. The [reference architecture](https://www.signadot.com/blog/kubernetes-staging-environment/) covers how to load and refresh each. Raw production data containing personal information never belongs in staging, whatever the access controls, because staging is by design the environment the most people can reach. ##### Sharing production traffic with staging Shadowing a sample of production traffic into staging, or replaying captured requests, raises fidelity further once the environment is stable. It exercises the code paths real users hit rather than the ones test authors imagined, which is the fastest way to close the last gap in environment parity. It needs the same data discipline as any other tier: scrub the payloads, and make sure shadowed writes land in staging datastores rather than anything shared with production. #### Staging environment best practices checklist Audit an existing staging environment against these twelve items. Each is a yes-or-no question, and each no maps to a failure mode from the sections above. 1. Staging is built from the same artifacts and manifests as production, with only replica counts and node sizes reduced. 2. Every merge to main deploys to staging automatically, and the current lag behind main is visible on a dashboard. 3. Staging has a named owner and an on-call rotation. 4. Staging has at least two published SLOs: percentage of time green, and time from request to availability. 5. No manual configuration changes are made in staging. Fixes go through the same pipeline as production. 6. Test data is synthetic or anonymized. No raw production personal data is present. 7. Changes that alter schemas or write destructively get an ephemeral datastore rather than the shared datastore. 8. Two teams, or a developer and an agent, can test conflicting changes at the same time without coordinating in a chat channel. 9. A failed test in staging can be attributed to a specific change without asking who else deployed. 10. Unit and component tests run before staging, not in it. Staging is for integration, parity, and rehearsal. 11. Third-party integrations point at the vendor’s sandbox or test mode, never at live accounts. 12. The cost of staging, including engineer waiting time, is measured and reviewed quarterly. Teams that can answer yes to items 8 and 9 have already stopped deploying everything into one environment, whether or not they call it that. #### Staging in regulated industries In fintech and healthcare, staging carries extra obligations. [PCI DSS](https://www.pcisecuritystandards.org/), [GDPR](https://gdpr.eu/) and [HIPAA](https://www.ecfr.gov/current/title-45/part-164) apply to any environment holding regulated data, audit trails have to show what was tested and by whom, and residency rules constrain where copies can run. Every additional full copy is another copy of sensitive data to govern and certify. Per-change isolation helps here rather than fighting it. Fewer copies means fewer places regulated data can exist, Sandboxes inherit the shared cluster’s access controls, encryption and audit logging instead of each copy being re-certified, and because logs and traces carry the sandbox identity, every test run is attributable to a change and a person or agent. Environments stay inside the cluster and region the organization already controls, so residency is unchanged. The payments and lending specifics are in [Breaking the Staging Bottleneck: Scalable Microservices Testing for Fintech](https://www.signadot.com/resources/breaking-the-staging-bottleneck-scalable-microservices-testing-for-fintech/). The compliance mapping is on the [microservices testing for fintech](https://www.signadot.com/microservices-testing-for-fintech/) page. #### Where to go next If your single staging environment still works, [Kubernetes Staging Environments: How to Build, Run, and Share One](https://www.signadot.com/blog/kubernetes-staging-environment/) shows how to operate it as a product before the queue forms. If the queue has formed and you are weighing an environment per change against a shared cluster, the [guide to ephemeral environments on Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) compares the four options in depth. If you have settled on request routing, the [Kubernetes test environments](https://www.signadot.com/solutions/kubernetes-test-environments/) page describes what Signadot provides. #### Related reading - [Staging Environment Challenges: The Bottleneck and How to Fix It](https://www.signadot.com/blog/the-staging-bottleneck-why-your-engineering-team-is-slow-and-how-to-fix-it/) - [Why Shared Staging Is the Most Expensive Tool You’re Not Accounting For](https://www.signadot.com/deep-dives/why-shared-staging-is-expensive/) - [Kubernetes Staging Environments: How to Build, Run, and Share One](https://www.signadot.com/blog/kubernetes-staging-environment/) - [It’s Time To Kill Staging: The Case for Testing in Production](https://www.signadot.com/blog/its-time-to-kill-staging-the-case-for-testing-in-production/) - [Integration tests pass with mocks but staging still breaks](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/) - [The Pitfalls of Using Feature Flagging for Testing in Shared Staging Environments](https://www.signadot.com/blog/pitfalls-of-using-feature-flagging-for-testing-in-shared-staging-environments/) - [Microservices Testing: Feature Flags vs. Preview Environments](https://www.signadot.com/blog/microservices-testing-feature-flags-vs-preview-environments/) - [The Staging Trap: How to Unblock AI Coding Agents in Enterprise Kubernetes](https://www.signadot.com/blog/scaling-coding-agents-enterprise-kubernetes/) - [How Lyft and Razorpay share development environments with hundreds of devs](https://www.signadot.com/blog/how-lyft-and-razorpay-share-development-environments-with-hundreds-of-devs/) - [Environment Replication Doesn’t Work for Microservices](https://www.signadot.com/blog/environment-replication-doesnt-work-for-microservices/) - [Kubernetes Namespace vs Cluster: Pros and Cons for Test Environments](https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/) - [What Are Preview Environments? The Complete Kubernetes Guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) - [Breaking the Staging Bottleneck: Scalable Microservices Testing for Fintech](https://www.signadot.com/resources/breaking-the-staging-bottleneck-scalable-microservices-testing-for-fintech/) - [ShareChat case study](https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/) - [Ephemeral environments on Kubernetes: the complete guide](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) - [Kubernetes sandbox](https://www.signadot.com/kubernetes-sandbox/) - [A comprehensive guide to microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/) - [The Complete Guide to Microservices Testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/) #### Frequently asked questions What is a staging environment? A staging environment is a pre-production copy of a system, built from the same code, configuration, and infrastructure definitions as production, where a change is validated against the real versions of its dependencies before release. Tests that pass there are treated as a release gate. It is scaled down in capacity, not in fidelity, and uses anonymized or synthetic data rather than live user data. What is the difference between staging and production? Production serves real users with real data, and failures there cost revenue and trust. Staging runs the same code and configuration but serves only the team's test traffic, so failures there cost only the time to fix them. Staging typically runs fewer replicas and smaller nodes than production, and should never differ from it in dependency versions, network policy, or configuration. What is the difference between dev, test, QA, UAT, staging, and pre-production? They describe levels of testing fidelity, not six environments most teams run. Development is the developer's or agent's own environment, local or cloud-hosted, with mocked dependencies. Test and integration usually refer to the automated suites CI runs, against mocks or against staging. Staging is the deployed, production-like environment where integration, end-to-end, QA, and acceptance testing run against real dependencies. QA, UAT, and pre-production are other names for staging or extra pre-production copies split out for testers, business users, or release candidates. Do you need a staging environment? You need a stage where a change meets the real versions of its dependencies before users do. A monolith or small system is well served by one shared staging environment. A system with dozens of services and many concurrent changes needs per-change isolation instead, as a full environment or a routed slice of a shared cluster. Testing only in production suits reversible, observable changes, not migrations, payments, or regulated data. Why does a shared staging environment become a bottleneck? A staging environment that everyone deploys into holds one integrated state of the system at a time, so every change has to pass through it in series. As teams and change rate grow, changes queue, the environment fills with unrelated half-deployed work so failures cannot be trusted, and engineer time spent waiting and repeating work becomes the largest cost. Coding agents multiply the change rate and lengthen the queue. What is the alternative to a shared staging environment? The alternatives give each change its own isolated view of the system. A full ephemeral environment per pull request offers complete isolation at the highest cost. A namespace per change is cheaper but still duplicates every service. Request routing on a shared cluster deploys only the changed services and routes tagged test requests to them, so hundreds of changes share one cluster while none shares its work in progress. Should staging use production data? Not raw production data. Staging is the environment the most people can reach, so personal or regulated data does not belong there under any access control. Use synthetic seed data for most testing, an anonymized subset of production refreshed on a schedule where behavior depends on real data distributions, and an ephemeral per-change database for schema migrations and other destructive operations. What is the difference between a staging environment and a sandbox? A staging environment is the long-lived, production-like deployment of the whole system. A sandbox is one change's isolated view of it: only the services that change are deployed, and a routing key sends that change's test traffic to them while everything else falls through to the shared stable versions. Sandboxes do not replace the staging environment. They run on it, which is how hundreds coexist without anyone deploying over anyone else. How do AI coding agents change staging environment requirements? Agents raise both the number of changes needing validation and the number of attempts per change. A build-test-fix loop needs an environment on every iteration, not once per feature, and it cannot wait for a slot in a chat channel. That rules out a single shared staging environment and any queue in front of it. What works is per-change isolation on one staging cluster, created in seconds and torn down on merge. Can a coding agent test its change against real dependencies before opening a pull request? Yes, if each change gets its own isolated view of a staging environment rather than a turn at a shared one. Agents such as Claude Code, Cursor, Codex and Copilot can call a CLI or an MCP server to create a sandbox holding only the services they changed, run tests against the real shared dependencies, read the results and fix the change before a person sees it. Validation moves ahead of review instead of behind it. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## What Is a Kubernetes Sandbox? Source: https://www.signadot.com/kubernetes-sandbox/ Summary: The two meanings of a Kubernetes sandbox: a secure box for running untrusted or AI-generated code, and a lightweight environment for testing a change against real services. ### What Is a Kubernetes Sandbox? A Kubernetes sandbox can mean two different things: a secure box for running untrusted or AI-generated code, or a lightweight environment for testing a change against real services. This explainer covers both and shows where each one fits. Type Guide Reading time 7 min Published June 21, 2026 Updated August 31, 2026 Search for “Kubernetes sandbox” today and you get two unrelated answers. One is a secure box for running untrusted or AI-generated code. The other is a lightweight, isolated environment for testing a code change against real services. They share a name and almost nothing else. This page explains both, so you can tell which one you actually need. #### The short version A Kubernetes sandbox is a temporary, isolated place to run or test something on a cluster without affecting everything else. The term splits into two camps: The second kind is what replaces a turn at a shared staging environment, a tradeoff covered in the [complete guide to staging environments](https://www.signadot.com/staging-environments/). - **Run-something sandboxes** care about safety. They give code you don’t fully trust, often code an AI agent just wrote, its own locked-down place to execute so it cannot touch the host or other tenants. - **Test-something sandboxes** care about fidelity. They let a developer or an agent try a change against the real services, databases, and queues it will run with in production, without copying the whole stack. If you are running code you don’t trust, you want the first kind. If you are checking whether a change works, you want the second. Signadot builds the second kind. #### A sandbox for running code safely This is the meaning that has taken over the term lately, pushed by AI coding agents. When an agent writes and runs code on its own, that code needs somewhere isolated to execute. Two layers of tooling cover this. At the lower level are general execution sandboxes that will run code from any kind of agent, not just a coding one: - [E2B](https://e2b.dev/) runs each session in a Firecracker microVM, so the code gets its own kernel and a hardware-level boundary. - [Daytona](https://www.daytona.io/) focuses on fast startup for running AI-generated code, with an SDK that agents call to open a session. - [agent-sandbox](https://agent-sandbox.sigs.k8s.io/), a Kubernetes SIG project (`kubernetes-sigs/agent-sandbox`), adds a `Sandbox` custom resource for long-running, stateful agent runtimes, using gVisor or Kata Containers for kernel and VM-grade isolation. A layer up are environments built specifically for coding agents. [Ona](https://ona.com/) (formerly Gitpod) is one example: it gives each software engineering agent a full, isolated cloud workspace to read the repo, write code, run it, and open a pull request. The focus here is the development workflow, not just safe execution. The common thread across both layers is the same: they isolate where code runs. The question they answer is “where can this agent do its work without doing damage?” None of them tell you whether the change is actually correct against your real services. #### A sandbox for testing a change This is what Signadot means by a sandbox. Here the problem is not safety. It is that you cannot tell if a change works until it runs against its real dependencies. Spinning up a full copy of thirty services for every change is slow and expensive, and a single shared staging environment turns into a queue. A Signadot Kubernetes sandbox solves this with tunable isolation. You start from a shared, production-like baseline cluster and decide, for each change, what to isolate and what to borrow from the baseline. For the services you are changing, a routing key on each request sends traffic to your version while everything else falls through to the baseline. For stateful dependencies you isolate as much as the test needs: [resource plugins](https://www.signadot.com/docs/reference/resource-plugins) spin up ephemeral [database instances](https://www.signadot.com/docs/guides/set-up-data-isolation) on demand, and for message queues you either route messages by the same key or spin up [ephemeral topics](https://www.signadot.com/docs/guides/set-up-message-queue-isolation). Because you choose what is shared and what is forked, you get a high-fidelity, production-like environment without copying the whole stack, and many developers or agents can run their own sandboxes on the same cluster at once. This is the same idea behind [ephemeral environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/): start from a shared baseline and isolate only what each change needs. Execution sandbox Coding-agent environment Signadot sandbox Examples E2B, Daytona, kubernetes-sigs/agent-sandbox Ona (formerly Gitpod) Signadot What it does Runs any code in isolation Hosts a coding agent so it can write and run code Tests a change against real services in a cluster Scope Any agent The coding workflow The coding workflow Answers Can this run safely? Where does the agent work? Does this change actually work? #### How to create a Kubernetes sandbox The right way to create a sandbox follows from which of the two meanings you need. **For learning and experimentation.** If “sandbox” just means a safe cluster to poke at, run one locally with [kind](https://kind.sigs.k8s.io/) or [minikube](https://minikube.sigs.k8s.io/), or use a hosted playground. Nothing you break matters, and teardown is one command. **For running untrusted or AI-generated code.** Define a `RuntimeClass` backed by a hardened runtime such as gVisor or Kata Containers and schedule the untrusted pods onto it, or use a purpose-built controller like [agent-sandbox](https://agent-sandbox.sigs.k8s.io/), which wraps this in a `Sandbox` custom resource with stable identity and persistent storage. The boundary you get is the point: the code cannot touch the host kernel or other tenants. **For testing a change against real dependencies.** Copying the stack into a namespace or a separate cluster per change works at small scale, but the cost and spin-up time grow with every service. The request-level approach avoids that: a short spec forks only the workloads you changed onto the shared baseline cluster, and a routing key steers matching requests to your version. With Signadot that spec looks like this: ``` name: my-feature spec: cluster: staging forks: - forkOf: kind: Deployment namespace: hotrod name: route customizations: images: - image: myrepo/route:pr-42 ``` Applying it creates a sandbox in seconds. Requests carrying the sandbox’s routing key hit your forked service; every other request flows through the untouched baseline. The [Kubernetes test environments](https://www.signadot.com/solutions/kubernetes-test-environments/) page covers how teams run this pattern at scale. Try a Kubernetes sandbox on your own cluster Isolate only what each change needs, from services to databases and queues, share the rest, and test against real dependencies in minutes. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### How they fit together These pieces are complementary, and the coding case is where they line up best. A coding agent can run inside an environment like Ona, where it has a workspace to read the repo, write code, and open a pull request. That covers writing and running the code. It does not cover whether the change works against the rest of your system. That is the gap Signadot fills. You connect the agent’s environment to a real Kubernetes cluster and run the change against live services, databases, and queues, the same dependencies it will meet in production. The coding agent writes the change in a host like Ona, and Signadot lets it run integration and system tests against the real cluster before the pull request merges. So the split is clean. A tool like Ona hosts the agent and its workspace. Signadot handles the integration testing and verification against real dependencies. One proves the code can run. The other proves the change does what it should. For more on that step, see [validating AI-generated code against real Kubernetes](https://www.signadot.com/validate-ai-generated-code-kubernetes/). #### When to use a Signadot Kubernetes sandbox - Developing locally against real cluster dependencies, without rebuilding images for every change. - Previewing a pull request in a production-like environment before it merges. - Running integration and end-to-end tests in parallel, one sandbox per change. - Letting a coding agent check its own work against the real system. For the bigger picture on testing across the lifecycle, see the [complete guide to microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). Test your next change in a real Kubernetes sandbox Spin up an isolated sandbox on the cluster you already run, test against live dependencies, and tear it down when you are done. Start free, no stack duplication required. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions What is a Kubernetes sandbox? A Kubernetes sandbox is a temporary, isolated place to run or test something on a cluster without affecting everything else. The term covers two different things: a secure execution box for running untrusted or AI-generated code (using gVisor, Kata Containers, or microVMs), and a lightweight test environment where a code change runs against the real services on a shared cluster. What is the difference between a Kubernetes sandbox and a namespace? A namespace is a logical grouping inside a cluster, but workloads in one namespace can still reach services, queues, and databases in another, and copying a full stack into a namespace per change is slow and expensive. A sandbox adds an actual isolation boundary: either a hardened runtime around untrusted code, or request-level routing that isolates one change's traffic while sharing the rest of the cluster. Is a Kubernetes sandbox the same as agent-sandbox? No. agent-sandbox (kubernetes-sigs/agent-sandbox) is a specific open source project that adds a Sandbox custom resource for running AI agent workloads in isolation, using gVisor or Kata Containers. It belongs to the run-something-safely camp. A testing sandbox, like Signadot's, answers a different question: whether a change works against its real dependencies. How do I create a Kubernetes sandbox? It depends on which kind you need. For a safe place to learn or experiment, run a local cluster with kind or minikube. For running untrusted code, use a hardened runtime such as gVisor or Kata Containers via a RuntimeClass, or the agent-sandbox controller. For testing changes against real services, use a platform like Signadot: apply a short sandbox spec that forks only the workloads you changed on a shared baseline cluster. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Validating AI-Generated Code Against Real Kubernetes Dependencies Source: https://www.signadot.com/validate-ai-generated-code-kubernetes/ Summary: Why a closed validation loop, real cloud-native dependencies, and infrastructure that scales to thousands of parallel agents turn AI-generated pull requests into software you can ship. ### Validating AI-Generated Code Against Real Kubernetes Dependencies Coding agents now write code faster than teams can verify it, and the bottleneck has moved from generation to proof. This guide explains why a closed validation loop, real cloud-native dependencies, and infrastructure that scales to thousands of parallel agents are what turn a flood of AI-generated pull requests into software you can ship. Type Guide Reading time 12 min Published June 21, 2026 **Validating AI-generated code** means proving that the change a coding agent produced actually works against the real services, databases, and message queues it will run with in production, not just that it compiles or passes a unit test. As agents move from autocomplete to opening pull requests on their own, the constraint on software delivery shifts from writing code to verifying it. This guide walks through why verification is the step that decides whether agents speed your team up or bury it, why the problem is hardest in cloud-native systems, what it actually takes to call a change verified, and how to make that verification fast and cheap enough to run on every change an agent produces. The short version: agents need a closed loop they can run themselves, against real dependencies, on infrastructure that scales to their volume. Everything below builds on that idea. For why the environment those dependencies live in cannot be a single shared copy, see the [complete guide to staging environments](https://www.signadot.com/staging-environments/). #### Why verification is the step that lets agents keep going For most of software’s history, typing the code was the slow part. That assumption no longer holds. A single engineer running coding agents can open more pull requests in a day than a small team used to open in a week. The agents are fast, tireless, and increasingly capable. The problem is that generation speed only turns into shipped product if every change can be verified quickly, and verification is now the rate limiter. There is a deeper reason verification matters so much for agents specifically, and it has to do with how they work. A coding agent makes progress by acting, observing the result, and deciding what to do next. When it cannot observe whether its change worked, it has to stop and ask a human, or worse, it guesses and keeps building on top of an unverified assumption. Either way the agent’s run ends early. Give the same agent a way to test its change, read real results, and correct itself, and it can stay productive for far longer without supervision. The verification step is what closes the loop. Write or fixthe changeValidate in a sandboxagainst real dependenciesRead theresultsPasses:ready forreviewFails or regresses: the agent fixes it and runs again, no human needed The closed loop is what keeps an agent moving on its own until the change actually works. This is why the most interesting agent results share a shape. When an agent can verify and correct its own work, it behaves less like an autocomplete and more like an engineer, as the team behind [Ramp’s Inspect described in detail](https://www.signadot.com/blog/ramps-inspect-shows-closed-loop-ai-agents-are-softwares-future/). The same pattern shows up in our own walkthrough of [Claude Code validating a microservices change end to end](https://www.signadot.com/blog/claude-code-signadot-validate-demo/): the agent provisions an environment, runs checks, reads what broke, and fixes it without a person in the path. Industry data is starting to name the gap too. The [2026 CircleCI report on the agent validation gap](https://www.signadot.com/blog/circleci-2026-report-agent-validation-gap/) found that teams adopting agents fastest are the ones whose biggest unsolved problem is verifying what those agents produce. Closing the loop, as we have [argued for cloud-native systems](https://www.signadot.com/blog/closing-the-loop-coding-agents-cloud-native/), is the difference between an agent that generates code and one that ships changes you can trust. #### Why this is a cloud-native problem first The reason verification is hard is almost never the changed file by itself. It is the system around it. A modern application is a mesh of dozens or hundreds of services talking over the network, backed by databases, caches, and queues, deployed on Kubernetes. The behavior that matters emerges from how those pieces interact, and a coding agent has no way to predict that from the source alone. To know whether a change works, you have to run it in something that looks like production. That is why Signadot is built for cloud-native environments first. The hard cases live there: request-level routing between services, real data stores, service meshes like Istio and Linkerd, asynchronous messaging. An approach that handles validation cleanly in that setting handles the easier cases for free. We think about the problem more broadly than Kubernetes, because the principle, give the agent a real environment and a loop it can drive, applies anywhere agents write code. But cloud-native is where the need is sharpest and where most teams running agents at scale already are. Claude and other agents need [a real place to run a change, not a mock of one](https://www.signadot.com/blog/claude-cloud-native-validation/), and in a cloud-native system that place is non-trivial to provide. #### What “verified” means for a cloud-native change, and why it is hard It is tempting to treat verification as a single checkbox: the tests passed. In a cloud-native system it is closer to a long tail of distinct questions, and a change can answer most of them correctly while quietly failing one that matters. On the functional side, you want to know that the change still does the right thing once it is wired into the live system: that its API contract did not shift in a way a caller cannot handle, that service-to-service calls still succeed, that an end-to-end user flow still completes, that a schema or data migration did not strand existing records. [Unit tests and mocks do not catch these](https://www.signadot.com/blog/validating-ai-generated-code/), because a mock encodes the very assumption an agent is most likely to get wrong. Then there is the non-functional side, which agents tend to ignore entirely: latency under realistic traffic, behavior under load, memory and resource limits, security, and the handling of authorization and secrets. A change can be perfectly correct and still be too slow, too expensive, or insecure. Functionaldoes it still behave correctly across services? API contractsService-to-service callsEnd-to-end user flowsSchema and data migrationsEvent and queue handlingBackward compatibility Non-functionaldoes it still meet the bar under real conditions? LatencyBehavior under loadResource and memory limitsSecurityAuthorization and secretsCost The practical consequence is that good verification is not one test but a portfolio of them, and the portfolio only produces a trustworthy signal when it runs against the real thing. An agent that reasons over noisy or fake signals reaches confident, wrong conclusions, which is why [coding agents are only as good as the signals you feed them](https://www.signadot.com/blog/coding-agents-are-only-as-good-as-the-signals-you-feed-them/). Real dependencies are what make the signal worth acting on. #### Who writes the checks, and who keeps them current A long tail of checks raises an obvious question. Someone has to write all of that, and keep it current as the system changes. At human pace, with humans authoring every integration test, this was already the part of testing that teams quietly let rot. At agent pace it is hopeless. If a fleet of agents is producing changes all day, a separate group of people cannot hand-write and maintain the verification for each one. So the checks have to be written and maintained by agents too, as a first-class part of doing the work rather than an afterthought. When an agent changes a behavior, it should also update or add the checks that prove the new behavior, the same way a careful engineer would. This is the line between an agent that produces code and one that does engineering, a distinction we have [written about directly](https://www.signadot.com/blog/agents-write-code-they-dont-do-software-engineering/): real engineering includes leaving the system verifiable for the next change. Tooling can make this the default. The [signadot-validate skill](https://www.signadot.com/blog/introducing-signadot-validate-skill/), for example, gives an agent a repeatable way to set up and run validation for a microservices change, so producing the proof is part of the same motion as producing the code. The human role does not disappear; it moves up a level. People define what good looks like, the scenarios that matter, the regressions that are unacceptable, the acceptance criteria a change must meet, and the agents fill in and maintain the checks that enforce it. #### Which checks run, and when Running every possible check on every change does not scale and is not even desirable. A one-line copy fix and a change to the payments service do not warrant the same battery of tests. Deciding which subset of the long tail is relevant to a given change is itself a judgment, and it is exactly the kind of judgment an agent is well suited to make, because the agent knows what it changed and can reason about the blast radius. The way to make that judgment reliable is to give the agent a library of validation it can compose rather than improvise. That is the idea behind [Signadot Plans](https://www.signadot.com/blog/signadot-plans/): reusable, deterministic validation flows that an agent selects and runs based on the change at hand. What makes the selection tractable is that each plan carries a `selectionHint` in its frontmatter, a short natural-language description of what the plan validates. An agent reads those hints, matches them against the diff in front of it, and decides which plans are relevant to the change, so it pulls in the booking-flow plan when it touches checkout and leaves the rest alone, rather than running the entire library every time. We went deeper on why this matters for agents specifically when we [introduced Plans as validation superpowers for coding agents](https://www.signadot.com/blog/introducing-plans-microservices-validation-superpowers-for-coding-agents/). The agent decides which plan fits a change and when to run it; the plan guarantees the check itself is consistent and repeatable. Intelligence picks the tests; determinism runs them. #### The validation layer has to scale to agent volume Everything above assumes you can actually run all of this, constantly. That assumption is where most teams hit a wall, because the two traditional ways to get a real environment both break under agent load. Replicating the full stack locally was already impractical for a thirty-service application on a laptop, and asking an agent to do it for every change is a non-starter. Shared staging turns into a queue: one environment cannot absorb dozens of concurrent agent pull requests without constant contention, broken state, and the forensic question of whose change caused the failure. That is the same [staging bottleneck](https://www.signadot.com/blog/scaling-coding-agents-enterprise-kubernetes/) that already slows human teams, now multiplied by agent throughput. Duplicating a full environment per change solves isolation but explodes cost, since the bill scales with the number of services times the number of in-flight changes. The picture to plan for is hundreds or thousands of agents, each opening and validating changes in parallel, every day. As we put it bluntly, most teams’ [infrastructure is not ready for agentic development at scale](https://www.signadot.com/blog/your-infrastructure-isnt-ready-for-agentic-development-at-scale/). What works is request-level isolation: instead of cloning the stack, deploy only the service a change touches into a shared baseline cluster, and use request routing to send test traffic to the changed version while everything else borrows the baseline. If you already run a service mesh, you are [halfway to solving this](https://www.signadot.com/blog/the-agent-pr-flood-is-here-if-you-run-istio-youre-halfway-to-solving-it/) already. Agent100s to 1000s of agentsvalidating in parallelONE SHARED KUBERNETES CLUSTERSHARED BASELINEPER-CHANGE SANDBOXESand moreeach change runs only what it touched, on the shared baseline Request-level isolation lets one cluster host hundreds of agent sandboxes at once, instead of duplicating the stack per change. Spun up this way, a sandbox costs a fraction of a full environment and starts in seconds, so running one on every change becomes the default rather than a budget decision. That economics is the whole game: validation that is cheap enough to always run is the only kind that keeps up with agents. #### How Signadot closes the loop Signadot puts these ideas together as a layer agents can drive. The environment layer is [Sandboxes](https://www.signadot.com/kubernetes-sandbox/): lightweight, ephemeral [ephemeral environments](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) that deploy only the changed service onto your existing cluster and route test traffic to it, so hundreds can run in parallel at low cost. On top of that sits the validation layer. SmartTests compare the baseline and changed versions of an API and use Smart Diff to flag meaningful behavioral changes while ignoring benign noise, catching regressions without the hand-written contracts that [tools like Pact require](https://www.signadot.com/blog/ai-driven-contract-testing-signadot-smarttests-superior-approach-vs-pact/). Jobs run the integration, end-to-end, and load suites you already trust, inside the cluster, against the sandbox. Plans tie these into single, repeatable workflows an agent can select and run. The loop itself is closed by [Signadot’s MCP server](https://www.signadot.com/docs/integrations/mcp), which lets agents such as Claude Code and Cursor provision a sandbox, run these checks against real dependencies, read the results, and iterate, all without a human in the path until the change is genuinely ready for review. To see this in practice, [watch Claude Code validate a microservices change in a closed loop](https://www.signadot.com/blog/claude-code-signadot-validate-demo/). The result is a pre-merge gate where every agent-generated change is exercised against the real system, automatically, in parallel, before it reaches a reviewer or production. Give every coding agent a real environment to prove its work Signadot spins up an isolated, production-like sandbox for every change on your existing cluster, and its MCP server lets agents validate their own pull requests against real dependencies. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Validation is the new build step Agentic development only pays off when generation speed converts into shipped, working software, and that conversion happens at the validation layer. The teams pulling ahead are the ones that treat verification as core infrastructure: a closed loop the agent can run itself, against the real cloud-native dependencies a change will meet in production, with checks the agents write and maintain, chosen intelligently per change, on infrastructure that scales to thousands of validations a day. Get that right and a flood of AI-generated pull requests becomes a stream of changes you can trust. For the broader testing context, see the [complete guide to microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/), the [guide to ephemeral environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), and [why coding agents break CI/CD pipelines and how to fix it](https://www.signadot.com/blog/why-coding-agents-will-break-your-cicd-pipeline-and-how-to-fix-it/). #### Frequently asked questions Why isn't passing unit tests enough to validate AI-generated code? Coding agents are good at producing code that is locally plausible, which is exactly what a unit test checks. The failures that matter in a cloud-native system are emergent: a changed response shape a downstream service cannot parse, a new call pattern that trips a rate limit, an assumption about data that holds in isolation but not against the real database. A mock confirms the agent called a dependency the way the author expected, which is the assumption the agent is most likely to get wrong. The only reliable signal is running the changed service against the real dependencies it will meet in production. Should developers or QA own AI-generated test suites? In practice, ownership follows the closed loop. When agents can validate their own changes against real dependencies before opening a PR, the developer who runs the agent owns the first line of validation, and QA shifts toward defining what good looks like: the high-value scenarios, the regression checks, and the acceptance criteria the agent must satisfy. Increasingly the agent also writes and maintains the checks themselves, since a human cannot keep hand-written suites current at agent volume. What happens when coding agents go wrong in enterprise environments? The risk is not that an agent writes one bad line; it is that it writes many plausible-looking changes that only fail on integration. The mitigation is a validation gate that every change must pass: an isolated environment, real dependencies, and automated regression detection before merge. With that gate in place, a wrong change fails fast in its own sandbox instead of breaking a shared environment or reaching production. How does validation infrastructure keep up with hundreds of agents? Duplicating a full environment per agent does not scale, because the bill grows with the number of services times the number of in-flight changes. The approach that scales is request-level isolation: deploy only the service a change touches into a shared baseline cluster and route test traffic to it. One cluster can then host hundreds of concurrent sandboxes at a fraction of the cost, which is what lets thousands of agent-driven validations run in parallel every day. Can AI detect release regressions in Kubernetes? Yes. By comparing the behavior of a changed service against the current baseline and filtering out benign differences, AI-assisted checks like Smart Diff surface the breaking changes that matter, such as a removed field, a changed type, or a different status code, while ignoring noise. Run against real dependencies in a sandbox, this catches regressions before merge rather than after deploy. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## How to Test MCP Servers: A Complete Guide Source: https://www.signadot.com/testing-mcp-servers/ Summary: The four levels of MCP server testing: unit tests via in-memory transports, protocol checks with the MCP Inspector, integration tests against real dependencies in isolated sandboxes on the staging baseline, and agent evals, plus a production-readiness checklist. ### How to Test MCP Servers: A Complete Guide MCP servers sit between AI agents and your real systems, which makes them easy to demo and hard to trust. This guide covers the four levels of MCP server testing, from unit tests and the MCP Inspector to integration tests against real dependencies and full agent evals, and shows how to run them in isolation on a shared cluster. Type Guide Reading time 10 min Published August 31, 2026 **Testing an MCP server means verifying four different things: that each tool handler behaves correctly in isolation, that the server speaks the protocol correctly, that the tools work against the real systems they front, and that an AI agent can actually use them to complete tasks.** Most teams stop after the first one, ship a server that demos well, and find out in production that the other three were where the risk lived. This guide walks through all four levels, the tools for each, and how to run the hard part, integration testing against real dependencies, without giving every change its own copy of your infrastructure. #### What is an MCP server? The [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) is an open standard, introduced by Anthropic in late 2024 and since adopted across the major AI platforms, that gives AI applications a uniform way to reach external systems. An MCP server exposes three kinds of capabilities to a client: **tools** (functions the model can call), **resources** (data it can read), and **prompts** (templates it can use). Under the hood it is JSON-RPC 2.0 over one of two transports: stdio for local servers, or streamable HTTP for remote ones, with OAuth-based authorization on the HTTP path. That is the whole surface, and it is deceptively small. The protocol is easy to implement and the SDKs do most of the work. What makes MCP servers hard to ship with confidence is not the protocol. It is everything behind it. #### Why testing MCP servers is hard **The caller is a model, not a program.** A REST API is called by code that was written against its contract. An MCP server is called by a language model that reads your tool names, descriptions, and JSON schemas at runtime and decides what to call and with what arguments. That means correctness includes things no traditional test covers: whether the model picks the right tool for a task, whether an ambiguous description sends it down the wrong path, and whether a schema change silently changes agent behavior. Two servers can be byte-for-byte protocol-compliant and still produce wildly different agent outcomes. **Tools have real side effects.** Useful MCP tools create tickets, write rows, send messages, and mutate state in the systems they front. A test that exercises them for real needs somewhere safe for those side effects to land. Pointing tests at production is out. Pointing every developer and agent at one shared staging environment turns it into a queue and a source of cross-contaminated state. **State spans calls.** Agent sessions are conversational. A tool call late in a session frequently depends on what earlier calls created or fetched. Testing individual calls in isolation misses ordering bugs, stale-handle bugs, and cleanup bugs that only appear across a sequence. **Auth is part of the contract.** Remote MCP servers authenticate clients and often act on behalf of a user against downstream systems. Scopes, token expiry, and permission boundaries are exactly the kind of behavior that mocks flatten away and that attackers probe first. **The dependencies are the point.** An MCP server is rarely an island. It is a thin protocol layer over your actual stack: internal APIs, databases, message queues, third-party services. Which means the classic microservices problem applies in full: [tests that pass against mocks while the integrated system breaks](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/). The server is only as correct as its interaction with the real dependencies behind it. #### The four levels of MCP server testing Think of it as a pyramid. Each level catches a class of bugs the previous one cannot. ##### Level 1: Unit test the tool handlers Tool handlers are functions, and the official MCP SDKs make them easy to test as functions. The TypeScript and Python SDKs both let you connect a client and a server in memory, no transport or process boundary involved, so a test can call a tool exactly the way a client would and assert on the structured result: ``` import { Client } from "@modelcontextprotocol/sdk/client/index.js"; import { InMemoryTransport } from "@modelcontextprotocol/sdk/inMemory.js"; const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair(); await server.connect(serverTransport); await client.connect(clientTransport); const result = await client.callTool({ name: "create_ticket", arguments: { title: "Test", priority: "high" }, }); ``` Cover the basics here: valid inputs, schema-violating inputs, error paths returning proper MCP error responses rather than crashes, and edge cases in your business logic. This level is fast and belongs in every CI run. It tells you nothing about the model’s behavior or the real dependencies, and that is fine. That is not its job. ##### Level 2: Exercise the protocol surface with the MCP Inspector The [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) is the official interactive testing tool, and the fastest feedback loop you get during development: ``` npx @modelcontextprotocol/inspector node build/index.js ``` It connects to your server over stdio or streamable HTTP, lists every tool, resource, and prompt, lets you invoke tools with arbitrary arguments, and shows you the raw JSON-RPC messages both ways. Use it to verify the things unit tests take for granted: that tools actually appear with the schemas you intended, that descriptions read the way a model will read them, that errors come back as structured MCP errors, and that notifications fire when they should. The Inspector is interactive by design. For repeatable protocol checks in CI, script a minimal MCP client with the SDK, connect over the same transport your users will use, and assert on `tools/list` and a handful of representative `tools/call` exchanges. ##### Level 3: Integration test against real dependencies This is the level that separates a demo from a production service, and it is where most MCP testing advice goes quiet, because it is the expensive part. The mock-based shortcut fails here for the same reason it fails for any microservice: the mock encodes what the author imagined the dependency does, and the failures that matter live in the gap between that and reality. Schema drift in an upstream API, a side effect the mock has no concept of, auth scopes that behave differently against the real identity provider. The question is where to run it. Spinning up the full dependency stack per change is slow and expensive, and sharing one staging environment means every developer’s and agent’s side effects land in the same state. The pattern that scales is **request-level isolation on the staging baseline you already run**: deploy only the changed MCP server (and any backing service the change touches) as a sandboxed workload, and route requests carrying a sandbox key to it while everything else flows through the stable shared services. The server under test talks to real upstream and downstream dependencies, side effects are scoped to the sandbox, and hundreds of these can coexist on one cluster. With [Signadot](https://www.signadot.com/solutions/microservices-testing/), that looks like: your MCP server runs in the cluster as a normal workload, a pull request produces an image, and a short sandbox spec forks just that deployment on the baseline. The sandbox gets a routed endpoint, so you point your integration suite (the scripted MCP client from level 2, plus whatever end-to-end checks you have) at the sandboxed server and it exercises real APIs, real databases with [isolated schemas where tests write](https://www.signadot.com/docs/guides/set-up-data-isolation), and real [message queues with per-sandbox isolation](https://www.signadot.com/docs/guides/set-up-message-queue-isolation). [Jobs](https://www.signadot.com/docs/reference/jobs) run those suites inside the cluster against the sandbox, in parallel across many open changes. This is the same model behind [ephemeral environments on Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), applied to the newest kind of service in your cluster. Test your MCP server against real dependencies Give every change to your MCP server its own isolated sandbox on the cluster you already run, with real APIs, databases, and queues behind it. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) ##### Level 4: Agent evals The last level tests the thing MCP exists for: can an agent use your server to get work done? Here you drive a real model against the server with a set of realistic tasks and assert on outcomes. Does the agent select the right tool for each prompt? Does it chain calls in a sensible order? Does it recover when a tool returns an error? Because model output varies run to run, these tests are statistical rather than binary: run each scenario several times and track success rates, and use an LLM-as-judge or explicit tool-call assertions to score runs. Keep this suite small and high-signal. It is the slowest and most expensive level, and its job is to catch regressions in tool ergonomics (names, descriptions, schemas) that the lower levels cannot see. When a level 4 failure appears, the fix is usually a description or schema change, which then flows back down the pyramid for cheaper verification. #### Where coding agents change the picture MCP servers are increasingly written and modified by the same coding agents that consume them, and that changes who runs the tests. An agent working in Claude Code, Cursor, or Codex can own the whole loop: make the change, create a sandbox for it, deploy the modified server there, run the level 2 and level 3 suites against the sandbox’s routed endpoint, read the failures, and fix them, all before a pull request exists. Signadot exposes this workflow to agents directly through its [MCP server and CLI](https://www.signadot.com/docs/integrations/mcp), so the agent creates and tears down its own isolated environments on the shared cluster. The isolation is what makes this safe at agent speed. Ten agents iterating on ten changes get ten sandboxes against one baseline, and none of them can corrupt each other’s state or the shared environment. Every change arrives at review with evidence from real dependencies instead of a green checkmark from mocks. We cover the broader pattern in [validating AI-generated code against real Kubernetes dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/) and in [why CI pipelines are not ready for agent-scale change volume](https://www.signadot.com/blog/your-ci-cd-pipeline-is-not-ready-to-ship-ai-agents/). #### A practical checklist Before you call an MCP server production-ready: - Every tool handler has unit tests through an in-memory client, covering error paths and schema violations, running in CI. - Tool list, schemas, and representative calls are verified over the real transport (stdio or streamable HTTP), not just in memory. - Auth is tested as a first-class behavior: expired tokens, missing scopes, and per-user permission boundaries all have explicit tests. - Integration tests run against real upstream and downstream dependencies in an isolated sandbox per change, not against mocks and not against a contended shared environment. - Side-effecting tools are exercised for real, with writes landing in sandbox-scoped datastores or queues. - Multi-step sessions are tested as sequences, not just as independent calls. - A small agent-eval suite guards tool selection and chaining against regressions in names, descriptions, and schemas. - The whole loop is runnable by a coding agent, so changes to the server can be validated at the speed they are now written. #### Conclusion MCP servers compress a lot of trust into a small protocol: an agent will do whatever your tools let it do, against whatever systems they front. Unit tests and the Inspector get you a correct protocol surface. Real confidence comes from the levels above that, integration tests against the real dependencies and evals of real agent behavior, and those become routine once each change has an isolated, production-like place to run. If your MCP server fronts services on Kubernetes, that place already exists: it is your staging baseline, shared safely through [sandboxes](https://www.signadot.com/kubernetes-sandbox/). Ship MCP servers with proof, not promises Spin up an isolated sandbox for every change, run your MCP test suite against real dependencies, and let your coding agents do the same. Start free on the cluster you already run. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions How do you test an MCP server? Test it at four levels. Unit test each tool handler with the SDK's in-memory transport. Exercise the protocol surface interactively with the MCP Inspector to verify tool schemas, resources, and error contracts. Run integration tests against the real services and datastores the server fronts, ideally in an isolated sandbox on a shared cluster. Finally, run agent evals that check an AI agent selects and chains your tools correctly on realistic tasks. What is the MCP Inspector? The MCP Inspector is the official interactive testing tool for MCP servers, run with npx @modelcontextprotocol/inspector. It connects to a server over stdio or streamable HTTP, lists its tools, resources, and prompts, lets you invoke tools with arbitrary arguments, and shows the raw JSON-RPC exchange, which makes it the quickest way to verify schemas and error handling during development. Why is testing MCP servers harder than testing a normal API? Three reasons. The caller is a non-deterministic AI agent, so correct behavior includes how well your tool names, descriptions, and schemas steer the model, not just what the code returns. Tools carry real side effects, like writing to databases or calling internal APIs, so a bad test run can corrupt shared state. And an MCP server usually fronts a stack of real dependencies, so mock-based tests pass while the integrated behavior breaks. Can you test an MCP server against real dependencies without breaking shared environments? Yes, with request-level isolation. Deploy the changed MCP server as a sandboxed workload on your existing staging baseline: requests carrying the sandbox's routing key reach the new version, while every other request flows to the stable services around it. The server under test talks to real upstream and downstream dependencies, and many sandboxes run in parallel on the same cluster without interfering. How do AI coding agents test the MCP servers they build? By closing the loop themselves. An agent working in Claude Code, Cursor, or a similar tool creates a sandbox for its change, deploys the modified MCP server there, runs the test suite against real dependencies through the sandbox's routed endpoint, reads the results, and fixes what broke before opening a pull request. Each agent task gets its own isolated sandbox on the shared cluster, so parallel agents never collide. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Microservices Testing Environments on Kubernetes Source: https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/ Summary: Best practices for microservices testing environments, ephemeral environments, and sandboxes on Kubernetes. ### A Comprehensive Guide to Microservices Testing Environments on Kubernetes Complete guide to microservices testing environments on Kubernetes. Learn best practices for ephemeral environments and sandboxes. Read the guide. Type Guide Reading time 16 min Published February 28, 2026 Updated July 13, 2026 In the world of cloud-native engineering, the staging environment is often where developer velocity goes to die. For engineering leaders and platform teams, the phrase “staging is down again” has become a painful, all-too-common refrain. It signals the start of another productivity-killing investigation that grinds pull request reviews, CI/CD pipelines, and feature delivery to a halt. This isn’t a new problem, but its scale and cost have been magnified by the very architecture designed to speed us up: microservices. The promise of microservices was team autonomy and independent, rapid deployments. The staging environment itself, what it is for and the four architectures that replace the single shared copy, is the subject of our [complete guide to staging environments](https://www.signadot.com/staging-environments/). The reality for many scaling organizations is a shared staging environment that has become a central bottleneck, creating a state of constant resource contention and instability.1 When multiple teams deploy concurrent, unstable features into the same shared space, a single test failure triggers a time-consuming forensic exercise. Was it my change? Was it another team’s deployment? Or is the environment itself in a broken state? A growing share of code is now written by AI coding agents like Claude Code, Codex, and Cursor, and they produce changes far faster than teams can review or test them. That shifts where the work piles up. Writing the change is no longer the hard part; validating it is. For cloud-native applications, validation has always run into the environment problem, and now the queue feeding that environment is much longer. The staging bottleneck stops being an occasional annoyance and becomes the rate limiter on the whole organization. This uncertainty erodes developer confidence and slows the entire delivery pipeline. In fact, the problem of slow, inefficient testing is not just a frustration; it’s a multi-million dollar drain on resources. One VP of Platform Engineering recently calculated their “broken testing process” was costing them [**half a million dollars monthly**](https://www.signadot.com/blog/the-million-dollar-problem-of-slow-microservices-testing/) in lost productivity. This guide provides a strategic framework for engineering leaders and platform teams to navigate this challenge. We will explore the evolution of testing environments, from the inherent flaws of the traditional staging model to the rise of modern ephemeral environments. We will conduct a deep, balanced analysis of the two dominant architectural models for these environments, present a clear-eyed view of the ROI, and offer a path forward that aligns with the principles of high-velocity, cost-efficient, and scalable software development. For the full lifecycle picture, see our complete guide to [microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). #### **The Broken Promise of the Monolithic Staging Environment** The traditional, long-lived staging environment was born in a simpler, monolithic era. It was a single, stable pre-production replica where final integration testing could occur. However, when applied to a complex microservices ecosystem running on Kubernetes, this model fundamentally breaks down. As [Kelsey Hightower](https://www.getambassador.io/podcasts/kelsey-hightower-on-developer-experience-paas-and-testing-in-production), a prominent voice in the cloud-native community, has often noted, the goal of modern platforms should be to enhance the developer experience, yet traditional staging frequently does the opposite.3 It becomes a source of friction, not empowerment. The core issues are systemic: - [**The Bottleneck Effect**](https://www.launchableinc.com/blog/devops-pros-report-losing-time-to-testing-bottlenecks/)**:** When dozens of developers must queue for their turn to deploy and test on a single shared environment, parallel development ceases to exist. This queuing behavior directly contradicts the agile principles that microservices are meant to enable. *Image: The staging bottleneck problem: exclusive access queues cause productivity loss while shared access causes false confidence and bugs* - **Chronic Instability:** A shared environment is only as stable as the least stable service deployed to it. A single buggy commit can destabilize the entire system, blocking every other team from making progress. This leads to what one engineering leader described as a “crowded nightclub: everyone wants in, capacity is limited, and fights break out regularly”. - **Configuration Drift:** Long-lived environments are notoriously difficult to keep in perfect sync with production. Over time, manual changes, forgotten test data, and inconsistent updates cause the environment to “drift,” diminishing the value and reliability of the tests performed within it. - **Exorbitant Hidden Costs:** Beyond the visible infrastructure spend, the true cost of staging is buried in lost engineering hours. Industry reports reveal that non-production environments can account for [**27% of a company’s total cloud costs**](https://info.flexera.com/CM-REPORT-State-of-the-Cloud-2025-Thanks), with staging alone consuming up to 21% of ongoing maintenance efforts. When you factor in wasted developer time, which surveys show can be over 8 hours per week per developer due to technical inefficiencies, the financial impact becomes staggering. #### The Rise of Ephemeral Environments: A Step in the Right Direction In response to these limitations, the industry has shifted towards a more dynamic paradigm: [**ephemeral environments**](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/). An ephemeral environment is an on-demand, isolated, and temporary deployment created automatically for a specific, short-term purpose, such as testing a pull request. Unlike their static predecessors, these environments are treated as disposable components of the development workflow. They are provisioned when a PR is opened and automatically destroyed upon merge or closure, ensuring a clean slate for every set of changes and conserving infrastructure resources. This approach aligns with the “shift-left” philosophy of catching issues earlier in the development lifecycle, when they are exponentially cheaper to fix. The core attributes of a well-architected ephemeral environment system are: - **On-Demand & Temporary:** Environments are created and destroyed automatically, aligning their lifecycle with the feature being developed. - **Production-Like:** To be effective, a preview environment [must mirror the production environment as closely as possible](https://vfunction.com/blog/microservices-testing/), using similar services, dependencies, and data schemas. - **Isolated:** Each environment is [self-contained](https://www.signadot.com/blog/scaling-quality-the-industrys-shift-towards-ephemeral-environments-in-2024/), ensuring that tests for one PR cannot interfere with another, enabling true parallel development. While the concept is powerful, the implementation strategy is where the paths diverge, with profound implications for cost, speed, and scalability. #### The Great Divide: Two Models of Ephemeral Environments ##### Model 1: Full Environment Duplication (Infrastructure-Level Isolation) The most conceptually straightforward approach is to duplicate the entire application stack for every pull request. This typically involves creating a new Kubernetes namespace and deploying all microservices and their dependencies into it. Tools like [Okteto](https://www.signadot.com/comparison/okteto/) and [Release](https://www.signadot.com/comparison/release/) are often associated with this philosophy of providing complete, replicated environments. **Strengths:** - **Maximum Isolation:** This model provides the highest possible degree of isolation. Each environment is a complete, self-contained replica, eliminating any chance of cross-contamination between tests. - **Simple Mental Model:** The concept is easy for developers to grasp, every PR gets its own private copy of the application. Weaknesses and Business Impact: The simplicity of this model hides crippling inefficiencies that become apparent at scale. - **Prohibitive Infrastructure Costs:** The financial burden of this approach is staggering. Let’s run some conservative “napkin math” for a 100-developer team with a 50-microservice architecture: - Assuming each service requires 2 vCPUs, and environments are active for 8 hours per weekday, the [annual compute cost alone can exceed **$832,000**](https://www.signadot.com/blog/scale-microservices-testing-without-duplicating-environments/). - This calculation doesn’t even include the cost of replicated databases, message queues, and other stateful services. For a company like Brex, with over 1,000 microservices, their homegrown preview environments based on this model were nearly as expensive as their production environment, leading them to seek a more scalable solution. - **Slow Provisioning and Long Feedback Loops:** Spinning up a full stack of 50+ services is not instantaneous. Wait times of 20-30 minutes are common, even after significant optimization. This reintroduces a slow feedback loop, delaying PR reviews and hindering the rapid, iterative cycle that is crucial for [developer experience](https://www.signadot.com/blog/7-reasons-developer-experience-is-a-strategic-priority/). - **Operational and Maintenance Nightmare:** Your platform team becomes responsible for maintaining hundreds of replicas of your entire stack. Every configuration change, database migration, and security patch must be propagated across all environments. This creates an [enormous maintenance burden that grows linearly with the number of developers](https://www.signadot.com/blog/why-scaling-makes-microservices-testing-exponentially-harder/), making configuration drift almost inevitable. While full duplication appears to solve the problem of contention, it often backfires at scale, creating a distributed version of the same bottlenecks and adding an unsustainable financial and operational tax. As [one developer on Reddit noted](https://www.reddit.com/r/devops/comments/1ffzvms/recs_for_ephemeral_environments_for_testing/) after attempting this approach, “It eventually worked, but took a very very long time… and also had a high operational overhead. It also got very expensive, very quickly”. ##### Model 2: Request-Level Isolation (Application-Layer Isolation) A fundamentally different and more cloud-native approach is to achieve isolation at the application layer through intelligent request routing. This model, pioneered by tech giants like Uber and Lyft and commercialized by platforms like Signadot, is built on a [shared infrastructure paradigm](https://www.signadot.com/docs/concepts/introduction). The architecture works as follows: 1. [**Shared Baseline Environment:**](https://www.signadot.com/docs/concepts/baseline-environment) A single, long-lived “baseline” environment is maintained. This is typically an existing staging or QA Kubernetes cluster that is kept in sync with the main branch via CI/CD. It serves as the stable, high-fidelity foundation against which all changes are tested. [**‍**](https://www.signadot.com/docs/concepts/sandbox) 2. [**Sandboxes and Service Forking**](https://www.signadot.com/docs/concepts/sandbox)**:** When a developer needs a test environment, they don’t clone the entire baseline. Instead, they create a lightweight, logical entity called a **sandbox**. The Sandbox definition specifies which one or two services are being modified. For these services, a “forked workload” is deployed, a new version running the code from the PR. All other unmodified services and dependencies in the baseline are [**shared**](https://www.signadot.com/docs/concepts/introduction), not copied.[**‍**](https://www.signadot.com/docs/guides/request-routing) 3. [**Dynamic Request Routing:**](https://www.signadot.com/docs/guides/request-routing) This is the technological core that enables isolation on shared infrastructure. Test requests are tagged with a unique context, usually in an HTTP header (e.g., sd-routing-key=). A service mesh (like Istio or Linkerd) or a lightweight sidecar proxy intercepts traffic and inspects this header. If a routing key is present, the request is dynamically routed to the forked service in the corresponding Sandbox. If no key is present, it goes to the stable baseline service. This routing context is propagated throughout the entire downstream call chain, creating a virtual “slice” of the application for that specific test. Strengths and Business Impact: This innovative architecture yields a set of powerful benefits that directly address the primary pain points of other models. - **Drastic Cost Reduction:** Since only the changed services are deployed, the resource overhead per environment is minimal. This can lead to [infrastructure cost reductions of **90% or more**](https://www.signadot.com/articles/cut-testing-costs-90-with-kubernetes-ephemeral-environments/) compared to full duplication. For the same 100-developer team, the [annual cost drops](https://www.signadot.com/blog/scale-microservices-testing-without-duplicating-environments/) from over $800,000 to around $68,000. [Brex](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/), a Signadot customer, reports saving **about $2 million annually** on infrastructure after making this switch. - **Blazing-Fast Environment Creation:** Sandboxes spin up in seconds because there’s no need to wait for dozens of services to be provisioned. This provides a near-instantaneous feedback loop, allowing developers to preview changes almost as soon as they push code. DoorDash reported that this approach [**accelerated their testing by 10x**](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/), cutting deployment time significantly. *Image: Sandboxes forking two services from the shared baseline environment, with requests routed to the sandboxed versions* - **High-Fidelity Testing:** Developers test their changes against the _actual_ shared dependencies, the same databases, message queues, and third-party APIs that the baseline environment uses. This dramatically increases the likelihood of catching subtle, real-world integration issues that are often missed when testing against fresh, empty copies of these dependencies. - **Exceptional Scalability:** The model scales effortlessly, supporting hundreds of concurrent Sandboxes on a single cluster without performance degradation or resource exhaustion. This is a critical capability for large, high-velocity engineering organizations. These same properties are what make the model a good fit for AI coding agents. An agent does its best work when it can close the loop on its own: make a change, run it against real dependencies, read the result, fix, and repeat, without waiting on a human or queuing for a shared environment. That requires environments that are cheap and quick to create but still high fidelity, which is exactly the combination request-level isolation provides. A sandbox gives an agent an isolated place to exercise its change, and a validation layer on top, covering [functional and non-functional checks of AI-generated code](https://www.signadot.com/validate-ai-generated-code-kubernetes/), tells it whether the change is actually safe to ship. #### The ROI of Intelligence: A Business Case for Request-Level Isolation For engineering leaders, the decision to invest in a testing platform must be justified by a clear return on investment. The business case for request-level isolation is compelling, with measurable improvements across cost, velocity, and quality. ##### Quantifying the Gains with DORA Metrics The DORA (DevOps Research and Assessment) metrics are the industry standard for measuring software delivery performance. An [effective testing environment strategy](https://www.signadot.com/blog/how-to-do-dora-metrics-right/) should directly and positively impact these key indicators. - ‍**Lead Time for Changes:** This metric, which measures the time from code commit to production deployment, is dramatically reduced. By providing feedback in seconds instead of hours, request-level isolation slashes the “code-test-debug” cycle time. Teams like [DoorDash](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/) have seen lead times for testing drop from **30 minutes to under 60 seconds**. - **Deployment Frequency:** By removing the staging bottleneck, teams can merge and deploy smaller batches of code more frequently, a [key characteristic of elite-performing organizations](https://dora.dev/guides/dora-metrics-four-keys/). - **Change Failure Rate:** Shifting high-fidelity integration testing left into the PR phase means more bugs are caught before code is merged. This leads to a cleaner main branch and fewer hotfixes or rollbacks after deployment. Earnest, another Signadot customer, [**boosted their release reliability**](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) by catching bugs earlier in the process. - **Mean Time to Recovery (MTTR):** While primarily a production metric, faster, more reliable [pre-production testing](https://www.sumologic.com/glossary/dora-metrics) reduces the number of incidents that require recovery in the first place, contributing to overall system stability.24 ##### The Unquantifiable ROI: Developer Experience (DevEx) Beyond hard metrics, the impact as stated in [this article](https://www.signadot.com/blog/are-you-delivering-on-developer-experience/) is profound. As articulated in [a recent ACM Queue article](https://queue.acm.org/detail.cfm?id=3639443), the three pillars of a great DevEx are short feedback loops, low cognitive load, and enabling a “flow state”. Traditional testing models actively work against all three. In contrast, a seamless, fast, and reliable testing environment is a strategic asset for attracting and retaining top engineering talent. As one Software Engineering Manager at [Brex, Connor Braa](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/), put it, “On the margin, with the Signadot approach, 99.8% of the isolated environment’s infrastructure costs look wasteful. That percentage looks like an exaggeration, but it’s really not”. This level of efficiency directly translates to a better daily experience for developers, allowing them to focus on creative problem-solving instead of fighting with broken infrastructure. #### Handling the Hard Parts: Stateful Services and Asynchronous Flows A common and valid question about the shared infrastructure model is how it handles stateful services and asynchronous workflows. A mature request-level isolation platform must provide robust solutions for these complex scenarios through a principle of tunable isolation: each stateful component gets only as much isolation as the test actually needs. - ‍**Databases and Schema Changes:** Testing destructive database schema changes requires careful isolation. The solution is to use [**resources**](https://www.signadot.com/docs/concepts/resources), an extensible framework that allows a Sandbox to spin up its own ephemeral, isolated database instance or schema for the duration of a test. This provides the necessary data isolation for stateful changes without the overhead of cloning the main database for every PR. You can see a detailed walkthrough in our tutorial on [how to test database schema changes](https://www.signadot.com/docs/tutorials). - **Message Queues (Kafka, RabbitMQ, etc.):** Testing event-driven architectures requires a more sophisticated pattern to isolate messages. The solution involves propagating the routing context within the message headers or metadata. On the other side, consumer services within a Sandbox are configured for “selective consumption”, they are programmed to only process messages that contain their specific routing key. This ensures that test messages are isolated from the main message stream and are only consumed by the correct test instance. This pattern works across all major message brokers, and you can explore a hands-on example in our tutorial on [testing asynchronous Kafka flows](https://www.signadot.com/blog/kafka-step-by-step-tutorial/). #### Conclusion: Choosing a Strategy, Not Just a Tool The evolution of testing environments for microservices reflects the maturation of the cloud-native ecosystem. We have moved from the brittle, monolithic staging environments of the past to a new era of dynamic, on-demand testing. However, as we’ve seen, not all ephemeral environments are created equal. The choice between full environment duplication and request-level isolation is a strategic one that will define your organization’s ability to scale its development practices efficiently and economically. While full duplication offers a simple mental model, it is a solution that collapses under its own weight and cost at scale. It is a tactical fix that fails to address the fundamental architectural challenges of testing distributed systems. Request-level isolation represents a paradigm shift. By moving isolation from the infrastructure layer to the application layer, it decouples the cost and complexity of testing from the overall size of the application. The cost of a test environment is no longer proportional to the total number of microservices (N), but to the number of _changed_ microservices in a given pull request (M), where M is almost always a small fraction of N. This economic and logistical reality makes the request-level isolation model, as implemented by Signadot, uniquely capable of supporting true, independent, high-velocity microservice development for large and growing engineering organizations. It is the enabling technology for teams seeking to test every change thoroughly, accelerate their release cycles, and deliver higher-quality software, all without breaking their infrastructure budget. That capability matters more now that much of the code arriving at the environment is written by AI coding agents rather than typed by hand. The volume of change has gone up sharply, but the question for each change is the same: is it safe to merge? Signadot answers it by pairing the two halves of the problem. Sandboxes are the environment layer, the isolated and high-fidelity place a change runs against real dependencies, and SmartTests, Jobs, and Plans are the validation layer on top that checks both functional and non-functional behavior. Together they give developers and agents alike a way to produce verified changes and pull requests, which is what continuous delivery has always promised and what the next era of software development will demand. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Why Shared Staging Is Expensive Source: https://www.signadot.com/deep-dives/why-shared-staging-is-expensive/ Summary: The hidden tax on every engineering team running microservices, and why adding more staging environments makes it worse, not better. The Hidden Cost of Shared Environments  ·  01 of 05 ### Why Shared Staging Is the Most Expensive Tool You're Not Accounting For The hidden tax on every engineering team running microservices, and why adding more staging environments makes it worse, not better. Reading time 10 min Author Rory Nolan Category Cost Optimization It's 2:17pm on a Tuesday. A senior developer has been blocked for forty minutes. Not on a hard problem on a queue. Three other teams have changes deployed to staging, and one of them broke something. Nobody's sure whose change it was. The PR that was supposed to ship today will slip to tomorrow, maybe Thursday if the investigation runs long. This scene plays out in engineering organizations everywhere, dozens of times a week. It's so normal that most teams have stopped registering it as a cost. It's just how things work. But it isn't free. And the gap between what teams think shared staging costs and what it actually costs is one of the largest unexamined line items in modern software engineering. #### The Three Real Costs of Shared Staging Shared staging has three distinct cost buckets. They're rarely measured together, which is part of why the total stays invisible. ###### Cost 1 · Developer Time Lost to Contention When two or more teams need staging at the same time, someone waits. At a 100-person engineering organization shipping at pace, this isn't a rare edge case; it's a daily condition. Consider a conservative estimate: if the average developer loses one hour per day to staging-related delays, waiting for a slot, waiting for an environment to stabilize, waiting to understand whether a failure is theirs or another team's, the math is stark. 1 hr Lost per developer per day (conservative) 230 Working days per year ~12.5% Of total engineering capacity, gone At a fully loaded cost of $125,000 per year, one hour daily represents roughly $15,600 per developer annually. For a hundred-developer team, that's $1.56M in lost velocity, before counting a single incident, a single deployment failure, or a single bug that reached production because the debugging environment was too contested to investigate properly. That number doesn't appear on any invoice. It doesn't show up in your infrastructure costs or your headcount budget. But it's real, and it compounds. "We had developers deploying unapproved code into staging just to test. That meant when bugs showed up, we couldn't tell what broke what." Engineering Team · Wealthsimple This describes something that happens in most scaling engineering organizations: developers start working around the bottleneck. They push code to staging before it's review-ready because waiting is expensive. The environment becomes noisier. Signal degrades. Eventually nobody trusts staging, and the entire point of having it begins to erode. ###### Cost 2 · The Blast Radius Problem In a shared environment, one team's bad deploy is every team's problem. When a service breaks in staging, it doesn't just block that team; it blocks every team with a downstream dependency. In a microservices architecture with dozens of interconnected services, that blast radius can be substantial. The less visible cost is investigative overhead. When staging breaks and multiple teams have active changes, the first thing that happens is an unplanned multi-team debugging session. Time is spent in Slack threads trying to attribute the failure rather than building features. Large engineering teams running shared staging often hit this directly: when regressions appear, it is impossible to quickly determine which team's change was responsible, causing delays across teams that had nothing to do with the original issue. The mechanics behind that failure, and the four alternatives to a single shared copy, are covered in [Staging Environments: The Complete Guide](https://www.signadot.com/staging-environments/). The Pattern That Develops Teams start serializing their deployments to avoid collisions, effectively turning a shared parallel environment into a queue. A 100-person team that could theoretically be testing in parallel instead tests sequentially. Throughput gets capped by the throughput of a single environment. Teams then game the system further, pushing to staging at off-peak hours to avoid conflicts. Testing happens at the margins of the workday. Bugs get found on Friday afternoon. The problem perpetuates itself. ###### Cost 3 · The Bugs That Make It Through Anyway Perhaps the most significant cost of staging contention is the hardest to attribute: the bugs that slip through because the environment wasn't trustworthy enough to catch them. When staging is unreliable, developers learn to discount what it tells them. A test failure might be their bug, or it might be noise from another team's deploy, or it might be configuration drift in the shared environment. Over time, engineers develop a kind of learned skepticism about staging signals. They merge code that staging flagged as failing because "staging is always broken." And occasionally they're right. But every so often the flag was real. The research on production incident costs is consistent: a bug caught in development costs orders of magnitude less to fix than one caught in production. Industry estimates put the cost of a production incident at $10,000 or more when you account for engineer time, customer impact, and remediation. A team that lets three additional bugs per month reach production because staging was too noisy to catch them is adding $30,000+ to its annual cost base, without ever seeing it as a line item. * * * #### Why Adding More Staging Environments Doesn't Fix This The intuitive response to staging contention is to give each team their own staging environment. More environments, fewer collisions. This works briefly and at a small scale. It stops working as your microservices architecture grows: duplicating a full stack of services doesn't just duplicate compute costs. It duplicates the cost of maintenance, data seeding, configuration management, third-party integrations, and the operational burden on your platform team. Brex learned this the hard way. They built a system using duplicated Kubernetes namespaces to give developers isolated environments. As their microservices footprint grew, those environments began pushing the scaling limits of a single Kubernetes control plane. Availability issues pushed teams back toward staging, and the duplicated environments fell into disrepair. As Connor Braa, Software Engineering Manager at Brex, put it, the cost of getting something wrong in a preview environment was never high enough to prevent people from leaving things broken, so they constantly were. "On the margin, with the Signadot approach, 99.8% of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not." Connor Braa · Software Engineering Manager, Brex The fundamental issue is architectural. Full environment duplication is the wrong model for microservices. When a developer changes one service out of 50, the cost of running the other 49 is pure overhead. The question isn't "How do we give each developer their own environment?" it's "How do we give each developer isolation for the services they're actually changing?" #### What Healthy Pre-Merge Validation Actually Looks Like The teams that have solved this problem well share a common pattern. They've stopped thinking of testing environments as finite, shared resources, and started treating isolation as something that gets created on demand, per change, and torn down when it's no longer needed. This is what the industry calls "shift-left" testing: moving integration validation as early as possible in the development cycle, ideally to the moment a developer opens a pull request. The core insight is that the cost of finding a bug rises with time. A bug found before merge is cheap. Found in staging, it costs more. Found in production, it's expensive. The goal is to catch as many bugs as possible at the earliest, cheapest stage. ###### The model that works at scale Rather than giving each developer a full clone of the environment, the approach that scales works like this: maintain a single stable baseline representing your production cluster. When a developer changes one or two services, spin up an isolated context, a Sandbox for just those changed services. Route test traffic through that Sandbox. Everything else flows from the shared baseline, unchanged. 1. 01A developer opens a PR. An isolated Sandbox spins up automatically inside the existing Kubernetes cluster, deploying only the services changed in that PR. 2. 02The Sandbox routes relevant traffic through the changed services and falls through to the baseline for everything else. **No full stack duplication. No other teams affected.** 3. 03Automated tests (Playwright, Cypress, Postman, or Signadot SmartTests) run against the Sandbox. Developers and reviewers access a live environment with real backend behavior. 4. 04When the PR merges or closes, the Sandbox tears down automatically. Nothing to clean up. Nothing left running and accruing cost. This model scales in a way that full duplication never can. A 100-developer team can run 100 Sandboxes simultaneously. Each contains only the 1-3 services being changed. The shared baseline handles everything else, which is precisely what Brex found: infrastructure costs reduced by 99% compared to their previous namespace-duplication approach. · · · #### What Teams Report After Making the Shift This isn't theoretical. Several engineering organizations have moved from shared staging to sandbox-based isolation and documented what happened. Customer Outcomes · Signadot 80% **Brex** replaced namespace-based preview environments with Signadot Sandboxes across hundreds of engineers. Previewing changes took 80% less time. Developer satisfaction scores (CSAT) were 28 points higher for Signadot than the previous tooling. Infrastructure costs were reduced by 99% on a per-preview basis. ~50% **Wealthsimple** reduced staging bottlenecks by nearly 50% after shifting to per-PR sandboxes. Staging conflicts, teams blocking each other, unclear failure attribution, and developers pushing unapproved code just to test were eliminated. Sandbox adoption became core to their workflow, with plans to extend to async systems including Kafka and Temporal. The pattern across these organizations is consistent. The pain isn't unique to their scale or stack. It's the natural consequence of treating a shared environment as an infinite, low-friction resource, when it isn't either of those things. #### Calculate Your Own Staging Waste Staging Cost Audit Adjust inputs → see your annual waste Your Team Number of engineers using staging All developers who depend on the shared staging environment devs Average fully-loaded annual salary Include salary, benefits, employer taxes, equipment $ Staging Contention & Wait Time Avg. hours lost per developer per day to staging delays Waiting for a slot, environment stabilising, attribution debugging hrs/day Platform / DevOps engineers maintaining staging Headcount whose time is materially consumed by staging upkeep people % of platform time spent on staging maintenance Tickets, environment fixes, oncall for staging incidents % Infrastructure Spend Annual cloud cost for non-production environments Compute, networking, storage for staging / preview clusters $ Bugs That Slip Through Production incidents per year caused by staging gaps Bugs that staging was too noisy or unreliable to catch pre-merge /year Average cost per production incident Engineering hours, customer impact, remediation, post-mortems $ Developer Contention $938K Platform Overhead $104K Infrastructure Spend $120K **Estimated Annual Staging Waste** Developer time + platform overhead + infrastructure + incident cost $1.28M Estimates only. Developer contention calculated at hourly rate × wait hours × 230 working days. Platform overhead at ops salary × 1.15 premium × time allocation. All figures in USD. The numbers are illustrative until they're yours. Most teams that run this exercise are surprised not because the numbers are challenging to find, but because nobody had put them side by side before. The cost of the problem is usually much larger than the cost of solving it. The gap just hasn't been visible. Shared staging isn't bad because of a tooling mistake or a specific architectural choice. It's a scaling problem. It works reasonably well for small teams with a handful of services. It stops working when the number of concurrent developers, active PRs, and interconnected services grows, and it stays broken until the underlying model changes, not just the number of environments provisioned. The next question, once the cost is visible, is what a replacement model looks like technically and what it takes to adopt it without disrupting the teams already in flight. That's the subject of the next piece in this series. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## The Future of API Validation: AI-Powered Contract Testing Source: https://www.signadot.com/the-future-of-api-validation-a-deep-dive-into-ai-powered-contract-testing/ Summary: How AI-powered contract testing transforms API validation for microservices. ### The Future of API Validation: A Deep Dive into AI-Powered Contract Testing Explore AI-powered contract testing for APIs. Learn how intelligent validation transforms microservices testing. Read the deep dive guide. Type Guide Reading time 12 min Published February 28, 2026 Updated July 13, 2026 #### Shifting Left: The Rise of AI-Powered Continuous PR Validation API contract testing was meant to be the safety net for microservices, ensuring that when one team updates a service, they won’t break others. But as organizations scale their services and teams, traditional contract testing approaches are starting to buckle under the pressure. Many teams that “tried Pact… didn’t stick” due to **too much maintenance** and tests that “get out of date fast.” In theory, [consumer-driven contract tests](https://www.signadot.com/comparison/pact/) should catch breaking API changes early. In practice, they often introduce their own bottlenecks in large, evolving systems. The reason is simple: maintaining explicit API contracts by hand doesn’t scale. A single API change can trigger dozens of contract updates across client services, creating a significant maintenance tax for developers. It’s no surprise that teams frequently abandon contract testing efforts that become “dusty old tombs” rather than living documentation. This scaling problem is no longer theoretical. A growing share of code is now written by AI coding agents like Claude Code, Codex, and Cursor, and they produce API changes far faster than anyone can hand-maintain a contract for. When the volume of changes jumps, any approach that depends on a human keeping the contracts in sync falls behind immediately. The bottleneck has moved from writing the change to knowing whether it is safe to merge. Moreover, these tests often check **specifications, not real behavior**. They assert that a service meets a predefined spec, but can miss subtle integration issues that only appear when the service interacts with [real dependencies](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). In a microservice architecture where _behavioral_ compatibility matters as much as structural typing, this gap is dangerous. And for developers, traditional contract testing can feel like a **white-box exercise** requiring deep implementation knowledge and fragile test data setups. In short, what started as a guardrail becomes another source of friction. From a platform engineering perspective, this problem translates to slow feedback and brittle pipelines. If every API change triggers a cascade of Pact file edits and synchronized releases between teams, velocity suffers. The original promise of microservices, independent deployments and faster iteration, gets undermined by heavy coordination costs. Clearly, a new approach is needed. What would it look like to validate APIs _without_ all this overhead? #### Introduction: The Staging Bottleneck and the Need for Speed Safety nets for microservices, from API contract tests to end-to-end integration suites, were meant to ensure that when one team updates a service, they won’t break others. But as organizations scale their services and teams, traditional testing approaches are starting to buckle under the pressure. Shared staging environments, brittle test suites, and even manual contract testing approaches are failing. Teams say that they “tried Pact… didn’t stick” due to high maintenance and tests that “get out of date fast”. In theory, late-stage testing should catch breaking changes. In practice, these methods often introduce their own severe bottlenecks in large, evolving systems. The reason is simple: maintaining complex test environments and explicit test suites by hand doesn’t scale. A single API change can trigger dozens of test updates and reruns across services, creating a major maintenance tax for developers. It’s no surprise that teams frequently abandon contract testing efforts that become “dusty old tombs” rather than living documentation. Moreover, these tests often run too late and check specifications, not real behavior. They can miss subtle integration issues that only appear when the service interacts with real dependencies. In a microservice architecture where behavioral compatibility matters as much as structural typing, this gap is dangerous. For developers, traditional testing can feel like a white-box exercise requiring deep implementation knowledge and fragile test data setups. What started as a guardrail becomes another source of friction. From a platform engineering perspective, this problem translates to slow feedback and brittle pipelines. If every API change requires a full integration suite to run in a queued, shared environment, velocity suffers. The original promise of microservices, independent deployments and faster iteration, gets undermined by heavy coordination costs. The environment is the real constraint: local setups are resource-limited and low-fidelity, while shared and staging environments are slow and contended. An agent generating a steady stream of changes cannot make progress if every one of them has to queue behind that. What would it look like to validate APIs and service behavior without all this overhead? What if you could catch bugs _continuously_, as part of every pull request, paving the way for true continuous delivery? #### The Shift to Intelligent, Continuous PR Validation Instead of forcing developers to manually write and update complex test suites, the emerging approach is to let the system do the work. This is the shift from slow, late-stage testing to a fully managed solution for continuous PR validation. Modern solutions like Signadot’s **SmartTests** product pioneer this approach by shifting from manual enforcement to intelligent behavioral validation. - **_No more exhaustive, brittle test suites._** _You write a lightweight functional test (e.g., a few critical API calls) and let the platform infer the rest by observing real interactions. The system learns the current baseline behavior of your services and uses that as the “implicit contract,” testing every change against it automatically._ - **_No dedicated test infrastructure or complex mocks._** _Rather than spinning up custom mock servers or maintaining separate integration environments just to validate changes, these tests run in real ephemeral environments under the hood. No stubs to maintain and no fake data drifting from reality, validation happens against real, running services_ - **_No waiting for production failures._** _Instead of discovering too late that an API change broke something, you catch issues before merge as part of the pull request workflow, with rapid feedback and minimal setup._ With [SmartTests](https://www.signadot.com/product/smart-tests/), AI-powered analysis takes over the heavy lifting of change detection, automatically identifying what’s different and filtering out the noise. For example, SmartTests uses a “Smart Diff” model. This leverages a dedicated AI model to compare responses from the baseline and new service versions to distinguish meaningful breaking changes (e.g., a removed field or changed status code) from benign noise (like differing timestamps or IDs). This eliminates the false positives and flaky tests that plagued traditional systems. Developers no longer have to sift through irrelevant failures because the AI only highlights the differences that actually matter. Crucially, this approach validates actual runtime behavior by running the new version of a service in an isolated environment and comparing its responses to the current baseline version. This dynamic testing is like having an automated reviewer that catches subtle regressions that static tests would miss, flagging any meaningful deviations in behavior. It is also the kind of signal an AI coding agent can act on directly: a precise, behavioral diff between baseline and changed service tells the agent exactly what its change broke, so it can close the loop itself and [validate AI-generated code against real Kubernetes dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/) without waiting on a human or a shared environment. Teams have found it transformative. [DoorDash](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/), for instance, used this model to slash integration test feedback time from over 30 minutes to under two, effectively turning each pull request into a full integration validation gate rather than just a code review. #### High-Fidelity Sandboxes: Testing without Environment Headaches A key enabler of AI-powered, continuous PR validation is the use of lightweight sandboxes and request-level isolation. To validate behavior properly, tests need to run in an environment that is as close to production as possible. The naive solution is to duplicate full environments for each test or for each developer, but at scale, that’s painfully slow and prohibitively expensive. Spinning up dozens of microservices and databases for every feature branch is a huge time sink at scale, and it incurs cloud costs that can quickly grow out of control. Request-level isolation offers a smarter path. Instead of cloning everything, you run a single shared Kubernetes cluster as a baseline (with all services at their stable versions), and you isolate tests at the application layer. By routing specific test requests to sandboxed service instances, each pull request gets its own ephemeral environment. This means only the API calls related to your change get diverted to your new code. Everything else uses the shared, production-like components. The result is a high-fidelity test run without duplicating entire environments. Your sandboxed service is talking to real dependencies with real data, so the observed behavior matches what would happen in production. You don’t have to pay the cost of booting an entire stack. The environment comes up in seconds, and each sandbox is isolated by context so that dozens of tests can run in parallel on the same cluster without interference. This approach also dramatically changes the cost equation for testing. Traditionally, the cost of test environments grew with the formula: (# of Developers) x (# of Services) Request-level sandboxing breaks that model, decoupling cost from team and service growth: infrastructure expenses now grow roughly with the sum of developers and services, not their product. [Brex](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) saw this firsthand: by switching from full-stack duplication to request-level sandboxes, they now save about $2 million annually in infrastructure costs and saw developer satisfaction jump by 28 points. #### Boosting Pull Request Velocity and DevOps Metrics When comprehensive testing becomes intelligent and environments become cheap, the effect on developer velocity is dramatic. Integration tests that used to happen only after merge (or not at all) can be pulled earlier into the development process. This has a direct impact on DORA metrics: - **Lead Time for Changes**: Catching integration issues within minutes in a PR instead of days or weeks later drastically reduces the time from commit to production-ready build. DoorDash’s move to on-demand sandbox testing cut their pre-deployment validation from 30+ minutes to ~2 minutes. - **Deployment Frequency:** Faster, more reliable PR checks mean teams can safely merge and deploy smaller changes more frequently. With isolated sandboxes, multiple feature branches can be tested simultaneously without queuing for a shared environment. - **Change Failure Rate:** Catching breaking API issues before they reach mainline reduces the number of hotfixes and incidents in production. [Earnest](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) reported an **80% reduction in production incidents** after adopting early, high-fidelity integration testing. - **Mean Time to Restore:** Higher confidence in each release and smaller changesets make it easier to rollback problematic changes quickly. #### Real-World Results: DoorDash, Brex, and Earnest The move to AI-powered PR validation and sandboxed environments isn’t just theoretical. Several large engineering teams have already seen major benefits in practice: - [**DoorDash**](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/)**:** Achieved a **10× faster feedback loop** on code changes, cutting deployment validation from over 30 minutes to under 2 minutes, and retired their shared staging environment entirely. - [**Brex**](https://www.signadot.com/blog/how-brex-transformed-developer-experience-and-slashed-infrastructure-costs-with-signadot/)**:** Saves about $2 million annually in infrastructure costs and saw developer satisfaction climb by 28 points after switching to request-level isolation. - [**Earnest**](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/)**:** Reduced production incidents by 80% thanks to early, high-fidelity sandbox testing. #### The Road Ahead: Invisible, Comprehensive Testing in the Inner Loop Imagine a future where testing is so seamlessly integrated into development that it’s practically invisible. That’s where we’re headed. AI-powered validation checks and ephemeral environments are making continuous testing a natural part of writing code, rather than a separate phase. Every pull request spins up an isolated sandbox, runs a suite of tests, and delivers immediate feedback to the developer without extra setup or coordination. But functional API testing is just the beginning. The real goal is to “shift left” _all_ forms of validation. This same managed platform is being extended to support a wide range of non-functional testing, all triggered within the same, simple PR workflow. This includes: - **Performance Testing:** Automatically run baseline performance tests against your sandboxed service to catch latency regressions or $N+1$ query issues before they impact users. - **Security Testing:** Integrate automated security scans (like DAST) to probe your new code in its high-fidelity sandbox, finding vulnerabilities long before they reach a production environment. - **Log Analysis:** Use AI to analyze the logs generated by your service during the test run, automatically flagging new error patterns, concerning warnings, or significant deviations in log volume. - **Chaos Testing:** Proactively introduce controlled failures, like network latency or pod kills, within the isolated sandbox to validate that your service’s resilience and fallback logic work as intended, all without risking the shared cluster. This future is enabled by platform engineering, AI-driven validation, and a relentless focus on developer experience. For platform and senior engineers, this means rethinking the traditional testing strategy: brittle test suites and a single, overloaded staging environment won’t cut it. The path forward is integrated, automated, and developer-centric. It also lines up with where development itself is heading. As more code is written by AI coding agents, the work of validation has to keep pace with the work of generation, and it has to happen without a human in the loop for every change. Signadot provides both halves of that loop: sandboxes as the isolated, high-fidelity environment layer, and SmartTests, Jobs, and Plans as the validation layer on top. SmartTests gives an agent the same zero-maintenance behavioral signal it gives a developer, comparing baseline against the changed service and flagging the differences that matter, so agent-generated change can be verified at the speed it is produced. Take Signadot for a whirl and see it for yourself! Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Microservices Testing for FinTech Source: https://www.signadot.com/microservices-testing-for-fintech/ Summary: How fintech engineering teams test microservices safely in production-like Kubernetes environments. ### Microservices Testing for FinTech Signadot helps fintech companies test microservices safely in production-like environments. Secure Kubernetes testing for financial services. Learn more. Type Guide Reading time 15 min Published February 28, 2026 Updated June 21, 2026 #### Executive Summary In FinTech, testing isn’t just about software quality, it’s about safeguarding customer trust, ensuring regulatory compliance, and enabling secure innovation. But the rise of microservices architectures has exposed fundamental flaws in traditional testing workflows, especially staging environments. As FinTech organizations scale, the cost, complexity, and inefficiencies of infrastructure-heavy testing environments become unsustainable. This pressure is intensifying as more code is written by AI coding agents like Claude Code, Codex, and Cursor. A growing share of changes inside regulated FinTech orgs now originates from these tools, and they produce changes far faster than anyone can hand-review them. Writing the change is no longer the hard part: knowing whether it is safe to merge is, and in FinTech an unvalidated change is a compliance and financial risk, not just a bug. The general case, what a staging environment is for and the four architectures that replace the single shared copy, is covered in the [complete guide to staging environments](https://www.signadot.com/staging-environments/). This white paper explores the evolution of testing strategies in FinTech and introduces a new solution: Kubernetes-native sandbox environments. These lightweight, production-like testing spaces offer compliance-ready isolation without duplicating infrastructure, adding speed, scalability, and precision. With real-world examples from leading organizations like Brex, Earnest, and DoorDash, we demonstrate how the sandbox model is redefining how FinTech teams [test microservices](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). #### 1\. The FinTech Imperative: Trust, Compliance, and Speed FinTech applications operate in a uniquely high-stakes environment. They manage sensitive customer data, execute financial transactions, and rely on intricate integrations with external APIs, such as payment processors and fraud detection systems. In this context, software bugs aren’t just inconvenient, they pose serious risks, including financial loss, reputational damage, and regulatory violations. That’s why high-fidelity testing environments are essential in FinTech. They ensure that every new feature, update, or workflow behaves correctly before reaching production, reducing the risk of costly errors. The arrival of AI coding agents sharpens this point. When the volume of generated code jumps, the bottleneck moves from writing code to validating it, and that is precisely the part regulated FinTech teams cannot shortcut. Every agent-generated change still has to be proven safe against real payment and banking dependencies and within the same PCI DSS and GDPR boundaries, so the demand for high-fidelity, compliant validation rises in step with the code being produced. However, testing in FinTech comes with a distinct set of challenges. Regulatory frameworks such as PCI DSS and GDPR impose strict requirements around data handling, access controls, and system auditing. These constraints make it nearly impossible to simply clone production environments or data. Additionally, FinTech systems often depend on real-world, external services, including banking networks and payment gateways, that introduce unpredictable behaviors like rate limiting, timeouts, and service outages. These interactions must be tested in realistic conditions to ensure reliability. At the same time, every action in a testing environment must meet security and auditability standards, which adds further complexity. Historically, staging environments have played a critical role in addressing these challenges. Designed to replicate production conditions, they’ve been the go-to solution for validating functionality and compliance. But as FinTech systems grow more complex and teams scale, the traditional staging model is showing its limits. Maintaining multiple production-like environments is costly, difficult to synchronize, and increasingly prone to bottlenecks and delays. What was once a safety net is now becoming a drag on velocity and innovation. #### 2\. The Microservices Testing Paradox The shift from monolithic architectures to microservices has enabled software teams to achieve greateragility and scalability. In this new model, services are decoupled and independently deployable, allowingteams to move faster and scale specific parts of their systems without impacting others. This architecturalevolution has been especially appealing to FinTech companies looking to innovate quickly while managingcomplex systems. However, it has also introduced significant new testing challenges. While unit testing continues to scale effectively in microservices environments, enabling developers to test components in isolation, integration testing becomes increasingly difficult. As services proliferate, interdependencies grow. A simple feature change may span multiple services, each potentially managed by different teams using different stacks. These cross-service interactions are a frequent source of failures. Common issues include mismatched API versions, inconsistent data contracts, and hard-to-reproducebugs stemming from asynchronous workflows. Integration testing must account for all of these variables to ensure reliability, but doing so at scale is complex and time-consuming. This is particularly challenging in FinTech systems, where asynchronous flows are everywhere: fraud detection triggers, payment settlement queues, webhook-driven notifications, and more. These workflows don’t follow a simple request-response pattern, which means bugs can emerge long after a request is made, and failures often surface far downstream from their root cause. Testing these flows reliably requires high fidelity environments and end-to-end visibility, which most teams lack in their current setup. *Image: RabbitMQ, AWS SQS, Google Cloud Pub/Sub, and Kafka logos* Recent industry data highlights the severity of the issue. According to the CNCF’s 2024 annual survey, 80% of respondents are running Kubernetes in production (cncf.org). Yet despite the widespread adoption, many organizations continue to struggle with testing. Moreover, developers in microservices organizations lose an estimated 8 to 10 hours per week (getdx.com) dealing with testing bottlenecks and context switching. For a 200-person engineering team, that equates to approximately $400,000 in lost productivity each month. AI coding agents widen this gap further: they generate changes far faster than these bottlenecked workflows can absorb, so the queue of work waiting to be validated grows rather than shrinks. In FinTech, where trust, compliance, and speed are critical, these inefficiencies are unacceptable. Testing workflows must scale effectively, catching integration issues early, without compromising on security, data privacy, or regulatory compliance. Traditional staging environments, designed for simpler, monolithic systems, were never built to handle the dynamic, large-scale demands of today’s FinTech microservices. As a result, many organizations are now searching for modern testing solutions that align with the realities of microservices development. What FinTech teams need is a modern testing approach, one that supports asynchronous workflows, deep service integration, and scalable developer autonomy, without compromising compliance or operational integrity. #### 3\. Why Traditional Staging Breaks at Scale As FinTech organizations scale, their testing needs become more complex, and traditional staging environments struggle to keep up. Most teams fall back on one of three common testing strategies, each with its own benefits but also critical limitations. The first approach relies on mocks and unit tests, which are fast and easy to run. This method is popular because it allows developers to test individual components in isolation and get rapid feedback during the development cycle. However, this speed comes at the expense of realism. Mocks oversimplify service interactions and fail to capture the behavior of external systems like payment gateways, identity verification services, or fraud detection tools. As a result, many bugs go undetected until much later in the release process, often in production. The second approach is to use shared staging environments, which aim to closely replicate production conditions by running all services together in a single environment. This setup improves test accuracy compared to mocks but introduces a new set of problems. Because the environment is shared across multiple teams, it’s prone to test collisions, data conflicts, and instability. When multiple developers deploy overlapping changes or run conflicting tests, issues arise that are difficult to trace and resolve. These bottlenecks create delays, reduce developer confidence, and increase the time required to validate changes. *Image: Challenges in shared staging environments: team pull requests queue for one environment, causing long wait times and resource conflicts* The third and most comprehensive approach is environment duplication, creating a full copy of the staging environment for each team or use case. This strategy delivers high fidelity and strong isolation, making it easier to detect issues early and ensure test accuracy. However, the operational and financial costs are steep. Each environment must maintain compliance with regulations like PCI DSS and GDPR, which means provisioning isolated encryption keys, access controls, and secure audit logging. Additionally, these environments require unique configurations and connections to third-party APIs. As the number of environments grows, so does the complexity of managing and securing them. In practice, each of these approaches introduces friction. Duplicating environments creates significant overhead and delays due to the need for specialized infrastructure. Mocking trades off realism and often results in runtime failures that escape early detection. Sharing environments leads to interference between teams, test flakiness, and slower feedback cycles, all of which hinder development velocity. As one FinTech VP described their experience: > “We had dozens of staging environments, but debugging took days. There was always something out-of-sync, or a conflict we couldn’t reproduce.” This quote reflects a broader industry trend: traditional testing strategies may have worked for simpler systems, but they fall apart under the scale, security demands, and interdependencies of modern FinTech. A more scalable, cost-effective, and developer-friendly testing model is needed to move forward. #### 4\. A Paradigm Shift: The Sandbox Model *Image: Sandbox model diagram: developer workstation and Git branch sandboxes testing changes against a shared baseline environment* Sandbox environments offer a fundamentally different approach to testing microservices, one that breaks away from the infrastructure-heavy methods of the past. Rather than duplicating an entire application stack for every developer or test case, sandboxes isolate only the specific services under development. These services are then seamlessly integrated into a shared, high-fidelity baseline environment that mirrors production. This model dramatically reduces complexity and infrastructure costs while maintaining the realism and compliance needed in FinTech systems. At the core of this approach is selective deployment. Developers no longer need to spin up the entire system to test a change. Instead, they deploy only the service they are actively working on. This minimizes resource usage and accelerates the development cycle, especially when working within complex, multi-service architectures. Once deployed, request routing ensures that traffic is intelligently directed through the sandbox. Each request includes a sandbox identifier, which tells the system whether to route the call to the developer’s modified service or to the shared baseline version. This level of control allows for precise, per-sandbox behavior without duplicating the entire environment. Context propagation is another critical capability of the sandbox model. As a request flows through multiple services in a microservices architecture, it carries the sandbox context with it. This ensures that the entire chain of service calls remains isolated within that sandbox, preserving the integrity of the test and avoiding cross-contamination with other developers’ work. The foundation for all of this is a shared baseline environment. This environment runs continuously, containing the latest stable versions of all services and complying with organizational security and regulatory standards. By building on this shared baseline, sandboxes inherit its compliance posture, configuration, and connections to real external services, without requiring individual setups to replicate them. For FinTech teams, the benefits of this model are substantial. First, sandboxes inherit compliance from the shared environment. This means developers can test in production-like conditions without reconfiguring PCI DSS controls, audit logging, or encryption mechanisms. Second, sandboxes support real API integration. There’s no need to rely on mocks: teams can test against actual payment gateways, fraud tools, and banking APIs, capturing issues like rate limits and timeouts that often go undetected in simplified test setups. This inherited compliance is what makes sandboxes well suited to AI-driven development. Because a sandbox already sits inside the compliant baseline, an agent-generated change can be validated against real payment and banking dependencies without anyone standing up a separate compliant environment for it. That property matters most when the author is an agent rather than a person: agents do their best work when they can close the loop themselves, making a change, testing it against real dependencies, reading the result, and fixing, which requires environments that are quick and cheap to create but still high fidelity. Signadot supplies both halves of that loop: sandboxes as the isolated environment layer, and a validation layer on top in SmartTests, Jobs, and Plans that exercises the change and reports back. For a closer look at this workflow, see how teams [validate AI-generated code against real Kubernetes dependencies](https://www.signadot.com/validate-ai-generated-code-kubernetes/). Additionally, sandboxes provide fast feedback. Because they avoid full environment provisioning, developers can spin up a sandbox in seconds, test their changes, and iterate quickly. This speeds up the development loop and reduces time-to-release. Finally, the model is inherently audit-ready. All test activity remains within compliant boundaries, and sandbox-specific logs and headers allow for precise traceability, an essential requirement in any regulated FinTech environment. In short, sandbox environments enable FinTech teams to test faster, smarter, and more securely, without sacrificing the realism or regulatory rigor their applications demand. #### 5\. Real-World Use Cases: From Scaling to Security ##### [**Brex**](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) Brex adopted sandbox testing via Signadot to support hundreds of developers while maintaining complianceand real API fidelity. They: *Image: Brex outcomes with Signadot: infrastructure costs reduced by $2M per year, no environment drift, and faster development cycles, with a quote from Phil Burrows* ##### [**Earnest**](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) Earnest integrated Signadot into their CI/CD pipelines to enable instant sandbox environments and automated end-to-end testing, giving developers real-time insights into service behavior and dramatically improving release reliability. This shift empowered dev teams to: *Image: Earnest outcomes with Signadot: integration bugs caught early, faster code-merge confidence, and fewer staging surprises, with a quote from Early Ehlinger* ##### [**DoorDash**](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/) DoorDash’s developers use CLI-triggered sandbox environments, integrated with Istio for header-based routing. This self-service model enabled: *Image: DoorDash outcomes with Signadot: 70% lower infra costs, fewer pre-production bugs, and greater developer satisfaction, with a quote from Amit Gud* #### 6\. The Sandbox Advantage for FinTech *Image: Table comparing the traditional approach and the sandbox model across compliance, integration fidelity, async workflows, cost, speed, developer velocity, and data handling* #### 7\. Implementation Considerations Sandbox testing builds on technologies many FinTech teams already use. If you’re running on Kubernetes and using tools like Istio, Linkerd, or an API gateway, you likely already have the core building blocks in place. Even without a service mesh, lightweight systems like Signadot’s DevMesh provide built-in routing and context management, making it easy to get started. A key enabler is context propagation, passing a sandbox ID across service calls. This is made trivial by standards like OpenTelemetry, and in most interpreted languages (e.g., Java, Node.js, Python), auto instrumentation libraries mean no application-level changes are required. For event-driven systems like Kafka or SQS, sandbox IDs can be embedded in message headers to ensure isolation across async flows. Data isolation is handled through existing multi-tenant patterns or ephemeral database clones. Most teams start by scoping data to sandbox-specific IDs and clone databases only for services that require deeper or destructive testing. Sandboxes also integrate seamlessly with developer workflows. Engineers can spin up environments through CLI tools or CI pipelines, deploy just the service they’re changing, and test against real dependencies. Observability tools like Datadog and Grafana work out of the box, automatically tagging logs and traces by sandbox ID, so there’s nothing new to build. With minimal setup, sandboxes deliver isolated, production-like environments that fit naturally into modern FinTech stacks, enabling fast, compliant testing without the overhead of full environment duplication. #### 8\. Conclusion: Building Resilient FinTech Systems As the FinTech landscape continues to evolve, systems are becoming increasingly interconnected. New partnerships, third-party APIs, and constantly changing regulatory requirements are raising the stakes for integration testing. In this environment, even a small misconfiguration or unnoticed compatibility issue between services can lead to serious consequences, ranging from failed transactions to compliance violations. As the complexity of these systems grows, so too does the cost of inadequate testing. Unfortunately, traditional testing environments, whether shared staging environments or fully duplicated infrastructure, are no longer sufficient. Shared environments often lead to test interference, stale configurations, and bottlenecks that slow development. On the other hand, duplicating environments for every team or use case introduces prohibitive infrastructure costs, maintenance overhead, and compliance complexity. These legacy approaches cannot keep up with the speed, precision, or security required by modern FinTech development. Sandbox environments offer a much-needed breakthrough. By providing isolated, production-like testing spaces built on top of a shared and compliant baseline, sandboxes deliver the best of both worlds. They allow developers to work autonomously while maintaining strict security and data boundaries. Developers can test their services against real dependencies without impacting others, ensuring higher test fidelity without the cost of full duplication. **What sets sandboxes apart is their ability to align key objectives that are often at odds:** *Image: Three benefits of sandbox environments: safe independent testing, high-fidelity testing without duplicating systems, and regulatory compliance at speed* This advantage compounds as AI coding agents take on more of the writing. The constraint in FinTech is no longer how fast code can be produced, it is how fast each change can be proven safe to merge under real dependencies and real compliance controls. Sandboxes paired with a validation layer let teams keep that bar high while agents close their own loop, so the growing volume of generated code becomes throughput rather than risk. Ultimately, FinTech organizations that embrace sandbox testing gain a clear strategic advantage. They can release features with greater confidence, reduce bugs and delays, and maintain rigorous compliance, all while empowering developers, and the agents working alongside them, to move quickly and safely. In a sector where trust, speed, and innovation are tightly linked, sandbox environments are becoming essential infrastructure for success. #### About Signadot Signadot is a Kubernetes-native testing platform purpose-built for microservices. It enables application layer sandbox environments, letting developers test their changes in isolated, production-like conditions without duplicating infrastructure. Signadot helps FinTech companies shift testing left, boost developer velocity, and maintain compliance without compromise. [Learn more → www.signadot.com](https://www.signadot.com/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## What Are Preview Environments? The Complete Kubernetes Guide Source: https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/ Summary: What preview environments are, how they work in Kubernetes, and an honest comparison of the four main ways to build them: full duplication, virtual clusters, GitOps pipelines, and request-level isolation. ### What Are Preview Environments? The Complete Kubernetes Guide Author Arjun Iyer Published July 31, 2025 Updated August 31, 2026 _Image by Mo from Unsplash._ **Preview environments** are on-demand, isolated deployments created automatically for each branch or pull request, so reviewers can click through a live version of a change before it merges. They are provisioned when the PR opens, get a shareable URL, and are destroyed when it closes. This guide explains how preview environments work in Kubernetes, the benefits they unlock, and an honest comparison of the four main ways to build them. #### **Introduction: Escaping the Staging Bottleneck** In the landscape of modern software development, particularly within microservice-based architectures, the traditional, monolithic staging environment has evolved from a reliable proving ground into a significant impediment to velocity. This shared, long-lived environment, once a staple of the software development lifecycle (SDLC), now frequently represents a central bottleneck. Teams operating in parallel find themselves in a constant state of resource contention, queuing for their turn to deploy and test features. This queuing behavior directly contradicts the agile principles of rapid, independent deployment that microservices are intended to enable. A primary challenge of the shared staging environment is the high risk of “feature fratricide,” where multiple, concurrent, and often unstable features are deployed into the same space. When a test fails, it becomes a time-consuming forensic exercise to determine whether the failure was caused by your changes, a colleague’s recent deployment, or a latent issue in the environment itself. This uncertainty erodes developer confidence and slows down the entire delivery pipeline. These environments are also susceptible to configuration drift, where their state slowly diverges from production, diminishing the value of the tests performed within them. As application complexity and team size scale, these problems are magnified, transforming the staging environment into a primary constraint on an organization’s ability to innovate and release software frequently and reliably. The [complete guide to staging environments](https://www.signadot.com/staging-environments/) covers those failure modes and the four alternatives to the shared copy, of which preview environments are one. #### **Preview Environment Platforms at a Glance** A preview environment is a type of [ephemeral environment](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) created automatically for each pull request. Four approaches dominate Kubernetes preview environments today: - **Okteto** provisions a full copy of your stack per PR. Simplest mental model and great inner-loop developer experience, but infrastructure cost scales linearly with the number of services. - **vCluster** gives each PR a virtual Kubernetes cluster. Strongest isolation, ideal when changes touch operators, CRDs, or cluster config, with some control-plane overhead. - **ArgoCD with Jenkins** is the GitOps, build-it-yourself route. Maximum control and auditability, highest implementation and maintenance cost. - **Signadot** uses request-level isolation on a shared baseline cluster. You deploy only the services that changed, so previews spin up in seconds at the lowest cost per PR and scale to hundreds of concurrent environments. The rest of this guide explains how preview environments work, the benefits they unlock, and a deep, honest comparison of each approach so you can pick the right one for your scale and architecture. #### **Defining the Modern Preview Environment** In response to the limitations of traditional staging, a new paradigm has emerged: the modern preview environment. A preview environment is an on-demand, isolated, and ephemeral deployment created automatically for a specific branch or, more commonly, a Pull Request (PR). Unlike their static predecessors, these environments are dynamic components of the development workflow, designed to provide a high-fidelity preview of code changes as they would behave in production. Their lifecycle is intrinsically tied to the PR they serve. They are provisioned when the PR is opened and automatically destroyed upon merge or closure, a practice that ensures a clean slate for every set of changes and conserves valuable infrastructure resources. The core attributes of a well-architected preview environment system are critical to its success: - **On-Demand & Ephemeral:** Environments are created and destroyed automatically, aligning their lifecycle with that of the feature being developed. This temporary nature is a key differentiator, preventing resource waste and eliminating the leftover data and configurations that plague static environments. - **Production-Like:** To be effective, a preview environment must mirror the production environment as closely as possible. This includes using similar services, dependencies, data schemas, and underlying infrastructure configurations. This fidelity is essential for reliably identifying integration gaps and performance issues early, effectively solving the classic “but it works on my machine” problem by moving validation off the developer’s local machine and onto a realistic, shared infrastructure. - **Isolated:** Each preview environment is self-contained, ensuring that tests for one PR cannot interfere with the tests for another. This parallelism is crucial for unblocking teams and eliminating the bottlenecks associated with shared staging environments. Isolation can be achieved at various levels, from the Kubernetes namespace to the individual application request. However. the goal remains the same: to guarantee that any observed behavior is a direct result of the changes within the PR. - **Automated & GitOps-Driven:** The creation, updating, and destruction of preview environments should be fully automated and integrated with the organization’s CI/CD pipeline and version control system (VCS), such as Git. This automation means the environments respond to repository events (e.g., opening a PR, pushing a new commit) without requiring manual intervention, reducing cognitive load on developers and embedding the process seamlessly into their existing workflow. #### **The Transformative Benefits of PR-Centric Previews** The adoption of PR-centric preview environments yields a host of transformative benefits that ripple across the entire engineering organization, fundamentally altering how teams collaborate, test, and deliver software. - **Accelerated Feedback Loops:** Perhaps the most significant advantage is the drastic compression of feedback cycles. In a traditional workflow, critical feedback from stakeholders often arrives late, after code has been merged and deployed to a staging environment. Preview environments shift this feedback to the earliest possible moment: during the PR review process itself. Developers can receive immediate, actionable input from product managers, designers, and QA engineers, allowing for rapid iteration and refinement before the code is ever merged into the main branch. This real-time validation can reduce feature delivery times by as much as 60% by eliminating the dependencies on shared environments. - **Enhanced Collaboration:** Preview environments act as a powerful collaboration hub. By providing a unique, shareable URL for each PR, they democratize the review process. Non-technical stakeholders, who would otherwise rely on static mockups or screenshots, can now interact with a live, fully functional version of the feature. Product managers can perform User Acceptance Testing (UAT), designers can validate the user experience, and marketing teams can align on messaging, all based on the same interactive artifact. This shared context reduces miscommunication and ensures that the final product is a result of holistic, cross-functional input, not just a successful code diff. - **Shift-Left Quality Assurance:** The practice of “shifting left” involves moving testing activities earlier in the development lifecycle. Preview environments are a cornerstone of this philosophy. They enable comprehensive testing (including unit, integration, and full end-to-end (E2E) tests) to be executed against a production-like environment for every single PR. This allows for the detection of complex integration bugs and performance regressions that would be nearly impossible to catch in a local development environment or with unit tests alone. By identifying and resolving these issues before a merge, organizations can significantly reduce the number of production bugs, with some reporting up to a 50% decrease. - **Improved Developer Experience (DevEx):** For engineering managers focused on optimizing developer productivity, preview environments offer a substantial improvement to DevEx. They eliminate the frustrating wait times and contention associated with shared staging environments, allowing developers to test their work in parallel. They also unburden team leads and senior engineers from the time-consuming task of manually pulling down PR branches to their local machines for validation, which is inefficient and lacks standardization. By providing a standardized, automated, and high-fidelity testing environment on demand, preview environments boost developer confidence, reduce infrastructure-related delays, and allow engineers to focus on what they do best: writing and shipping high-quality code. The move toward preview environments is more than a simple tooling upgrade. It signifies a profound evolution in the software development process. The traditional, linear progression of develop, review, merge, test is inherently inefficient, creating hand-offs and delays at each stage. The introduction of a preview environment for every PR dissolves this sequential model, replacing it with a highly parallel and collaborative workflow. When a PR is opened, it triggers a convergence of activities: code review by peers, automated testing by the CI system, exploratory testing by QA, and functional review by product and design stakeholders all occur simultaneously. This parallelization not only accelerates the delivery timeline but also fundamentally changes the nature of collaboration, fostering a more integrated and agile culture where quality is a shared responsibility from the very beginning of a feature’s lifecycle. #### **The Full-Duplication Model: Okteto** ##### **Core Philosophy: The Ultimate Developer Experience** Okteto’s market position and product philosophy are squarely focused on maximizing developer productivity and delivering a superior Developer Experience (DevEx). The platform is engineered to abstract away the inherent complexities of Kubernetes, providing a seamless bridge between local development and a production-like cloud environment. The core tenet is to empower developers to concentrate on application logic and code, rather than becoming experts in infrastructure configuration and management. Okteto aims to replicate the speed and immediacy of local development within a robust, shareable, and high-fidelity cloud-native setting. ##### **Architectural Deep Dive: Namespace-per-PR Replication** The architectural foundation of Okteto’s preview environment solution is **full-stack replication**. For each pull request, [Okteto](https://www.signadot.com/comparison/okteto/) provisions a complete, independent copy of the application stack, including all microservices, databases, and other dependencies. - **Isolation Mechanism:** This full replication is achieved by creating a dedicated and isolated Kubernetes **namespace** for each preview environment. This namespace acts as a hard boundary, ensuring that the resources for one PR (e.g., app-pr-123) are completely separate from those of another (e.g., app-pr-124). The okteto namespace create command is a fundamental primitive within the Okteto CLI, underscoring the centrality of this approach. - **Configuration:** The entire environment, including its services, deployment commands, dependencies, and development container settings, is defined declaratively within an okteto.yaml manifest file. This file serves as the single source of truth for what constitutes a development or preview environment, ensuring consistency and repeatability. - **Workflow:** The process is tightly integrated with standard CI/CD practices: 1. A developer finalizes a feature and opens a pull request in a Git repository. 2. This event triggers a CI/CD pipeline (e.g., using GitHub Actions, GitLab CI). The pipeline executes the okteto deploy command, which reads the okteto.yaml manifest. 3. Okteto’s platform receives the command and orchestrates the creation of a new, uniquely named Kubernetes namespace. It then proceeds to deploy all the components defined in the manifest into this new namespace. 4. Upon successful deployment, Okteto generates and reports back a unique, shareable URL that provides access to the running preview environment, which can then be posted as a comment on the PR for easy access by reviewers. - **Inner Loop Optimization:** A standout feature of the Okteto platform is its optimization of the “inner loop” development cycle. Using the okteto up command, a developer can establish a real-time, two-way file synchronization between their local filesystem and the development container running in the remote Kubernetes cluster. This allows code changes to be reflected in the running application in seconds, completely bypassing the time-consuming container build-and-push cycle that can take several minutes. This rapid feedback mechanism is a cornerstone of Okteto’s DevEx-centric philosophy. ##### **Strengths and Ideal Use Cases** The full-duplication model offers several distinct advantages, particularly for certain types of teams and applications. - **Simplicity and Ease of Use:** The mental model for developers is exceptionally straightforward. Each developer receives their own private, complete copy of the application. There is no need to reason about shared state, complex routing rules, or potential interference from other services. This simplicity lowers the barrier to entry and allows developers to be productive quickly without needing deep Kubernetes expertise. - **Complete Isolation:** Because every component of the stack is duplicated within a dedicated namespace, the risk of cross-environment interference is effectively zero. This provides a very high degree of confidence that any observed behavior or test result is a direct consequence of the code changes within the pull request. This level of isolation is [ideal for sensitive tests or when debugging complex, intermittent issues](https://www.signadot.com/comparison/okteto/). - **Excellent Inner-Loop DevEx:** The fast file synchronization feature (okteto up) is a significant productivity enhancer for developers during the active coding and debugging phase. The ability to see changes reflected in a production-like environment almost instantly is a powerful capability that dramatically shortens the code-test-debug loop. ##### **Limitations and Challenges** Despite its developer-friendly nature, the namespace-per-PR replication model carries [significant challenges](https://www.signadot.com/comparison/okteto/) that become more pronounced at scale. - **Resource Inefficiency and Cost:** This is the primary and most critical drawback. The model’s resource consumption and associated infrastructure costs scale linearly with both the number of microservices in the application and the number of active pull requests. For an application with 20 microservices, each open PR will spin up 20 service deployments, plus any associated databases or caches. For a team with 10 active PRs, this translates to 200 running services. This resource explosion can become prohibitively expensive and difficult to manage as teams and applications grow. - **Performance at Scale:** The time required to spin up a preview environment is directly proportional to the complexity of the application. For large applications with many services and complex startup dependencies, the provisioning time can extend to several minutes, which begins to erode the benefit of a “rapid” feedback loop. - **Environment Parity and Maintenance:** Maintaining dozens or even hundreds of independent, ephemeral environments and ensuring they remain in sync with production becomes a substantial operational challenge. Furthermore, the problem of data seeding (populating each ephemeral database with realistic and useful test data) is a non-trivial task that must be solved for each environment instance, adding to the complexity. The architectural decisions made by Okteto represent a clear and deliberate trade-off. The platform prioritizes the autonomy and mental ease of the individual developer above all else, choosing a model that provides unambiguous ownership and complete isolation. This approach is the most faithful cloud-native translation of the traditional “development environment on my laptop” concept, where every developer has their own self-contained world. The direct consequence of this architectural choice is the linear scaling of cost and resource usage, a point frequently highlighted in [comparative analyses](https://www.signadot.com/comparison/okteto/). For every unit of developer isolation (a single PR environment) the platform incurs a full unit of infrastructure cost. This reveals a philosophical stance: the cost of a developer’s time and cognitive load is deemed more significant than the cost of the underlying infrastructure. This equation holds true for smaller teams or applications with moderate complexity. However, as an organization’s scale and application complexity increase, this balance inverts, making the full-duplication model less tenable and economically unsustainable for large enterprises. #### **The Virtual Cluster Model: vCluster** ##### **Core Philosophy: True Kubernetes Isolation, Virtualized** The core philosophy of vCluster is to deliver the robust isolation and administrative boundaries of separate physical Kubernetes clusters but without the significant financial and operational overhead they entail. It carves out a unique position in the ecosystem by offering an isolation model that is substantially stronger and more secure than standard Kubernetes namespaces, yet far more lightweight, affordable, and faster to provision than dedicated, full-blown clusters. vCluster is designed for multi-tenancy, empowering teams to operate with full autonomy on shared infrastructure. ##### **Architectural Deep Dive: A Cluster Within a Namespace** vCluster’s architecture is an elegant implementation of cluster virtualization within Kubernetes itself. - **Core Components:** The fundamental principle of vCluster involves running a virtualized Kubernetes control plane as a standard workload within a single namespace of a “host” Kubernetes cluster. This virtual control plane is typically packaged as a StatefulSet and contains its own lightweight API server, a controller manager, and a data store (which defaults to an embedded SQLite database for efficiency). This means each vcluster has its own distinct API endpoint, separate from the host cluster’s API. - **The Syncer:** The magic of vCluster lies in a critical component called the syncer. When a user or a CI/CD process creates a Kubernetes resource (like a Pod or a Service) by interacting with the vcluster’s API server, the resource is recorded in the vcluster’s data store. The syncer component, which runs alongside the virtual control plane, detects this new resource. It then creates a corresponding “real” resource in the host cluster’s namespace. This real Pod is scheduled onto a physical node by the host cluster’s scheduler, but all of its subsequent lifecycle management (updates, deletions) is governed by the virtual control plane it originated from. - **Isolation Mechanism:** The isolation provided by vCluster is at the Kubernetes API level, which is a significantly stronger boundary than a simple namespace. Users of a vCluster can be granted cluster-admin privileges within their virtual cluster, allowing them to install operators, manage CRDs, and configure RoleBindings, all without possessing any elevated permissions on the underlying host cluster. This robust security model is a key differentiator, preventing “noisy neighbor” problems where one tenant’s actions could disrupt the entire host cluster. - **Workflow for Preview Environments:** 1. The process begins when a pull request is opened, triggering a CI/CD pipeline (e.g., via GitHub Actions). 2. The pipeline script executes commands against the vCluster Platform or uses the open-source vCluster CLI to provision a new virtual cluster. This is typically done using a pre-configured virtual cluster template that defines its characteristics, such as the Kubernetes distribution to use (e.g., K3s, k0s) and any specific configurations. The newly created vcluster and its components reside within a dedicated namespace on the host cluster. 3. Once the Ccluster is active, the pipeline proceeds to deploy the application’s manifests (e.g., using helm install or kubectl apply) directly into the new virtual cluster. 4. To expose the preview application to the outside world, Ingress resources created within the vCluster can be automatically synced by the syncer to the host cluster’s IngressController. This allows the application to be accessible via a unique URL, just like any other service on the host cluster. 5. Upon the closure or merging of the pull request, a corresponding cleanup job in the CI/CD pipeline is triggered. This job destroys the virtual cluster and its associated host namespace, ensuring all resources are reclaimed. ##### **Strengths and Ideal Use Cases** The virtual cluster model provides distinct advantages that make it particularly well-suited for specific, demanding use cases. - **Superior Security and Isolation:** This is the primary and most compelling benefit of vCluster. By providing each tenant (or in this case, each preview environment) with its own control plane, it creates a powerful security boundary. This model is ideal for organizations with high security and compliance requirements, as it ensures that actions within one preview environment cannot affect the stability or security of the host cluster or other tenants. - **Testing Cluster-Level Changes:** Because each vCluster is a genuine, albeit virtualized, Kubernetes cluster, it is the perfect environment for testing changes that go beyond simple application code. If a pull request involves installing or upgrading a Kubernetes Operator, introducing new Custom Resource Definitions (CRDs), or modifying cluster-wide permissions and network policies, vcluster is the only model (short of provisioning a full physical cluster) that can safely and accurately test these changes in an isolated manner. - **Cost-Effectiveness at Scale (vs. Physical Clusters):** When the alternative is provisioning a new physical cloud cluster (e.g., EKS, GKE, AKS) for each preview environment, vCluster offers dramatic cost and time savings. A vCluster can be spun up in seconds, whereas a new cloud-managed Kubernetes cluster can take many minutes to become available. This makes ephemeral, per-PR clusters logistically and financially feasible. ##### **Limitations and Challenges** While powerful, the vCluster approach is not without its own set of trade-offs and complexities. - **Resource Overhead (vs. Shared Models):** Although significantly lighter than a full physical cluster, a vCluster still incurs more resource overhead than models that share a control plane, such as namespace-based or request-based isolation. Each vcluster runs its own API server and controller manager, which [consume CPU and memory resources](https://www.signadot.com/comparison/vcluster/) on the host cluster. - **Configuration Complexity:** The initial setup and ongoing management of vCluster templates can be more complex than simpler models. Configuring the interaction between the virtual cluster and the host cluster, such as syncing ingresses, sharing services, or defining specific network policies, requires a deeper understanding of both vcluster’s configuration and Kubernetes networking. - **Potential Overkill for Simple Changes:** For a routine pull request that only involves updating a single service’s container image, the overhead of creating and managing an entire virtual Kubernetes cluster might be unnecessary. In such cases, a more lightweight approach could be more efficient. vCluster is fundamentally a platform-building and multi-tenancy tool that has found an excellent secondary application in the realm of preview environments. Its core value proposition is not just the isolation of application workloads, but the isolation of the Kubernetes control plane itself. When this capability is applied to preview environments, its unique strength becomes clear: it excels in scenarios where a pull request contains changes that transcend the application layer. If a PR modifies an operator, introduces a new CRD, or requires specific cluster configurations that could conflict with other tenants, vCluster provides the necessary sandbox to test these changes safely. This implies that vCluster is the optimal choice for organizations with advanced Kubernetes usage, high security postures, or those building complex platforms where application development is tightly coupled with changes to the underlying cluster infrastructure. It solves a deeper, more structural isolation problem than simple workload-duplication models. #### **The GitOps-Native Model: ArgoCD and Jenkins** ##### **Core Philosophy: Declarative, Auditable, and Extensible** The approach of using a combination of a CI tool like Jenkins and a GitOps CD tool like ArgoCD is fundamentally rooted in the core principles of GitOps. This philosophy posits that Git should serve as the single source of truth for the desired state of not only the application code but also its operational environment. Every action, from the initial deployment of a preview environment to its eventual teardown, is managed through declarative manifests stored in a Git repository. This ensures that the entire process is automated, auditable, and transparent, leaving a clear, version-controlled history of every change made to every environment. This model prioritizes flexibility, control, and governance above all else. ##### **Architectural Deep Dive: The Two-Repository CI/CD Flow** Implementing preview environments with this model typically relies on a well-defined workflow that spans two distinct Git repositories: one for the application source code and a separate one for the Kubernetes deployment manifests, often referred to as the “GitOps repository”. This separation of concerns is a widely adopted best practice in the GitOps community. **The Role of the CI Tool (Jenkins):** The process is initiated within the Continuous Integration pipeline. 1. A developer pushes code to a feature branch and opens a pull request in the **application source code repository**. 2. This event triggers a Jenkins pipeline. The pipeline’s first responsibilities are to build the application’s container image, run unit and integration tests, and tag the resulting image with a unique identifier, such as the Git commit SHA or the PR number. 3. The critical and most complex step follows: the Jenkins pipeline script checks out the **GitOps repository**. It then programmatically modifies the Kubernetes manifests within this repository. This could involve using a tool like kustomize or sed to update the image tag in a deployment.yaml file to point to the newly built image. Finally, the Jenkins pipeline commits these changes to a new branch in the GitOps repository and automatically opens a new, paired pull request. **The Role of the CD Tool (ArgoCD):** The Continuous Deployment part of the workflow is managed by ArgoCD. 1. A special ArgoCD resource, the ApplicationSet, is configured to monitor the **GitOps repository**. This ApplicationSet is equipped with a **Pull Request Generator**, a powerful feature that can automatically discover open PRs in a specified GitHub, GitLab, or Bitbucket repository. 2. When the generator detects the new pull request created by the Jenkins pipeline, it uses a predefined template to dynamically generate an ArgoCD Application custom resource. 3. This dynamically generated Application resource is configured with parameters extracted from the pull request. For instance, it points to the specific PR branch in the GitOps repo as its source of manifests and is configured to deploy the application into a new, unique Kubernetes namespace, often named dynamically using the PR number or branch name (e.g., my-app-pr-123). ArgoCD’s syncOptions can be set to CreateNamespace=true to handle this automatically. 4. ArgoCD’s reconciliation loop then takes over, comparing the desired state in the GitOps PR branch with the actual state in the cluster and applying the necessary changes to deploy the preview environment. 5. The lifecycle is completed when the pull request in the GitOps repository is closed or merged. The ApplicationSet generator detects this event and automatically deletes the corresponding Application resource. With a prune: true policy, ArgoCD then removes all associated Kubernetes resources, effectively tearing down the ephemeral environment. ##### **Strengths and Ideal Use Cases** This “build-it-yourself” approach offers a unique set of advantages for organizations with the right capabilities and requirements. - **Maximum Flexibility and Control:** Because the entire workflow is constructed from powerful, general-purpose, and highly extensible open-source tools, the organization has complete control to customize every single aspect. The logic in the Jenkins pipeline and the configuration of the ArgoCD ApplicationSet can be tailored to fit any specific or esoteric requirement. - **Strong Auditability and Governance:** The GitOps methodology ensures that every change to every environment, no matter how small, is represented as a commit in a Git repository. This provides an immutable, chronological, and perfectly auditable history of the state of all environments, which is a critical requirement for organizations in highly regulated industries like finance or healthcare. - **Vendor-Agnostic and Open-Source:** This approach avoids lock-in to any proprietary commercial platform. It is built entirely on well-supported open-source projects with large communities, giving the organization full ownership of its tooling stack. ##### **Limitations and Challenges** The power and flexibility of this model come at a significant cost in terms of complexity and effort. - **High Implementation Complexity:** This is not an out-of-the-box solution but a significant internal software engineering project. It requires deep, cross-functional expertise in Jenkins pipeline scripting (e.g., Groovy), advanced ArgoCD concepts (ApplicationSet generators), Kubernetes manifest management (Helm, Kustomize), and general automation scripting. Setting up the two-repo dance, the pipeline logic, and the generator templates is a non-trivial undertaking. - **Maintenance Overhead:** The platform engineering team that builds this custom system is also responsible for its ongoing maintenance, troubleshooting, and evolution. This includes managing Jenkins stability, updating ArgoCD, securing the pipelines, and adapting the system as new requirements emerge. - **“People Process” and Collaboration Hurdles:** The automation can introduce new human process challenges. As noted in one analysis, testing features from two different PRs together now requires developers to coordinate the creation and merging of their respective infrastructure PRs, which can be cumbersome. - **Complex Cleanup and Secrets Management:** While ArgoCD can prune the resources it knows about, ensuring a comprehensive cleanup of all associated artifacts (e.g., dynamically created databases, storage buckets, DNS records) requires custom logic to be built into the pipeline. Similarly, securely injecting secrets into dozens of dynamically created ephemeral environments is a complex security challenge that the team must solve from the ground up. Implementing preview environments using the ArgoCD and Jenkins model represents the “build” side of the classic “build vs. buy” dilemma for internal platform tooling. It consciously trades the convenience, polished user experience, and managed support of a commercial product for ultimate power, control, and customizability. The documented workflows are not simple tutorials but complex recipes demanding a high degree of DevOps maturity. The challenges that must be overcome, such as comprehensive cleanup, secrets management, and user-friendly collaboration flows, are precisely the problems that dedicated commercial tools are designed to solve out of the box. Therefore, embarking on this path is a strategic decision to invest significant and ongoing engineering resources into building a bespoke internal developer platform. This is a feasible and often desirable path for very large enterprise organizations that possess a mature and dedicated platform engineering function and have a strategic imperative to own and tailor their core developer tooling to their unique operational and governance needs. However, for most enterprise teams the costs of development and maintenance outweigh the benefits. #### **The Request-Level Isolation Model: Signadot** ##### **Core Philosophy: Share More, Copy Less** [Signadot](https://www.signadot.com/) introduces a paradigm that is a radical departure from the conventional wisdom of environment duplication. Its foundational principle is to “share more, copy less,” achieving robust isolation not by cloning infrastructure, but by intelligently routing individual application requests. The platform is engineered to provide preview environments that are exceptionally fast to create, highly cost-efficient, and immensely scalable. This approach is specifically designed to address the challenges of testing in complex microservice architectures, where duplicating the entire stack for every pull request is logistically impractical and financially prohibitive. ##### **Unique Architectural Deep Dive: Sandboxes, Service Forking, and Dynamic Routing** Signadot’s unique architecture is built upon three core concepts that work in concert to deliver on its philosophy. **Baseline Environment:** The system operates on the concept of a single, shared, long-lived “baseline” environment. This is typically an existing staging or QA Kubernetes cluster that is maintained in a state that closely mirrors production. This baseline serves as the stable foundation against which all changes are tested. **Sandboxes and Service Forking:** - When a developer requires a preview environment for their pull request, they do not clone the entire baseline. Instead, they create a logical, lightweight entity called a **“Sandbox”**. - A Sandbox definition specifies which services are being modified in the PR. For each of these services, the **Signadot Operator**, which is a controller running within the Kubernetes cluster, creates a **“forked workload”**. - This forked workload is a new Kubernetes Deployment of the modified service, running the new container image from the PR. Critically, all other unmodified services, databases, and dependencies within the baseline environment are **shared**, not copied. This “forking” action is the key to the model’s resource efficiency. **Dynamic Request Routing:** This is the technological heart of the Signadot model, enabling isolation on shared infrastructure. 1. To access a specific preview, a user or an automated test initiates a request with a special context. This context is typically carried in an HTTP header, such as baggage: sd-routing-key=. This header can be added manually with tools like curl, or more conveniently, injected automatically by the Signadot browser extension. 2. The Signadot Operator, running in the cluster, is responsible for intercepting network traffic between services. It can achieve this using its own lightweight DevMesh (which injects a sidecar proxy) or by [integrating with and controlling an existing service mesh like Istio or Linkerd](https://www.signadot.com/docs/concepts/architecture). 3. The Operator’s proxy inspects the header of each incoming request. If it detects a sd-routing-key that corresponds to an active Sandbox, it dynamically routes the request to the appropriate **forked workload** for that service. 4. If a request arrives without a sd-routing-key header, it is treated as normal traffic and is routed to the stable **baseline service**. 5. Most importantly, this routing context is **propagated** throughout the entire downstream call chain of the microservices application. When the forked service calls another service, the proxy ensures the sd-routing-key header is passed along. This ensures that the entire end-to-end request remains within the logical boundary of the Sandbox, creating a virtual “slice” of the application for that specific test, even though the underlying infrastructure is shared. ##### **Transformative Benefits and Strengths** This innovative architecture yields a set of powerful benefits that directly address the primary pain points of other models. - **Unmatched Resource Efficiency and Cost Savings:** This is the most profound advantage. Since only the services being actively changed are deployed, the marginal resource overhead per preview environment is minimal. This results in dramatic infrastructure cost savings, with claims of 85-90% reductions compared to full-duplication models. For an organization with hundreds of microservices, this difference translates into millions of dollars in annual savings. - **Blazing-Fast Environment Creation:** Sandboxes can be spun up in seconds. The system does not need to wait for dozens of services, databases, or other infrastructure to be provisioned and become ready. This provides developers with a near-instantaneous feedback loop, allowing them to preview their changes almost as soon as they push their code. - **High-Fidelity Testing:** Developers are able to test their changes against the actual shared dependencies, including databases, message queues, and third-party APIs, that the baseline environment uses. This is a significant step up in fidelity from testing against fresh, ephemeral, and often empty copies of these dependencies. It dramatically increases the likelihood of catching subtle, real-world integration issues that only manifest when interacting with long-running, stateful systems. - **Exceptional Scalability:** The request-level isolation model scales effortlessly. Because the marginal cost of each additional Sandbox is so low, the system can support hundreds of concurrent preview environments on a single baseline cluster without performance degradation or resource exhaustion. This is a critical capability for large engineering organizations. - **Advanced Cross-Team Collaboration:** Signadot allows multiple independent Sandboxes to be logically grouped together into “Route Groups.” This powerful feature enables developers from different teams to easily test the integration of their respective in-progress features together before any code is merged, [solving a common and difficult collaboration challenge in microservice development](https://www.signadot.com/solutions/preview-environments/). ##### **Limitations and Considerations** The power of Signadot’s model is predicated on certain architectural patterns and carries its own set of considerations. - **Context Propagation Requirement:** The model’s reliance on dynamic routing requires that the application’s services are instrumented to correctly propagate the routing context (i.e., the HTTP headers) from one service to the next. While this is a widely accepted best practice in modern microservice design and is natively supported by instrumentation frameworks like OpenTelemetry, it can pose an adoption barrier for legacy applications or those not built with this capability in mind. - **Stateful Service Complexity:** Testing changes that involve destructive database schema migrations or other stateful modifications requires careful planning in a shared-database model. While Signadot provides patterns to handle this, such as spinning up an ephemeral database as a “Resource” within the Sandbox for the duration of the test, it is a [more complex scenario](https://www.signadot.com/docs/concepts/architecture) than a simple stateless service change and must be designed for explicitly. - **Asynchronous Workflows:** Testing event-driven architectures that use message queues like Kafka or Google Pub/Sub is inherently more complex than synchronous request-response flows. It requires a more sophisticated pattern known as “selective consumption,” where consumer services within a Sandbox are configured to only process messages that contain the correct routing context in their metadata. Signadot supports this advanced use case, but it requires [specific instrumentation](https://www.signadot.com/docs/concepts/architecture) in the message producers and consumers. The architectural model pioneered by Signadot represents a genuine paradigm shift in pre-production testing. It moves the concept of isolation away from the infrastructure layer (copying compute, storage, and networking) and up to the application layer (slicing a shared system using request context). This is a fundamentally more resource-efficient and cloud-native approach that effectively decouples the cost and complexity of testing from the overall size and complexity of the application. The cost of a preview environment is no longer proportional to the total number of microservices in the system (N), but rather to the number of changed microservices in a given pull request (M), where M is almost always a small fraction of N. This economic and logistical reality makes Signadot’s model uniquely capable of supporting true, independent, high-velocity microservice development at a scale where full-duplication models would inevitably collapse under their own weight and cost. It is an enabling technology for large engineering organizations seeking to test every single change thoroughly without breaking their infrastructure budget. Preview every pull request in seconds Signadot creates request-level preview environments on your existing cluster, so you test only the services that changed against real dependencies. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### **Comparative Analysis and Strategic Framework** The selection of a preview environment tool is not merely a technical choice but a strategic one that reflects an organization’s scale, architecture, security posture, and DevOps maturity. The four approaches analyzed here (Okteto, vcluster, ArgoCD+Jenkins, and Signadot) represent distinct philosophies on how to solve the problem of pre-production testing. A direct comparison of their underlying architectures and the resulting trade-offs provides a clear framework for decision-making. ##### **The Spectrum of Isolation: A Head-to-Head Comparison** The most critical differentiator among these tools is their chosen method of isolation. This architectural decision dictates nearly every other characteristic of the solution, from cost and speed to fidelity and complexity. Understanding this spectrum is paramount for any technical evaluation. Feature Okteto (Namespace Duplication) vCluster (Virtual Cluster) ArgoCD + Jenkins (Namespace Duplication) Signadot (Request Routing) Isolation boundary Kubernetes namespace Kubernetes API server (virtual control plane) Kubernetes namespace Application request context (e.g., HTTP header) Core primitive okteto deploy into a new namespace vcluster create to spin up a virtual control plane ArgoCD ApplicationSet with Pull Request Generator Signadot Sandbox creation, which triggers service forking Resource granularity Full stack replica: all services, databases, and dependencies are duplicated per PR Full stack replica within a virtual cluster; the control plane itself is additional overhead Full stack replica: all services and dependencies defined in manifests are duplicated per PR Partial replica: only modified services are forked, while all other baseline services and dependencies are shared Control plane Shared: all preview environments run under the same host Kubernetes control plane Isolated: each preview environment has its own dedicated, virtualized control plane Shared: all preview environments run under the same host Kubernetes control plane Shared: all Sandboxes operate on a single baseline environment with a shared control plane Network isolation Strong: provided by Kubernetes NetworkPolicy within the dedicated namespace Strongest: full network virtualization within the vcluster, plus host-level NetworkPolicy Strong: provided by Kubernetes NetworkPolicy within the dedicated namespace Logical: isolation is enforced by routing rules in the service mesh or proxy layer, and workloads share the same network fabric This architectural comparison reveals a clear progression. The Okteto and ArgoCD models provide workload isolation at the namespace level. vCluster elevates this to provide control plane isolation, creating a much stronger security and administrative boundary. Signadot takes a completely different axis, providing logical isolation at the request level, which allows it to forgo infrastructure duplication almost entirely. ##### **Decision Vector Analysis** Moving beyond the core architecture, a comparison across key business and technical vectors helps to contextualize the trade-offs for different organizational priorities. **Resource Efficiency & Total Cost of Ownership (TCO):** - **Okteto / ArgoCD:** These models exhibit linear cost scaling. The total cost is a function of the number of services multiplied by the number of active PRs (Cost∝N×P). This results in the highest TCO at scale and [can quickly become financially unsustainable](https://www.signadot.com/comparison/okteto/). - **vCluster:** This model has a sub-linear cost profile. It is significantly cheaper than provisioning physical clusters but still incurs a fixed resource overhead for each virtual control plane per PR. Its TCO is lower than full duplication but higher than shared models. - **Signadot:** This model offers a near-constant, low-cost profile. The cost scales only with the number of changed services, not the total number of services (Cost∝M×P, where M≪N). This results in the lowest TCO, especially for complex applications, making it the most economically efficient model at scale. **Developer Experience (DevEx) & Speed:** - **Okteto:** Offers an excellent inner-loop DevEx with its rapid code synchronization feature. However, the initial environment spin-up time can be slow for complex applications, creating a delay before the preview is available. - **Signadot:** Delivers the fastest environment creation time, with Sandboxes spinning up in seconds. This provides a near-instantaneous feedback loop from code push to a shareable preview URL. - **vCluster:** vCluster creation itself is very fast (seconds), but the overall time to a ready preview environment depends on the application deployment time within the vCluster. - **ArgoCD + Jenkins:** This model generally has the slowest feedback loop. The multi-step process (CI build, push image, open infrastructure PR, ArgoCD detection, sync) introduces multiple points of latency. **Scalability & Performance:** - **Okteto / ArgoCD:** These models scale poorly. As the number of namespaces and pods in the cluster explodes, it can lead to performance degradation of the Kubernetes control plane and scheduler, and significant resource fragmentation. - **vCluster:** This model scales well, as it is explicitly designed for multi-tenancy. It effectively partitions the API load, distributing it across the virtual control planes. - **Signadot:** Exhibits excellent scalability. The architecture is designed to support hundreds of concurrent Sandboxes on a single baseline cluster with minimal performance impact, as the resource footprint of each preview is very small. **Operational Complexity & Implementation Effort:** - **ArgoCD + Jenkins:** Highest complexity. This is a full-fledged DIY engineering project requiring significant, ongoing investment in building and maintaining the custom automation. - **vCluster:** Medium complexity. It requires the setup and management of vCluster templates, host cluster ingress controllers, and potentially complex networking rules for communication between the host and virtual clusters. - **Signadot:** Low complexity. The control plane is managed by Signadot. The implementation requires installing an operator in the cluster and instrumenting applications for context propagation, which is a one-time effort per service. - **Okteto:** Lowest complexity. As a fully managed platform, it offers the most straightforward, out-of-the-box setup experience. **Test Fidelity & Reliability:** - **Signadot:** Offers the highest fidelity. Tests are executed against a stable, shared, production-like baseline environment, including real, long-running stateful services like databases and message queues. This provides the most realistic assessment of how a change will behave in production. - **Okteto / ArgoCD / vCluster:** Provide high fidelity in terms of the application code and its direct dependencies being deployed together. However, stateful dependencies like databases are typically fresh, ephemeral copies for each PR. This approach may miss subtle bugs related to data state, schema evolution, or interactions with other long-running services. The challenge of seeding these ephemeral databases with realistic data is significant and often overlooked. The analysis of these decision vectors reveals that there is no universally “best” tool. Instead, there is a “right” tool for a given set of organizational circumstances. The choice is a strategic one that involves weighing the trade-offs between developer autonomy, cost, security, and implementation effort. A small startup with a simple application and a focus on rapid iteration has vastly different needs and constraints than a large, regulated enterprise with a complex, 200-service mesh and a dedicated platform engineering team. The optimal choice depends entirely on which of these vectors the organization prioritizes most. #### **Summary and Strategic Recommendations** The transition from static staging environments to dynamic, on-demand preview environments is a critical step in modernizing the software delivery lifecycle. The choice of tooling for this transition has profound implications for an organization’s agility, cost structure, and developer productivity. The analysis of Signadot, Okteto, vCluster, and the GitOps-native ArgoCD+Jenkins approach reveals four distinct architectural philosophies, each with a unique profile of strengths and weaknesses. ##### **Comprehensive Tool Comparison Summary** The following table synthesizes the findings of the report, providing a high-level, comparative summary to aid in strategic decision-making. Criteria Signadot Okteto vCluster ArgoCD + Jenkins Isolation model Request-level routing: isolates traffic via context propagation on a shared baseline environment Full namespace duplication: creates a complete, isolated replica of the entire application stack per PR Virtual cluster: provides a fully virtualized, isolated Kubernetes control plane and namespace per PR Full namespace duplication: creates a complete replica of the application stack per PR, orchestrated via GitOps Primary use case High-fidelity, scalable testing for complex microservice architectures Maximizing individual developer experience and providing a seamless local-to-cloud workflow Secure multi-tenancy and testing of cluster-level changes (e.g., Operators, CRDs) Building a highly customized, fully owned preview environment system with maximum control and auditability Cost profile Very low: scales with the number of changed services, the most resource-efficient model High: scales linearly with the total number of services and active PRs, can become very expensive Medium: cheaper than physical clusters but has a fixed resource overhead per virtual control plane High: same linear scaling as Okteto, plus significant engineering and maintenance labor costs Environment speed Very fast: spins up in seconds, providing near-instantaneous previews Variable: fast inner-loop sync, but initial environment provisioning can be slow for large applications Fast: vcluster creation is very fast, but total time depends on application deployment Slowest: the multi-step, multi-repository workflow introduces significant latency Scalability Excellent: designed to support hundreds of concurrent environments on a single cluster Poor: resource explosion and control plane load limit scalability Good: designed for multi-tenancy and can scale to many virtual clusters Poor: suffers from the same resource explosion and scalability limits as the Okteto model Implementation effort Low: managed control plane, requires Operator installation and application instrumentation Very low: fully managed platform offering the simplest out-of-the-box experience Medium: requires configuration of templates, host and guest networking, and ingress syncing Very high: a significant, bespoke platform engineering project requiring deep expertise to build and maintain Best for Large-scale engineering orgs with complex microservices where cost, speed, and test fidelity are key Small to medium-sized teams prioritizing developer simplicity and autonomy over infrastructure cost Organizations with high security needs or those testing infrastructure-level changes alongside applications Mature organizations with a dedicated platform team, a build-over-buy philosophy, and a need for ultimate customization ##### **Which Preview Environment Platform Is Best?** The optimal choice of tool is contingent on an organization’s specific context. The following recommendations provide a strategic framework for this decision: - **Choose Okteto if…** your organization’s primary objective is to maximize individual developer productivity for a small-to-medium-sized team. It is the ideal choice when the application is of moderate complexity and the organization is willing to tolerate a higher infrastructure cost in exchange for unparalleled simplicity, a superior inner-loop development experience, and the conceptual ease of complete environment isolation. - **Choose vCluster if…** your organization operates under stringent security, compliance, or multi-tenancy requirements. It is the superior solution when pull requests frequently involve changes that extend beyond the application layer to include cluster-level resources like Operators, CRDs, or complex network policies. It is the right choice for providing developers with “self-service” Kubernetes clusters that are strongly isolated from each other and the host infrastructure. - **Choose the ArgoCD + Jenkins approach if…** your organization possesses a mature and well-resourced platform engineering team, fosters a strong “build-over-buy” culture, and requires ultimate control and customizability over its CI/CD and preview workflows. This path is for those who see their developer platform as a strategic, proprietary asset and have the long-term commitment to build and maintain a bespoke system. - **Choose Signadot if…** your organization operates a complex, distributed microservices architecture where cost efficiency, scalability, and speed are critical business drivers. It is the forward-looking choice for high-velocity engineering teams that need to enable high-fidelity testing against real, stateful dependencies for every pull request. Signadot is the only model presented that makes this practice economically and logistically viable at the scale of hundreds of microservices, where traditional environment duplication is not a sustainable long-term strategy. ##### **Concluding Remarks: The Future of Pre-Production Testing** The industry’s trajectory is clear: the era of the slow, contentious, and monolithic staging environment is drawing to a close. The future of pre-production testing lies in dynamic, on-demand, and automated environments that are deeply integrated into the developer workflow. The evolution from simple duplication models to more sophisticated virtualization and request-level isolation techniques marks a significant advancement in the field. As organizations continue to embrace microservices and seek to accelerate their release cycles, the adoption of a robust preview environment strategy will cease to be a competitive advantage and will become a fundamental prerequisite for building and shipping high-quality software at speed and scale. Try request-level preview environments free Spin up isolated, production-like preview environments for every PR on the cluster you already run. No stack duplication, no staging queue. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions What is a preview environment? A preview environment is an on-demand, isolated, ephemeral deployment created automatically for a branch or pull request. Reviewers get a shareable URL to interact with the change before it merges, and the environment is destroyed when the PR closes. What is the difference between a preview environment and staging? Staging is one long-lived environment shared by every team, so changes queue behind each other and failures are hard to attribute. Preview environments give each pull request its own isolated environment, so reviews and tests run in parallel without interference. How do preview environments work in Kubernetes? Four approaches dominate: duplicating the full stack in a namespace per PR, giving each PR a virtual cluster, building a GitOps pipeline with tools like ArgoCD, or request-level isolation on a shared baseline cluster where only the changed services are deployed. What is the best preview environment platform? It depends on scale and needs. Okteto suits small teams that want full copies and simplicity, vCluster suits changes that touch operators or CRDs, ArgoCD with Jenkins suits platform teams that want to build their own, and Signadot's request-level isolation suits teams that need speed, low cost, and high fidelity at hundreds of services. How do you get a preview environment for every pull request in a microservices app? Wire environment creation into CI so that opening a PR builds the changed services and creates an isolated environment automatically. With request-level isolation, that environment is a sandbox containing only the changed services on a shared baseline cluster, and the platform returns a preview URL whose requests are routed through the sandboxed versions. The PR gets a live, clickable preview in seconds rather than the minutes a full-stack copy takes. How much do preview environments cost at scale? Full duplication scales cost with the number of services times the number of open PRs, which is what makes it prohibitive for large teams. Request-level isolation deploys only the changed services per preview, so hundreds of concurrent previews fit on one shared cluster. Teams switching from duplication report 85 to 90 percent lower preview-infrastructure cost, and Brex saves about $2 million annually with this model. Do preview environments work for monorepos with many services? Yes, and monorepos are where request-level isolation shines. Each PR's sandbox forks only the services that the change actually touches, so a monorepo with dozens of services still gets one lightweight preview per PR, without rebuilding or redeploying the untouched services. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: Preview Environments for QA and Stakeholder Review* preview-environments ##### Preview Environments for QA and Stakeholder Review August 5, 2026 *Image: Per-PR Preview URLs, Explained* preview-environments ##### Per-PR Preview URLs, Explained July 21, 2026 *Image: ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains* preview-environments ##### ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains July 24, 2026 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Per-PR Preview URLs, Explained Source: https://www.signadot.com/articles/per-pr-preview-urls/ Summary: Why preview URLs are nearly free for frontends and hard for backends, and the two architectures for giving every pull request its own link: environment duplication and header-based routing on a shared cluster. ### Per-PR Preview URLs, Explained Author Arjun Iyer Published July 21, 2026 **A per-PR preview URL** is a link, posted on the pull request, that opens a running version of the application with that change included. Anyone with the link can try the feature before it merges, without pulling a branch or building anything. Frontend platforms made this a default expectation, and the question most teams face is how to get the same experience for services running on Kubernetes. The short answer is that the URL is the visible end of an environment strategy. For a frontend, the environment is a self-contained build artifact, so a URL per PR is nearly free. For a backend service, the PR’s code is one node in a graph of services and datastores, so the URL has to lead to a place where that whole graph exists. The approaches below differ mainly in how they produce that place. #### The frontend version everyone knows [Vercel](https://vercel.com/docs/deployments/environments) and [Netlify](https://docs.netlify.com/site-deploys/deploy-previews/) build every pull request and comment a unique link on it, using URL schemes like a per-PR subdomain. The pattern works because the deliverable is a static or serverless bundle. Each build is complete in itself, hosting is a content delivery network (CDN) push, and a thousand previews cost little more than one. That mental model is what most searchers arrive with. It sets the right expectation for the workflow, a link on every PR that product managers and designers can click, and the wrong expectation for the mechanics once real backends are involved. #### Why the same idea is harder for a backend A backend pull request has nothing to show by itself. To render a page or serve an API response, the changed service needs its upstream callers, its downstream dependencies, a database with plausible data, and often a message queue. The unit that must exist behind the preview URL is the system, not the artifact. Frontend previewPull requestBuild artifactCDNOne URL per PRBackend previewPull requestService graphChanged serviceServiceQueueDatabaseOne URL, full graph A frontend preview points at one artifact. A backend preview has to point at a whole graph of services. Frontend previewPull requestBuild artifactCDNOne URL per PRBackend previewPull requestService graphChanged serviceServiceQueueDatabaseOne URL, full graph A frontend preview points at one artifact. A backend preview has to point at a whole graph of services. That leaves two basic strategies. Either you stand up a copy of the system for every pull request, or you share one live system and arrange for the PR’s requests to hit the changed service. Everything else in this article is a variation on those two moves. #### Two ways to give a pull request its own URL Environment per PRpr-123.preview.example.comNew namespaceFull stack copyHeader-based routingX-Preview-Key: pr-123Shared clusteronly changed services deployed Duplicate the whole stack per PR, or deploy only the changed services and route requests to them, virtualizing the full stack for the preview. Environment per PRpr-123.preview.example.comNew namespaceFull stack copyHeader-based routingX-Preview-Key: pr-123Shared clusteronly changed services deployed Duplicate the whole stack per PR, or deploy only the changed services and route requests to them, virtualizing the full stack for the preview. ##### A full environment per PR, one subdomain each CI or a GitOps controller deploys the entire stack into a namespace per pull request, and a wildcard Domain Name System (DNS) record plus an ingress rule map `pr-123.preview.example.com` to it. Tools like [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) automate the records. This is the backend equivalent of the frontend pattern. [Okteto](https://www.okteto.com/preview-environments/) and [Release](https://release.com/ephemeral-environments) sell managed versions of it, and the [Argo CD ApplicationSet pattern](https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/applicationset/Generators-Pull-Request.md) is the common way teams build it themselves. It is conceptually clean because each preview is fully self-contained. Nothing is shared, so there are no routing rules to reason about, no header propagation to verify, and no way for one preview to interfere with another. Debugging an environment means looking at one namespace. But it gets expensive in proportion to system size and PR volume, since every open PR carries a full copy of every service, sitting mostly idle. Twenty open PRs against a thirty-service stack means six hundred running containers before anyone clicks a link. Each of those environments is also something the platform team operates: seeding its data, keeping its config current, and answering for it when a preview comes up broken. Spin-up time grows with the stack too, since the preview is not ready until the slowest service and its data are, and once previews take minutes to build, teams start rationing them to the risky changes, which quietly defeats the point of a preview on every PR. ##### Header-based routing on a shared cluster The alternative keeps one stable environment running and deploys only the services a PR changed, whether that is one service or several, as isolated versions alongside their stable counterparts. Requests that carry the PR’s routing key in a header are routed to the changed services at each hop, and fall through to the stable versions of everything else. One link virtualizes the full stack for that PR without deploying it. The preview URL is a hosted address that injects the routing key on every request, so clicking the link is all a reviewer does differently. This is the architecture behind Signadot’s Sandboxes, lightweight ephemeral environments that hold the changed service inside the shared cluster. Each Sandbox endpoint gets a hosted preview URL that injects the routing key automatically and authenticates through the control plane, so reviewers signed into the dashboard open it in a browser while automation uses an API key (see the [preview URL reference](https://www.signadot.com/docs/reference/sandboxes/preview-urls)). The biggest win is developer experience. A preview is ready as soon as one container starts, in seconds, and that stays true whether the stack has five services or three hundred, because nothing else needs to be deployed. Every preview also exercises the real, current versions of every dependency rather than a copy that may have drifted. Fast, dependable links are what keep reviewers and product managers clicking on every PR instead of saving previews for the risky changes. The operational and cost profile follows from the same property. The platform team keeps one baseline environment in sync with the main branch instead of operating a fleet of full copies, each needing data seeding, config updates, and an on-call answer when it comes up broken. And each preview costs one service instance rather than one system copy; this [walkthrough of cost-efficient preview environments](https://www.signadot.com/blog/create-cost-efficient-preview-environments-in-kubernetes-with-signadot/) shows how that changes the bill in detail. The prerequisite is that services propagate request headers across hops, which teams with distributed tracing already do. The same preview URLs verify behavior for web and mobile applications alike, including [mobile and frontend previews](https://www.signadot.com/blog/mobile-frontend-preview-with-signadot-sandboxes/) driven by backend changes. They also pair with frontend platforms, shown in this [Vercel plus Kubernetes preview tutorial](https://www.signadot.com/blog/tutorial-end-to-end-hot-reload-style-previews-with-vercel-signadot/). A preview URL on every PR, without duplicating the stack Signadot gives each pull request a hosted preview URL backed by a lightweight sandbox on your shared cluster, so reviewers click a link and see the change running against real dependencies. The free tier is open to every developer. [Start for free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Access, data, and cleanup The people a preview URL is for usually cannot run kubectl, so access has to work at the browser level. The common answers: - single sign-on in front of the preview domain - short-lived tokenized links - network placement behind the corporate virtual private network (VPN) Managed platforms handle this at their control plane, authenticating the hosted preview URL against the user’s existing session. Whichever you choose, the test is whether a product manager can open the link from the PR with zero setup. Data matters as much as access. A preview backed by an empty database demos nothing, so environments either share the stable system’s data through the routing approach, or seed fixtures on creation in the duplication approach. Shared data with isolated writes is its own topic, and the [preview environments guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) covers the options in depth. Cleanup is the part teams forget until it shows up on the cluster bill. Preview environments should tear down when the PR merges or closes, with a time-to-live backstop for anything that leaks. In the routing model, cleanup is deleting the ephemeral environment. In the duplication model, it is deleting a namespace and its volumes. #### Wiring the URL into the pull request The URL only changes behavior if nobody has to go looking for it. The standard wiring is a CI step that creates the preview and comments the link on the pull request, GitHub Actions and GitLab CI both make this a few lines, and many teams also post it to the ticket and the team channel. Some add a commit status or check run that links to the preview, so the URL sits in the merge box itself. Two small details pay off: - Pin the comment, or edit one comment in place per PR, so reviewers are not scrolling past a stack of stale links after every push. - Include the environment’s state in the comment, creating, ready, or failed, because a link that 502s for the first three minutes teaches stakeholders not to click. #### The lifecycle, end to end Step by step: 1. A developer opens a pull request. 2. CI builds the image and creates the preview, a full environment copy or a routed ephemeral environment. 3. A bot comments the URL on the PR, within seconds to minutes depending on the approach. 4. The reviewer clicks the link to sanity-check behavior, QA runs through the change in isolation, and the product manager confirms it matches intent, all before merge. 5. New commits update the same preview, so the URL never goes stale. 6. On merge, the environment is torn down automatically, with nothing left to clean up by hand. Reviewers are not always human. Coding agents can open the same preview to run end-to-end tests against the change before anyone looks at it, which makes the preview URL the validation surface for agent-written code as much as for human review. The preview lifecycle1PR opened2CI createspreview3Bot commentsURL4Team clickslink5Fix updatesURL6PR mergesenv removed The URL is created once, stays valid through every push, and disappears when the PR closes. The preview lifecycle1PR opened2CI creates the preview3Bot comments the URL4Reviewer, QA, PM click it5Fix updates the URL6PR merges, env removed The URL is created once, stays valid through every push, and disappears when the PR closes. #### Choosing between the approaches The choice is really about a tipping point. A team with a small stack and moderate PR volume has no bottleneck to fix. A namespace per PR is the simpler approach, cost and spin-up time are tolerable at that scale, and the whole mechanism stays easy to reason about. There is no reason to add a routing layer before the economics demand one. The calculus changes as the team and the service graph grow. When spin-up time gets long enough that stakeholders stop clicking, when the platform team spends its weeks keeping preview copies alive instead of improving the platform, or when the preview bill becomes a line item that needs explaining, duplication has hit its ceiling. At that point header-based routing stops being an optimization and becomes the requirement for PR previews to keep scaling: previews stay seconds from ready and at the cost of the changed services, no matter how large the stack grows or how many PRs are open. Both deliver the thing that changes how teams review, a URL on every pull request that anyone can click, and the [preview environments solution page](https://www.signadot.com/solutions/preview-environments/) covers what the managed version of that workflow looks like. #### Frequently asked questions What is a per-PR preview URL? A per-PR preview URL is a link, posted on the pull request, that opens a running version of the application with that change included. Anyone with the link, a reviewer, QA, or a product manager, can try the change before it merges without pulling a branch or building anything locally. Why are preview URLs harder for backend services than for frontends? A frontend preview deploys one self-contained build artifact to a CDN, so a URL per PR is nearly free. A backend change has nothing to show by itself: it needs its upstream callers, downstream dependencies, a database with plausible data, and often a message queue. The preview URL has to lead to a full working system, not a single artifact. What are the two ways to give a pull request its own preview URL? Either duplicate the environment per PR, deploying the full stack into its own namespace behind a per-PR subdomain, or keep one shared baseline environment, deploy only the changed services, and route requests carrying the PR's routing key to them at each hop. Duplication is simpler at small scale; header-based routing keeps previews ready in seconds, spares the platform team from operating a fleet of environment copies, and keeps cost flat as the stack and PR volume grow. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains* preview-environments ##### ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains July 24, 2026 *Image: What Are Preview Environments? The Complete Kubernetes Guide* preview-environments ##### What Are Preview Environments? The Complete Kubernetes Guide July 31, 2025 *Image: Preview Environments for QA and Stakeholder Review* preview-environments ##### Preview Environments for QA and Stakeholder Review August 5, 2026 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Cut the Cost of Kubernetes Preview Environments with Signadot Source: https://www.signadot.com/blog/create-cost-efficient-preview-environments-in-kubernetes-with-signadot/ Summary: Why per-PR preview environments get expensive with full duplication and how request-level isolation keeps the cost of hundreds of concurrent previews close to flat. ### Cut the Cost of Kubernetes Preview Environments with Signadot Preview environments do not have to cost a full environment copy per pull request. This tutorial shows how to cut preview costs in Kubernetes by forking only the microservices a change touches into a lightweight sandbox and sharing the rest of the cluster, with a step-by-step setup using Signadot and the HotROD demo app. Reading time 8 min Author Muhammad Khabbab Published October 2, 2024 Updated August 31, 2026 Topics [Tutorials/Guides](https://www.signadot.com/blog/category/tutorials-guides/), [Ephemeral Environments](https://www.signadot.com/blog/category/ephemeral-environments/) _Featured image by Gustavo Quepón on Unsplash._ #### Introduction How can development teams ensure efficient testing in a microservices world without incurring high resource costs? [Preview environments](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) are crucial for catching bugs early, but setting them up can be complex and expensive. Signadot tackles these challenges by providing a Kubernetes-native solution that creates scalable, lightweight sandboxes. Now developers can fork only the necessary microservices instead of replicating the whole tech stack. The result is optimized resources with high-quality testing in a real-world environment. Let’s dive into how Signadot simplifies the microservices testing workflow followed by a step-by-step guide to create a preview sandbox for microservices testing.  #### Signadot’s Approach and Its Benefits Unlike traditional testing methods that require replicating the entire cluster, Signadot’s approach isolates only the relevant microservices for testing. The diagram below illustrates how this isolation is achieved by routing requests through the main environment to the sandboxed microservices.  *Image: Diagram showing the Signadot operator routing requests with sd-routing-key baggage headers from the baseline environment to sandboxed services* This lightweight approach provides several key benefits, some of which are outlined below: ##### Key Features and Benefits **Lightweight Sandboxes:** - **Forking only necessary microservices:** Signadot allows you to create sandboxes by forking only the specific microservices that need to be tested. This not only reduces resource usage but improves performance as well. - **Connection to shared baseline:** Sandboxes connect to a shared baseline environment to provide access to common infrastructure and dependencies without duplicating them. **Improved Developer Experience:** - **Rapid environment creation:** As developers can spin up new environments in seconds, your development and testing cycles are accelerated.  - **Simplified workflows:** Reproducing bugs and testing in isolation is simplified with Signadot. Using its browser extension, developers can set headers and reuse existing URLs to streamline testing and reduce overhead. **Cost-Efficiency and Scalability:** - **Reduced resource consumption:** Signadot utilizes a shared baseline environment that minimizes the resources required for each preview. By forking only the necessary microservices, it avoids the overhead of creating and maintaining multiple full-stack environments. - **Supports large teams and complex architectures:** The platform efficiently manages multiple concurrent previews without performance degradation and can handle the demands of large development teams and complex microservices architectures. **Early Issue Detection:** - **Thorough code testing:** Signadot enables developers to test code changes thoroughly in isolated environments before merging them into the main codebase. - **Decreased likelihood of production bugs:** By identifying and addressing issues early in the development process, Signadot helps reduce the risk of production bugs. #### Step-by-Step Guide to Setting Up Preview Environments with Signadot ##### Step 1 - Prerequisites and Setup **Pre-requisites** 1. A Kubernetes cluster provisioned through minikube, K3, MicroK8s, etc. For this example, it will be a local minikube cluster.  2. [_Kubectl_](https://kubernetes.io/docs/tasks/tools/) needs to be installed.  3. [_Helm_](https://helm.sh/docs/intro/install/) should be installed too.  **Setup** 1. Create an account on signadot.com. You should have access to your Signadot dashboard from where you can create API keys, create cluster, manage sandboxes, and many more.  2. Create a cluster through the Signadot dashboard and create a cluster token. The Signadot cluster (from the dashboard) is a logical representation in the Signadot platform that allows it to connect and manage your local cluster (Minikube) using the cluster token. 3. Install [Signadot cluster operator](https://www.signadot.com/docs/installation/signadot-operator). This Kubernetes operator will be installed on your local Minikube cluster. It will enable management and coordination between your Minikube cluster and the Signadot platform. Upon successful installation of the operator, you will see the below message on your terminal.  On the Signadot dashboard, you will see the status of your Signadot cluster as ready, see the below screenshot for reference: *Image: Signadot dashboard cluster details showing the testcluster with operator version 0.18.0 in Ready state* This shows that the Signadot Operator on your local cluster has successfully authenticated with the Signadot platform using the cluster token. ##### Step 2: Deploying the Baseline Environment Deploy a baseline environment in your cluster. For this article, we will use the Hotrod application [https://github.com/signadot/hotrod](https://github.com/signadot/hotrod) as the baseline. See below commands to install the application.  The above commands deploy the Hotrod demo application into the _Hotrod_ namespace in your local Minikube cluster. After running the above commands, you will see the output below: Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) ##### Step 3: Installing and Configuring Signadot CLI 1. Install and configure the [Signadot CLI](https://www.signadot.com/docs/getting-started/installation/signadot-cli). It will be used to establish a connection with the local cluster so that you can access the Hotrod frontend application from your local machine. The Signadot CLI config is located at _$HOME/.signadot/config.yaml_. Make sure to configure it with the appropriate values. Below is a sample config file for the ongoing example: 2. Let’s use the Signadot CLI to connect to your local cluster, as well as start testing local changes using Sandboxes. See the below command “_signadot local connect_” and its result. The above command provided direct access to services running on the local Minikube cluster by configuring _/etc/hosts_ and routing traffic. As a result, you can access the services (API, front end, etc.) accessible via localhost on your machine. In the next step, we will test the front end of the Hotrod application.  3. You should be able to access the front end using the URL [http://frontend.hotrod.svc:8080](http://frontend.hotrod.svc:8080/). If you can see the Hotrod application, then everything worked fine so far and we are one step away from creating our first sandbox (preview environment).  *Image: HotROD demo app frontend in the baseline environment showing a ride request where the driver arrives in a negative ETA* Notice the ETA value coming as negative, which is a bug intentionally introduced in this baseline environment. We will discuss this in next section where we will create a sandbox to test its fix. ##### Step 4: Creating and Testing a Signadot Sandbox The Hotrod application consists of 4 services: _frontend_, _location_, _driver_, and _route_. We already noticed a bug in the “route” service that we want to fix and test through sandbox. We will deploy the docker image of that fix in a docker registry (in this case, Dockerhub) and reference this image in the sandbox configuration file. We can either create the sandbox through the Signadot dashboard or CLI. In both cases, the sandbox configuration file will be the key. Here are the details of the configuration file.  **Example Configuration for Forking a Deployment** We will continue with the example of Hotrod application and create a sandbox _negative-eta-fix_ as an example. In the baseline environment, when you book a ride, the ETA shows negative, which is a bug. We have tagged its fix as _signadot/hotrod:quickstart-v3-fix._ Below is the sandbox configuration for _negative-eta-fix_ sandbox\_.\_ You can just place this configuration in the Signadot dashboard when creating a sandbox and apply it. The sandbox containing the fix will be deployed immediately. See the below screenshot for reference.  *Image: Signadot dashboard confirming the negative-eta-fix sandbox was created and applied, with the sandbox YAML spec forking the route deployment* You can achieve the same through CLI. Just run the below command providing the path to the sandbox configuration file and specifying the Signadot cluster name.  The terminal will display the status of sandbox creation as below: You will see the status of the sandbox as “Ready” in the Signadot dashboard as well. At this stage, we have two versions of the “route” service. The buggy one in the baseline environment, and the fixed one in the sandbox. So how to divert traffic to the sandbox one? The answer lies in the last step which is about routing the request.  ##### Step 5: Routing to the Sandbox The Signadot operator is responsible for routing the request to the sandbox instead of the baseline version of “route” service but it needs the routing key for this purpose. To implement this, pass the header _baggage: sd-routing-key=_ in your requests, and the Signadot Operator will redirect traffic to the sandboxed service instead of the baseline. For this example, we will be using [Chrome extension](https://chromewebstore.google.com/detail/signadot/aigejiccjejdeiikegdjlofgcjhhnkim) for Signadot although we can use any extension that allows setting a header. See the below screenshot of the Signadot Chrome extension setting the header.  You will see a list of all the sandboxes that are created. We will select the _negative-eta-fix_ sandbox here.  *Image: Signadot Chrome extension over the HotROD app listing the negative-eta-fix sandbox to route requests to* Now that the routing is set, we will reload the Hotrod application on same URL and we can see the ETA is now positive.  *Image: HotROD app with requests routed to the negative-eta-fix sandbox, showing the route service handling the request and the driver arriving in a positive ETA* After completion of sandbox testing, you can either delete it from Signadot dashboard or through the below command: #### Conclusion With Signadot, creating efficient and scalable [preview environments in Kubernetes](https://www.signadot.com/solutions/preview-environments/) has never been easier. Its ability to isolate specific microservices in lightweight sandboxes reduces resource usage, increases productivity, and improves code quality. By incorporating Signadot into your development workflow, you can accelerate testing and release cycles while minimizing costs at the same time. Why not try [Signadot](https://www.signadot.com/) and transform the way your team builds and tests microservices? Explore how companies like [Brex](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) and [DoorDash](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/) have scaled their testing and improved productivity with Signadot. #### Related Posts *Image: Guide to Testing SQS-Based Microservices with Signadot Sandboxes* ephemeral-environments tutorials-guides ##### Guide to Testing SQS-Based Microservices with Signadot Sandboxes September 5, 2025 *Image: Federated GraphQL Schema Testing in CI/CD with WunderGraph and Sandboxes* ephemeral-environments tutorials-guides ##### Federated GraphQL Schema Testing in CI/CD with WunderGraph and Sandboxes September 19, 2025 *Image: How to Migrate from Telepresence to Signadot: A Technical Guide* ephemeral-environments tutorials-guides ##### How to Migrate from Telepresence to Signadot: A Technical Guide August 27, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## ArgoCD Preview Environments: The ApplicationSet Pattern Source: https://www.signadot.com/articles/argocd-preview-environments/ Summary: How Argo CD's ApplicationSet pull request generator stamps out a preview per PR, where duplication strains as stacks and PR volume grow, and when request routing on a shared cluster fits better. ### ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains Author Arjun Iyer Published July 24, 2026 **ArgoCD preview environments** give every open pull request its own running copy of the application. The standard way to build them is an ApplicationSet with the pull request generator: it watches your repository and stamps out a full [Argo CD](https://argoproj.github.io/cd/) Application for every open PR, deployed into its own namespace and exposed at its own URL. The pattern is GitOps-native, widely used, and worth understanding in detail, including the points where it starts to strain. This article walks through the mechanics first, then the failure modes, then the alternative architecture, request routing on a shared cluster, for teams whose service count or PR volume has outgrown per-PR duplication. #### The pattern: one Application per open pull request The [pull request generator](https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/applicationset/Generators-Pull-Request.md) polls your source control provider and produces one set of template parameters per open PR: the PR number, the branch, and the head commit SHA. The ApplicationSet controller renders an Application from each, and Argo CD deploys it like any other. GitHub and GitLab are the common providers, with GitLab configuration keyed by project rather than owner and repository, and label filters let you gate previews to PRs that opt in with a preview label. Configure webhooks early. The generator’s default is polling on an interval, which means a preview can lag a pushed commit by minutes. Source control webhooks trigger the ApplicationSet on push, so previews create and update within seconds of the commit. ReviewerPull requestApplicationSetcontrollerApplicationpreview-123Namespacepr-123full stackpreview URLAuto-pruned on PR close Each open PR gets its own Application, namespace, and preview URL, all removed when the PR closes. Pull requestApplicationSetcontrollerApplicationpreview-123Namespacepr-123full stackpreview URLReviewerAuto-prunedon PR close Each open PR gets its own Application, namespace, and preview URL, all removed when the PR closes. A trimmed example shows the moving parts: ``` apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: pr-previews spec: generators: - pullRequest: github: owner: your-org repo: your-service # tokenRef is required for private repos. Anonymous access # only sees public repos and has a lower rate limit. requeueAfterSeconds: 120 template: metadata: name: preview-{{number}} spec: project: default source: repoURL: https://github.com/your-org/your-service targetRevision: "{{head_sha}}" path: deploy/chart helm: parameters: - name: image.tag value: "{{head_sha}}" - name: ingress.host value: pr-{{number}}.preview.example.com destination: namespace: pr-{{number}} server: https://kubernetes.default.svc syncPolicy: automated: prune: true syncOptions: - CreateNamespace=true ``` ##### Per-PR namespaces and Helm overrides Each Application targets a namespace derived from the PR number, so environments cannot collide. [Helm](https://helm.sh/) value overrides do the per-PR specialization: the image tag pins to the head SHA, the ingress hostname embeds the PR number, and resource requests and replica counts shrink to preview scale. Teams on Kustomize do the same with per-PR overlays. ##### DNS, ingress, and the preview URL A wildcard DNS record for `*.preview.example.com` points at the cluster’s ingress, and each preview’s ingress rule claims its own hostname. [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) can manage the records automatically, and a wildcard TLS certificate keeps the URLs presentable to stakeholders. The result is the per-PR link that gets posted back to the pull request by CI. ##### Cleanup When a PR closes or merges, the generator stops emitting its parameters, the controller deletes the Application, and automated pruning removes the namespace. Two backstops are worth adding: a time-to-live sweep for environments that leak past the prune, and explicit handling for persistent volume claims, which otherwise outlive the namespace’s intent and keep billing. ##### Practices that keep the fleet healthy A few conventions keep a preview fleet manageable: - Apply a resource quota to every preview namespace, so one runaway PR cannot starve the rest. - Label everything with the PR number and team, which is what makes the preview line item attributable when the cluster bill needs explaining. - In monorepos, filter the generator by changed path so a docs-only PR does not deploy the stack. - Keep preview Helm values in the same file lineage as production values, overriding the minimum, because every hand-copied value is future drift. - Treat secrets deliberately, since stamping production credentials into short-lived namespaces per PR widens the blast radius of every leak. #### Where the pattern strains The mechanics above are sound, and for a single service or a small stack they hold up indefinitely. The strain shows up with system size and PR volume, on several fronts at once. Spin-up time grows with the stack. A preview that needs twenty services, migrations, and seed data takes minutes to become clickable, and slow previews stop being consulted. Data seeding is its own tax, since every namespace starts empty and realistic fixtures age badly. Cost scales with the number of services in the stack multiplied by the number of open PRs. Every open pull request holds a complete copy of every service, mostly idle, and preview fleets routinely become one of the larger line items in a cluster bill. Reduced replica counts soften this but do not change the shape of the curve. Operational overhead scales the same way, because every preview namespace is an environment the platform team is on the hook for: its seed data, its config currency, and the question of why it came up broken. Cluster capacity becomes a scheduling problem of its own, since preview load is spiky, quiet at night and heavy before a release, so teams either overprovision nodes for the peak or bolt on autoscaling and accept slower previews at the spike. On managed clusters like Amazon Elastic Kubernetes Service (EKS) this turns into node group and autoscaler tuning that exists only to serve previews. Two less visible problems compound over time. Preview Helm values drift from production values, so previews slowly stop predicting production behavior. And third-party dependencies, payment sandboxes, external APIs, message brokers, either get mocked per namespace or shared with no isolation at all. Coding agents amplify all of this. A team whose PR volume multiplies finds the duplication model multiplying its spin-up queues, its bill, and its fleet of environments to keep alive. #### The alternative: route requests instead of duplicating the stack The other architecture keeps one stable environment running, continuously deployed by Argo CD exactly as today, and deploys only the changed service per PR, as an isolated version beside the stable one. Requests carrying that PR’s routing key in a header are steered to the changed version at the sidecar or mesh layer, and every other request flows through stable services. The approach is GitOps-compatible rather than GitOps-replacing. Argo CD keeps owning the stable environment, and the preview layer operates on top of it, which also means previews exercise the real, current versions of every dependency instead of a per-namespace copy that seeded an hour ago. Signadot implements this model with Sandboxes, lightweight ephemeral environments created per pull request by CI, each holding the changed service inside the shared cluster and exposed at a hosted preview URL that injects the routing key. Route groups combine several changed services under one key when a change spans repositories. The first difference a team feels is developer experience. A preview is ready as soon as one container starts, in seconds rather than the minutes a full-stack deploy and seed takes, and it stays that fast whether the stack has five services or three hundred, because nothing else needs to be deployed. Fast previews are the ones reviewers and product managers actually click on every PR, instead of saving them for the changes that seem risky. Operational overhead drops with it. The platform team runs one baseline environment, kept in sync by Argo CD, instead of a fleet of per-PR copies that each need seed data, current config, and an answer when they come up broken. Capacity planning stops being a preview-specific problem, since the marginal preview is one or two pods rather than a namespace full of them. Cost follows the same shape. Each preview costs one or two service instances instead of a full system copy, so the bill scales with the size of the change, not the size of the stack. That economics is also what lets the model absorb agent-amplified PR volume: when coding agents multiply the number of open changes, previews that start in seconds and cost a single service multiply with them, without multiplying the cluster. Shared clustersyncscreatesArgoCDpreview URLpull requestservice-1service-1bSANDBOXservice-3dbtagged requestshared dependencies ArgoCD keeps syncing the shared cluster of stable services. The Sandbox holds only the change, and the preview URL's tagged requests route through it. syncsArgoCDpreview URLpull requestservice-1service-1bSANDBOXservice-3dbtagged requestshared dependencies ArgoCD keeps syncing the shared cluster of stable services. The Sandbox holds only the change, and the preview URL's tagged requests route through it. Three things have to be in place for this to work. Services must propagate trace context headers across hops, stateful resources like databases and queues need explicit per-resource isolation, and a platform component runs in the cluster. The [preview environments solution page](https://www.signadot.com/solutions/preview-environments/) covers the managed version of the workflow. Keep Argo CD, add previews that start in seconds Signadot gives each pull request a hosted preview URL backed by a lightweight sandbox on the shared cluster Argo CD already syncs, so a preview costs one service instead of a stack copy. The free tier is open to every developer. [Start for free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### When each approach fits ApplicationSet: duplicate per PRRequest routing: only what changedpr-101full stackpr-102full stackpr-103full stackpr-1011 servicepr-1022 servicespr-1031 serviceCost: services x PRsCost: one or two services per PR ApplicationSet cost grows with every service and every open PR. Request routing costs one or two services per PR. ApplicationSet: duplicate per PRpr-101full stackpr-102full stackpr-103full stackCost: services x PRsRequest routing: only what changedpr-1011 servicepr-1022 servicespr-1031 serviceCost: one or two services per PR ApplicationSet cost grows with every service and every open PR. Request routing costs one or two services per PR. The ApplicationSet pattern fits: - stacks small enough to duplicate comfortably - previews that must exercise cluster-level changes, such as operators, ingress, or the manifests themselves - teams that want the whole mechanism in open source tools they already run It is the right default for a handful of services and moderate PR volume. Request routing on a shared cluster fits: - large service graphs, where a full copy per PR is slow to start and expensive to hold - teams that want previews ready in seconds, so reviewers and stakeholders keep clicking them - platform teams that want one environment to operate instead of a fleet - high or agent-amplified PR volume The two are not mutually exclusive, and mature platform teams often run both. Application code changes, the overwhelming majority of PRs, get routed previews on the shared cluster, while the occasional PR that changes manifests, operators, or the ingress layer gets a full ApplicationSet preview, since cluster-level changes are exactly what request routing cannot isolate. Gating the expensive path behind a preview label keeps the default cheap. The [preview environments guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) compares these architectures alongside vCluster and Okteto, and [Per-PR Preview URLs, Explained](https://www.signadot.com/articles/per-pr-preview-urls/) covers the URL pattern itself, including access, data, and cleanup. For the routed model end to end, see this [walkthrough of cost-efficient preview environments](https://www.signadot.com/blog/create-cost-efficient-preview-environments-in-kubernetes-with-signadot/). #### Frequently asked questions How do ArgoCD preview environments work? An ApplicationSet with the pull request generator polls your source control provider and emits one set of template parameters per open PR. The controller renders an Argo CD Application from each, deploying that branch's code into a per-PR namespace behind a per-PR URL, and prunes the Application and namespace when the PR closes or merges. Where does the ApplicationSet preview pattern strain? Spin-up takes minutes because the full stack must deploy, migrate, and seed before the preview is clickable, cost scales with services multiplied by open PRs, and the platform team ends up operating a fleet of environment copies. All three compound as the service graph and PR volume grow, especially once coding agents multiply the number of open PRs. What is the alternative to duplicating an environment per pull request? Request routing on a shared cluster: one stable environment stays continuously deployed by Argo CD, each PR deploys only its changed services, and requests carrying the PR's routing key are steered to them. Previews are ready in seconds, the platform team operates a single environment instead of a fleet, each preview costs one or two service instances, and the model absorbs agent-amplified PR volume. Can I use request routing without giving up Argo CD? Yes. Argo CD keeps syncing the stable environment exactly as before, and the routing layer operates on top of it. Mature platform teams often run both: routed previews for application code changes, which are the overwhelming majority of PRs, and a full ApplicationSet preview for the occasional PR that changes manifests, operators, or ingress. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: What Are Preview Environments? The Complete Kubernetes Guide* preview-environments ##### What Are Preview Environments? The Complete Kubernetes Guide July 31, 2025 *Image: Per-PR Preview URLs, Explained* preview-environments ##### Per-PR Preview URLs, Explained July 21, 2026 *Image: Preview Environments for QA and Stakeholder Review* preview-environments ##### Preview Environments for QA and Stakeholder Review August 5, 2026 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Preview Environments for QA and Stakeholder Review Source: https://www.signadot.com/articles/preview-environments-for-qa-and-stakeholder-review/ Summary: How per-PR preview environments move QA, product, and design feedback to before the merge, what changes for the QA role, and what it takes to run the workflow credibly. ### Preview Environments for QA and Stakeholder Review Author Arjun Iyer Published August 5, 2026 **Preview environments for QA and stakeholder review** give every pull request a running version of the application that anyone can open from a link, before the merge happens. That inverts the usual order. On most teams, the first person to see a feature running is not the person who asked for it: QA meets the change after it merges, on a shared staging environment carrying everyone else’s changes too, and the product manager often meets it in production. A preview environment is an on-demand, isolated, ephemeral deployment created automatically for a specific branch or pull request. This article is about what that unlocks for the people around the code: QA leads, product managers, designers, and the engineering managers who own the release process. The infrastructure that makes it affordable is covered in the [preview environments guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/). #### Where review happens today The standard sequence puts every reviewer downstream of the merge. Code review looks at the diff, not the behavior. QA tests on a staging environment where a dozen changes landed since yesterday, so a failure could belong to any of them and attributing it means digging through everything that merged. Stakeholders see the feature when it ships, which is the most expensive possible moment to learn it missed the intent. Code reviewon the PRMergeQA finds bugs(shared staging)PM sees it(in production) Today every reviewer sits downstream of the merge, so feedback travels backward across it. Code reviewon the PRMergeQA finds bugs(shared staging)PM sees it(in production) Today every reviewer sits downstream of the merge, so feedback travels backward across it. The cost is more than bug latency. Feedback that arrives weeks after the code was written lands on a developer who has moved on, so every round trip carries a context-switch tax. And a contended staging environment adds its own failure mode, teams overwriting each other’s deployments and losing days to bugs that were never in anyone’s code. #### The per-PR review workflow With previews in place, the pull request becomes the review surface for everyone, not only engineers. When a PR opens, CI creates an environment for it and posts the URL on the PR and in the ticket. How that URL gets produced and wired into the PR is its own topic, covered in [Per-PR Preview URLs, Explained](https://www.signadot.com/articles/per-pr-preview-urls/). From there, each reviewer uses the same link differently. Developerpushes fixesCIbuilds the previewOpen PRpreview URL postedMergeQA · Product · Designreview the preview linkpushfeedbackcomments One loop: push, preview, feedback, fix. The merge comes after the loop settles. Developerpushes fixespushCIbuilds the previewOpen PRpreview URL postedcommentsQA · Product · Designreview the preview linkMergefeedback One loop: push, preview, feedback, fix. The merge comes after the loop settles. QA tests the change in isolation, against real, current versions of the system’s other services rather than a snapshot or a mock. One change per environment means a found bug has exactly one suspect, no bisecting a staging pileup. The fix arrives as a push to the same PR, and the same URL updates in place. Product managers and designers click the link. There is no branch to pull, no build to run, no request to an engineer for a demo. Design reviews rendering and interaction on the running feature, product confirms the behavior matches the intent, and both leave comments while the author still has the whole context in their head. Acceptance happens before merge, so the merge itself becomes a non-event. #### What changes for the QA role The gatekeeper model puts QA at the end of the line, batch-testing a release candidate under deadline pressure. Previews remove the batch. QA reviews changes one at a time, as they appear, and the release stops accumulating untested surface area between cycles. That shifts where QA time goes. Less of it is spent reproducing environment-specific failures and arguing about whose change broke staging, and more goes to exploratory testing per change and to promoting the checks worth keeping into automated suites that run against the same per-PR environments. The role moves upstream, from inspecting the finished batch to reviewing each change while it is still cheap to reject. #### How to tell it is working For the engineering manager who owns the rollout, a few measures separate a preview program that changed the workflow from one that added a link nobody clicks: - Escaped defects, the bugs QA or customers find after merge, should fall within a quarter, because the same bugs are being caught on the PR instead. - Time from PR opened to first non-author feedback should compress from days to hours. - The fraction of PRs whose preview is visited by someone other than the author measures whether stakeholders actually participate. - Release batch size should shrink toward single changes, since the point of previews is that merges stop waiting for a batch QA pass. #### What stakeholders do with a preview link The audience for a preview URL is wider than QA, and each group uses it differently: - Product managers do acceptance on the open PR instead of filing post-release correction tickets. - Designers check real rendering with real data instead of static mocks. - Documentation writers capture screenshots of features that have not shipped. - Support and sales teams see what is coming without waiting for a release note. The same links verify behavior for web and mobile applications alike, and reviewers are not always human: coding agents can run end-to-end tests against the same per-PR preview before a person ever opens it. None of these people will ever run kubectl, which is the point. The preview link has to work at the browser level, behind the company’s single sign-on, or it will not get clicked. #### What it takes to run this credibly The workflow above has one load-bearing prerequisite: per-change environments must be cheap and fast enough that creating one for every pull request is unremarkable. If a preview takes twenty minutes to build or carries the cost of a full environment copy, teams start rationing previews to the changes that seem risky, and the workflow quietly collapses back to batch review. That economics problem is why the architecture matters. [Duplicating the full stack per PR](https://www.signadot.com/articles/argocd-preview-environments/) works for small systems. Larger service graphs get there by sharing one live cluster and routing each PR’s requests to the services it changed. The first payoff is the reviewer’s experience: only the changed service deploys, so the preview is ready in seconds, and a link that is always ready is a link stakeholders keep clicking. The platform team runs one baseline environment instead of a fleet of copies to seed, patch, and answer for. And each preview costs one or two service instances rather than a stack copy, which is what keeps the practice affordable as coding agents multiply the number of open PRs waiting for review. This is what Signadot provides as a managed workflow: per-PR ephemeral environments on the cluster you already run. The [preview environments solution page](https://www.signadot.com/solutions/preview-environments/) covers what that looks like. Beyond the environments themselves, three practical pieces make or break adoption: - Access has to be one click for non-engineers, meaning single sign-on rather than credentials. - Data has to be realistic enough to review against, whether shared from the stable system or seeded. - Teardown has to be automatic on merge, so nobody manages an environment fleet by hand. A review link on every PR, before the merge Signadot gives each pull request a hosted preview URL backed by a lightweight sandbox on your shared cluster, so QA, product, and design review the change against real dependencies while the author still has context. The free tier is open to every developer. [Start for free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### The change that matters Preview environments are usually sold as infrastructure, but the durable value is organizational: feedback moves to the moment it is cheapest to act on, and the merge becomes the end of review rather than the beginning. For QA leads and product owners evaluating the pattern, the test is concrete. Count how far feedback currently travels back from staging and production, and what each of those round trips costs. #### Frequently asked questions What is a preview environment for QA and stakeholder review? A preview environment is an on-demand, isolated, ephemeral deployment created automatically for a specific branch or pull request. A link posted on the PR opens the running change, so QA, product managers, and designers can review it before the merge instead of after. How do preview environments change the QA workflow? QA stops batch-testing a release candidate on shared staging and reviews changes one at a time, as they appear. Each change runs in isolation against real, current versions of the system's other services, so a found bug has exactly one suspect, and the fix arrives as a push to the same PR with the same URL updating in place. What do product managers and designers do with a preview link? They click it. There is no branch to pull or build to run: product confirms the behavior matches the intent, design reviews rendering and interaction on the running feature with real data, and both leave comments on the PR while the author still has the context in their head. What does it take to give every pull request a preview environment? Previews must be cheap and fast enough that creating one per PR is unremarkable. Larger service graphs get there by sharing one live cluster and routing each PR's requests to its changed services, so a preview is ready in seconds and costs one or two service instances. Beyond that, access needs single sign-on, data has to be realistic, and teardown has to be automatic on merge. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: What Are Preview Environments? The Complete Kubernetes Guide* preview-environments ##### What Are Preview Environments? The Complete Kubernetes Guide July 31, 2025 *Image: Per-PR Preview URLs, Explained* preview-environments ##### Per-PR Preview URLs, Explained July 21, 2026 *Image: ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains* preview-environments ##### ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains July 24, 2026 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Signadot vs Garden.io: Which Kubernetes Environment Model Fits Your Team? Source: https://www.signadot.com/articles/signadot-vs-garden-io/ Summary: How Garden's full-stack environment automation compares to Signadot's shared-cluster Sandboxes: the duplication versus routing tradeoff, a feature-by-feature table, and a decision framework by stack size and bottleneck. ### Signadot vs Garden.io: Which Kubernetes Environment Model Fits Your Team? Author Arjun Iyer Published August 6, 2026 Comparing Signadot and Garden.io comes down to two different answers to the same question: how should a team running microservices on Kubernetes get environments for development and testing? Garden builds and deploys a complete copy of your stack for every environment, with a dependency graph and caching to make repeat runs fast. Signadot deploys only the services you changed into Sandboxes, lightweight ephemeral environments on a shared cluster, and routes requests to a single shared set of stable dependencies for everything else. Neither model wins everywhere. Garden is stronger when you need reproducible environments built from zero, isolation of stateful services without extra configuration, and build and test caching across development and CI. Signadot is stronger when the stack is large, the number of concurrent environments is high, and provisioning time and infrastructure cost are the constraints. This article explains how each tool works, compares them feature by feature, and closes with a decision framework by team size and use case. #### The problems that push teams to either tool The trigger is usually one of four problems, and which one it is matters for the choice. - A shared staging environment has become a queue. Teams wait for a turn to test, and one broken deploy blocks everyone. - CI takes too long to produce a testable environment, so end-to-end tests run after merge instead of before. - Preview environments exist but cost too much. Every open pull request duplicates the full stack, and the bill scales with PR volume. - Local development stopped working because the stack outgrew laptops, and mocks have drifted from the real services. Garden and Signadot both address these problems. They differ in the mechanism, and the mechanism determines the cost curve and suitability for your stack. #### How Garden works [Garden](https://garden.io/) is a DevOps automation tool that describes your entire system as a graph and can build, deploy, and test it from a single command. You define actions of four kinds, Build, Deploy, Test, and Run, in garden.yml files, and Garden assembles them into a dependency graph it calls the [Stack Graph](https://docs.garden.io/overview/what-is-garden). Because the graph knows what depends on what, Garden caches aggressively: the same image is never built twice, and the same test never reruns against unchanged code. Environments are full deployments of that graph. Garden templates a unique [Kubernetes namespace per developer, CI run, or pull request](https://docs.garden.io/guides/namespaces), and each namespace receives its own copy of every service in the project, datastores included. Sync mode live-reloads code changes into a running service without a rebuild or redeploy. Plugins cover Helm charts, Kustomize, plain manifests, and container builds, and Terraform and Pulumi actions can provision infrastructure as part of the same graph. The core is open source under the Mozilla Public License 2.0. Garden’s [hosted offering](https://garden.io/plans) adds team-wide result caches shared across clusters and a remote container build service. Repogarden.ymlStack GraphBuildDeployTestRundev-aliceapiwebjobsdbpr-101apiwebjobsdbpr-102apiwebjobsdb One graph, but every namespace receives a full copy of every service and datastore. Repogarden.ymlStack GraphBuildDeployTestRundev-aliceapiwebjobsdbpr-101apiwebjobsdbpr-102apiwebjobsdb One graph, but every namespace receives a full copy of every service and datastore. Where Garden fits: - One configuration drives development, CI, and preview environments, so the environment a developer tests in matches what CI runs. - Dependency-aware caching cuts repeat build and test time, which compounds in CI. - It reuses the Helm charts, Dockerfiles, and Terraform you already have. - Every environment is fully isolated, including its own datastores, with no extra per-resource setup. - Environments build from zero, so you do not need an existing healthy cluster to point at. Where it strains: - Every environment carries the full stack. Twenty services means twenty deployments, plus datastores, per developer and per open PR. - A cold environment still has to deploy and start every service, which takes minutes even when caching skips the builds. - Each service needs garden.yml actions written and maintained, and the configuration has a documented learning curve. - Infrastructure cost scales with the number of concurrent environments, which is roughly developers plus open PRs. That last point is the same ceiling any duplication-based approach runs into, whether the boundary is a namespace, a virtual cluster, or a whole cluster. [Namespace-based environments](https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/) hit it first because the cost is multiplicative rather than additive. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### How Signadot works Signadot is a Kubernetes-native validation platform built around [Sandboxes](https://www.signadot.com/docs/concepts/sandbox), lightweight ephemeral environments that share one cluster. A Sandbox deploys only the services a change touches. Requests carry a routing key in a header, and the routing layer sends matching traffic through the sandboxed service versions while every other hop is served by the shared stable versions already running on the cluster. Because nothing else is duplicated, a Sandbox is ready in seconds and hundreds can run concurrently at marginal cost. requestrouting key: alice-1Kubernetes clusterSandboxorders v2frontendorderspaymentsdatastore The routing key sends one hop through a Sandbox. Every other hop uses the shared stable version, so the greyed service is never duplicated. requestrouting key: alice-1Kubernetes clusterfrontendordersSandboxorders v2paymentsdatastore The routing key sends one hop through a Sandbox. Every other hop uses the shared stable version, so the greyed service is never duplicated. Testing runs where the environments are. Jobs execute existing Playwright, Cypress, or k6 suites inside the cluster against a Sandbox. Smart Tests run the same API calls against the PR version and the stable version of a service and flag behavioral differences. Plans package validation workflows so CI pipelines and coding agents can run them by name, and an MCP server lets agents create Sandboxes and validate their own changes. Where Signadot fits: - Environments arrive in seconds at marginal cost, which makes one per pull request, per developer, and per agent task affordable. - Changes are tested against real running dependencies rather than mocks, because the shared cluster runs the real services. - It works with your existing manifests. There is no per-service configuration format to adopt. - Concurrency scales past what duplication can afford. Brex replaced namespace-based preview environments with Sandboxes and [cut preview infrastructure costs by 99 percent](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/), about 2 million dollars a year. What it requires: - A shared cluster, usually staging, that runs stable versions of every service, and an owner who keeps it healthy. Signadot installs as an operator on that cluster. - Services must propagate request headers, typically trace context. Teams already running distributed tracing have this. Teams that do not must add propagation. - Isolating stateful resources is explicit. Resource plugins create per-Sandbox databases, queues, or other dependencies where a test needs them, instead of every environment getting copies by default. - Signadot is not a build tool. Images come from your existing CI, and Signadot does not build or cache them. - The platform is a commercial product rather than an open source core. The deeper version of this tradeoff is a question about where the isolation boundary sits, which is covered in [infra-level vs request-level isolation](https://www.signadot.com/articles/isolation-models-for-ephemeral-environments-infra-level-vs-request-level/). #### Signadot vs Garden.io: feature by feature Capability Garden Signadot Environment model Full copy of the stack per namespace Only changed services deploy, the rest is shared Time to a ready environment Minutes for a cold environment, caching speeds repeats Seconds Cost per concurrent environment Full-stack resource cost Marginal, only the changed services Build and test caching Core strength, dependency-aware None, uses your CI builds Local development Sync mode reloads code into a deployed environment Local process joins the cluster and receives routed requests Datastore isolation Every environment gets its own copies by default Explicit per-resource setup through resource plugins Configuration garden.yml actions per service Works with existing manifests Infrastructure provisioning Terraform and Pulumi actions in the same graph Out of scope Coding agents No per-agent isolation model One Sandbox per agent task, MCP server built in Licensing Open source core, hosted paid tiers Commercial The caching rows favor Garden and the environment rows favor Signadot, and that split summarizes the comparison. Garden optimizes the work of producing an environment. Signadot reduces how much environment there is to produce. #### Signadot vs Garden.io by team size and use case Choose Garden when: - Your stack is small enough that a full copy per environment fits comfortably in your cluster budget. At that scale duplication is simple and the isolation is complete. - You have no stable shared cluster to route against, and environments must be built from zero, infrastructure included. - Reproducibility is the goal: one command that takes a fresh cluster to a running, tested system. - CI build and test time is your bottleneck, and dependency-aware caching would remove most of it. - Policy requires an open source, self-hostable core. Choose Signadot when: - The stack is too large to duplicate per change. The cost is multiplicative: services times concurrent environments, and it grows with the team. - You want an environment per pull request, per developer, and per coding agent at the same time, without the bill scaling the same way. - You already run a staging cluster and want every change validated against real dependencies before merge. - Time to environment is your bottleneck: reviews and tests wait on provisioning, not on builds. What is thebottleneck?Start withGardenShared clusteralready running?Start withSignadotbuild and test timeenvironment availabilityyesno Two questions decide it: what is slow, and whether a stable shared cluster already exists. What is the bottleneck?build and test timeenvironmentavailabilityStart withGardenShared clusteralready running?noyesStart withSignadot Two questions decide it: what is slow, and whether a stable shared cluster already exists. Team size is a workable proxy for stack size and concurrency. A team of five with eight services can run either model, and Garden’s single-config simplicity and caching may win outright. A team of fifty with forty services and coding agents opening PRs cannot afford a full stack per change, and the shared-cluster model becomes the only affordable way to give every change its own environment. The duplication versus routing tradeoff, alongside two other approaches, is covered in more depth in the [guide to ephemeral environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/). The two tools also do not solve identical problems. Garden’s center of gravity is the build and deploy pipeline. Signadot’s is validation against real dependencies. A team whose pain is slow CI builds should evaluate Garden first, and a team whose pain is environment scarcity should evaluate Signadot first. #### How to choose Count your services, count your concurrent changes, and check whether a healthy shared cluster exists. A small stack, no shared cluster, or a build-time bottleneck points to Garden. A large stack, high concurrency, agents in the loop, and an existing staging cluster point to Signadot. For a product-level breakdown of the same comparison, see the [Signadot vs Garden comparison page](https://www.signadot.com/comparison/garden/). Further reading: - [Ephemeral Environments in Kubernetes: The Complete Guide](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) - [What Are Preview Environments? The Complete Kubernetes Guide](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) - [Local Development on Kubernetes: The Complete Guide](https://www.signadot.com/guide-to-local-development-kubernetes/) #### Frequently asked questions What is the difference between Signadot and Garden.io? Garden builds and deploys a complete copy of your stack into a dedicated Kubernetes namespace for every environment, using a dependency graph and aggressive caching to make repeat runs fast. Signadot deploys only the services a change touches into a Sandbox on a shared cluster and routes requests to the stable shared versions for every other hop, so nothing else is duplicated. Which is cheaper, Garden or Signadot? Cost depends on stack size and concurrency. Garden's cost per environment is the full resource cost of the stack, so the bill scales with services multiplied by concurrent environments. Signadot's cost per environment is marginal because only the changed services are deployed. Below roughly ten services with low concurrency the difference is small. At forty services with dozens of open pull requests the gap is large, and Brex cut preview infrastructure cost by 99 percent moving from namespace duplication to Sandboxes. Can you use Garden and Signadot together? Yes. Signadot is not a build tool and consumes images produced by your existing CI, which Garden can be. Teams commonly keep Garden or their current pipeline for building and caching, and replace full environment duplication with Sandboxes for per-pull-request testing. Does Signadot require a shared staging cluster? Yes. Signadot needs a cluster running stable versions of every service, usually staging, with an owner who keeps it healthy. Garden has no such requirement because each environment is built from zero, which is why Garden fits teams with no stable shared cluster to route against. Does Signadot require changes to my services? Services must propagate request headers, typically trace context, so the routing layer can follow a request through the call graph. Teams already running distributed tracing usually have this. Teams that do not must add propagation before Sandboxes will route correctly. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency* microservices-testing ##### Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency April 10, 2025 *Image: AI Powered Contract Testing for Microservices Excellence* contract-testing ##### AI Powered Contract Testing for Microservices Excellence July 3, 2025 *Image: Kubernetes Budget Rescue: Trim 90% of Testing Infrastructure Costs* cost-optimization ##### Kubernetes Budget Rescue: Trim 90% of Testing Infrastructure Costs April 18, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Integration Tests Pass With Mocks but Staging Still Breaks Source: https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/ Summary: Why mocked integration tests miss staging failures, the escalation ladder of contract tests, real-dependency tests, and scoped end-to-end tests, and the two architectures that let them run pre-merge. ### Integration tests pass with mocks but staging still breaks: how to catch it earlier Author Arjun Iyer Published August 12, 2026 When integration tests pass with mocks but staging still breaks, the gap is dependency fidelity, not test coverage. A mocked test verifies your assumptions about a dependency. Staging is the first place those assumptions meet the dependency itself, and the failures that surface there are exactly the ones a mock cannot represent. Adding more mocked tests cannot close that gap. A mock encodes the dependency’s behavior on the day the mock was written, and nothing updates it when the real service changes. More mocked tests raise the coverage of your assumptions, not their accuracy. This article covers why mocked integration tests miss what they miss, the escalation ladder of what to add, and how early each rung can realistically run. For the wider picture of what the stage is for and why the shared copy becomes a bottleneck, see the [complete guide to staging environments](https://www.signadot.com/staging-environments/). #### Why do mocked integration tests miss staging failures? A mock can only fail on what its author anticipated, and the failures that reach staging are the unanticipated ones. They cluster into four classes that live outside a mock’s reach: - **Mock drift.** The mock matches the dependency as it was when the test was written. The dependency’s team ships changes on their own schedule, and no build step fails when the mock falls behind. Comparing the changed service’s responses against the stable version’s on the same requests is one way to surface it, an approach covered in [shadow testing for microservice integration](https://www.signadot.com/blog/shadow-testing-superpowers-four-ways-to-bulletproof-apis/). - **Contract versus behavior.** A mock can match the schema exactly and still return values the real service never produces: an empty list where production always has entries, a status the service stopped emitting a year ago. - **The network is absent.** Timeouts, retries, serialization errors, and header propagation never execute in a mocked test, and each of those is a production failure class of its own. - **Deployed-only configuration.** Connection strings, feature flags, resource limits, and auth config exist only in the deployed environment, so no in-process test can exercise them. Integration failures are the failures between processes: data inconsistencies, latency behavior, fault tolerance. Unit tests cannot verify inter-service communication no matter how many of them exist, which is why a green pipeline says little about what happens when services meet. The second-order cost shows up in how teams respond. When the automated suite stops predicting staging behavior, verification moves to manual checks against the staging environment, and the suite degrades into background noise. A suite with a stable count of failing tests stops being a signal at all: teams have run for months watching that the number of failures stayed constant rather than investigating them. Shared staging then makes the feedback worse. Multiple teams deploy versions into the same environment at once, so test conditions change under your feet, and a failure could belong to any change that landed that day. 1Mock writtenmatches Service B v12Service B ships v23Tests still pass4Staging breaks The mock encodes the dependency as it was. Nothing fails when the dependency moves on. 1Mock writtenmatches Service B v12Service B ships v23Tests still pass4Staging breaks The mock encodes the dependency as it was. Nothing fails when the dependency moves on. #### What should I add to catch integration bugs before staging? The additions form a ladder. Each rung catches a failure class the one below it cannot, and each needs a higher-fidelity environment and more moving parts to run, so the question is how much fidelity your failure pattern actually demands. Simplest first: 1. **Contract tests.** A consumer and provider agree on the shape of their interaction, and each side verifies against the recorded contract without deploying the other. [Pact](https://pact.io/) is the most widely used implementation. This catches signature and schema drift in under a minute of pipeline time. It does not catch behavior, and it carries a standing cost: both sides have to write and maintain the contracts continuously, and sustaining that discipline across many teams is where the approach usually breaks down. The [Pact comparison](https://www.signadot.com/comparison/pact/) covers where the contract boundary ends. 2. **Integration tests against real dependencies.** Give the changed service an environment where its dependencies are real running services rather than mocks, then point the tests you already have at it. This rung catches behavior, routing, configuration, and serialization failures, the classes mocks miss. Something has to supply that environment, whether as a full copy of the stack or as an isolated slice of a shared cluster, and the next section compares those options. 3. **Pre-merge end-to-end tests scoped to the changed service.** Run the two or three user journeys the change touches, not the full suite. This catches cross-journey regressions and demands the most from both the environment and the suite, so scope is what keeps it viable. fidelityScoped E2Ecross-journeyregressionsIntegration againstreal dependenciesbehavior, config,routingContract testsschema drift Each rung catches what the one below it cannot, and costs more environment to run. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### How early can this realistically move? All three rungs can run pre-merge. Contract tests already do so trivially, because they verify recorded contracts without deploying anything. The open question is rungs two and three, which need a per-change environment with real dependencies, available quickly enough to sit inside a PR pipeline. They are also the rungs where pre-merge matters most, because post-merge feedback lands in the same place staging failures already land. Two architectures supply that. A full environment per PR deploys a complete copy of the stack for every open pull request. Routing on a shared cluster deploys only the changed service next to a single shared set of stable dependencies and steers tagged requests to it. Full environment per PR Routing on a shared cluster Cost per PR One full copy of the stack Only the changed service Isolation Complete, including data Per-request, shared stable dependencies Spin-up time Minutes Seconds Prerequisite Deployable manifests for every service Header propagation across every hop [Release](https://release.com/) and [Bunnyshell](https://www.bunnyshell.com/) provide the full-environment pattern as a managed workflow. It is simpler to reason about, since each PR gets a fully independent copy, and below roughly ten services it is the right call. Teams that build the same pattern in-house tend to run ten or fifteen standing test environments and absorb a second cost the table does not show: keeping every copy in parity with production configuration, which is ongoing operational work rather than a one-time setup. The crossover comes from arithmetic. Cost scales with the number of services multiplied by the number of open PRs, so a 40-service stack with 30 open PRs is provisioning 1,200 service instances to test 30 changes. Routing on a shared cluster flips the multiplier, because each PR deploys one service and shares the rest. The shared-cluster pattern is what Signadot provides. A Sandbox is a lightweight ephemeral environment holding the changed service, deployed into the cluster where the stable versions of its dependencies already run. Requests carrying the Sandbox’s routing key reach the changed service, every other call resolves to the shared stable versions, and provisioning takes seconds because nothing else is duplicated. The prerequisite is header propagation: every service forwards the routing header on each hop, and teams already propagating trace context have most of that in place. Shared staging gated by feature flags comes up in this comparison often, and it does not belong in it. Flags gate exposure after the code has merged, so nothing on the ladder moves pre-merge, and the flags add a cleanup obligation of their own. Whatever their value for release control, they are not a testing architecture. Full environment per PRenvironment copypull requestcreatesservice-1service-2service-3dbevery service deployed for this one PRRouting on a shared clusterShared clustercreatestestspull requestservice-1service-1bSANDBOXservice-2dbtagged requestshared dependencies A full copy runs every service per PR. Routing deploys the changed service into the shared cluster beside its stable version and steers tagged requests through it and back to the shared services. Full environment per PRpull requestcreatesenvironment copyservice-1service-2service-3dbevery service deployed for this one PRRouting on a shared clustertestspull requestShared clustercreatesservice-1service-1bSANDBOXservice-2dbtagged requestshared dependencies A full copy runs every service per PR. Routing deploys the changed service into the shared cluster beside its stable version and steers tagged requests through it and back to the shared services. #### How to choose Two decisions come out of this article, and they are worth separating. The first is which rungs to add, and the failure classes you actually see decide it. Shape mismatches between services point to contract tests, the cheapest rung and the one with no infrastructure requirement. Failures that only appear when services actually talk, wrong values, broken routing, misread configuration, point to the real-dependency rung, because no amount of contract or unit coverage reaches them. Recurring breakage in flows that span several services justifies the scoped end-to-end rung on the journeys that keep breaking. The second is which architecture supplies the environment for those rungs. Stack size is the main input: below roughly ten services, a full environment per PR is simpler to reason about and the duplication cost stays tolerable. Above that, the services-times-PRs arithmetic takes over, and routing on a shared cluster is the option that keeps cost and provisioning time flat as the stack grows. Header propagation is the gate. If your services already forward trace context, the shared-cluster pattern is close to free to adopt, and if they do not, that plumbing is the price of entry. The wider testing lifecycle around these stages is covered in [Microservices Testing Environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/). #### Frequently asked questions My integration tests pass with mocks but staging still breaks. What am I missing? The mocks encode assumptions about your dependencies, and staging is where the assumptions meet reality. The failure classes that get through are mock drift, behavior a schema-correct mock never produces, network effects, and deployed-only configuration. Adding a stage that tests the changed service against real dependencies is what closes the gap. Should I delete my mocked tests? No. Mocked tests are the right tool for logic inside a service, and they stay fast and deterministic. Stop asking them fidelity questions they cannot answer, and add a real-dependency stage for those. Do I need a full copy of my stack to test against real dependencies? No. A full copy per PR is one architecture, and below roughly ten services it is a reasonable one. Past that size the arithmetic turns: cost grows with the number of services multiplied by open PRs, and spin-up time tracks the slowest service in the stack. Routing on a shared cluster deploys only the changed service and resolves everything else to a single shared set of stable dependencies, which keeps cost and provisioning time flat as the stack grows. That is why it is the architecture that holds up for larger systems. How do I know when mock drift is happening? Indirectly: staging or production failures in interactions your suite says are covered. Directly: contract tests, which fail when a provider's actual interface no longer matches what consumers recorded. Comparing the changed service's responses against the stable version's on the same requests also surfaces drift. Mock drift itself produces no signal, which is the problem. [ ###### Read the docs *Image: arrow icon* Comprehensive guide and resources to get the most out of our platform. ](https://www.signadot.com/docs/overview)[ ###### Local Development *Image: arrow icon* Run services locally while connecting to dependencies in your remote Kubernetes cluster. ](https://www.signadot.com/solutions/local-development/)[ ###### Preview Environments *Image: arrow icon* Preview every code change without duplicating full environments. ](https://www.signadot.com/solutions/preview-environments/) #### Related Articles *Image: Reducing Costs and Boosting Productivity with Kubernetes Ephemeral Environments* cost-optimization ##### Reducing Costs and Boosting Productivity with Kubernetes Ephemeral Environments July 17, 2025 *Image: The Ultimate Guide to Lightweight Kubernetes Environments* tutorials-guides ##### The Ultimate Guide to Lightweight Kubernetes Environments May 1, 2025 *Image: Signadot SmartTests vs Pact Contract Testing* contract-testing ##### Signadot SmartTests vs Pact Contract Testing June 13, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Local Development on Kubernetes: The Complete Guide Source: https://www.signadot.com/guide-to-local-development-kubernetes/ Summary: The four approaches to Kubernetes local development, local clusters, sync tools, shared remote clusters, and cloud development environments, compared on speed, quality, and cost. ### Local Development on Kubernetes: The Complete Guide How should you do local development when your services run on Kubernetes? Compare the four workable approaches, local clusters, sync tools, connecting your laptop to a shared cluster, and cloud development environments, against the three dimensions that decide the choice: cost, quality, and speed. Type Guide Reading time 20 min Published July 10, 2026 **Local development on Kubernetes** means iterating on a service that will ultimately run in a cluster, with a feedback loop fast enough to keep you in flow and an environment faithful enough that passing locally predicts passing in production. Every way of setting this up is a position on three dimensions: speed, how quickly a change can be tried; quality, how much a passing test actually proves; and cost, what the environment consumes in infrastructure and upkeep. The shared cluster that third option connects to is usually the staging environment, whose own tradeoffs are covered in the [complete guide to staging environments](https://www.signadot.com/staging-environments/). There are four workable approaches to Kubernetes local development. You can run a scaled-down copy of the system on your machine with a local Kubernetes cluster, automate the rebuild and redeploy loop with a sync tool, run only the service you are changing and connect it to a shared remote cluster, or move the development workspace off the laptop entirely into a cloud development environment. Each approach settles the three dimensions differently, and this guide takes them in order before comparing them directly. 1 · Local clusterlaptopCode: laptopDependencies: laptop2 · Sync toolswatch · build · syncCode: synced to clusterDependencies: cluster3 · Shared clusterlaptopCode: one serviceDependencies: shared cluster4 · Cloud workspaceslaptopCloud workspaceCode: cloud workspaceDependencies: remote The four approaches: where the code runs and where its dependencies run. 1 · Local clusterCode: laptopDependencies: laptop2 · Sync toolsCode: synced to clusterDependencies: cluster3 · Shared clusterCode: one serviceDependencies: shared cluster4 · Cloud workspacesCode: cloud workspaceDependencies: remoteCloud The four approaches: where the code runs and where its dependencies run. #### Why localhost stops working A microservices system outgrows a laptop in predictable stages. Two or three services and a database run fine under [Docker Compose](https://docs.docker.com/compose/). Somewhere between ten and twenty services, the combined footprint of the system, its datastores, its message queues, and its sidecars exceeds what a development machine can hold. Past that point nobody runs the whole system locally, whatever the onboarding wiki claims. The standard response is to mock the dependencies you cannot run. Mocks keep the loop fast, but they encode yesterday’s understanding of a contract. As other teams ship changes, the mocks drift from the behavior of the real services, and the drift surfaces late, in staging or in an incident, where it is most expensive to fix. The [local versus remote environments tradeoff](https://www.signadot.com/blog/local-kubernetes-dev-environments/) has been argued for years, and mock drift is the recurring complaint that drives teams away from pure-local setups. Dependency behaviorreal service, changes each releaseyour mock, frozen at day onerelease 1release 2release 3timealigned on day onedriftthe gap widens with every releaseand surfaces in staging or an incident Time runs left to right, one tick per release of the dependency. The green line is what the real service does, the dashed line is what your mock still does, and the shaded area is drift your local tests cannot see. real servicemock, frozen at day oneDependency behaviorrelease 1release 2timedriftthe gap surfaces in staging Time runs left to right, one tick per release of the dependency. The green line is what the real service does, the dashed line is what your mock still does, and the shaded area is drift your local tests cannot see. Configuration drifts too. In-cluster DNS, service discovery, ConfigMaps, secrets, resource limits, and mesh sidecars have no faithful equivalent in a plain process-on-a-laptop setup. A service that behaves on localhost can fail in the cluster for reasons unrelated to the code change, which trains developers to distrust local results. The outcome is a familiar failure mode. The inner loop stays on the laptop and becomes less trustworthy, integration testing moves to a shared staging environment and becomes more contended, and the time between writing a change and trusting it grows. Each approach below is an attempt to shorten that distance from a different direction. #### Option 1: Run a local Kubernetes cluster on your machine The most direct answer is to run a real cluster locally. Several mature tools do this well, and they differ mainly in how they trade startup time and resource use against similarity to a production cluster. - [minikube](https://minikube.sigs.k8s.io/) runs a full single-node cluster, optionally multi-node, inside a virtual machine or containers, with an addon system covering ingress, dashboards, and load balancer emulation. - [kind](https://kind.sigs.k8s.io/) runs Kubernetes nodes as Docker containers and was built for testing Kubernetes itself, which makes it fast to create and destroy and a common choice in continuous integration (CI). - [k3s](https://k3s.io/) is a certified lightweight distribution packaged as a single binary, aimed at edge and resource-constrained machines. [k3d](https://k3d.io/) wraps it in Docker containers for the same convenience kind offers. - [Docker Desktop](https://docs.docker.com/desktop/features/kubernetes/) bundles a one-checkbox cluster, provisioned as kind nodes since early 2025, so images built locally are immediately visible to it. The differences between these distributions are covered in more depth in [the guide to lightweight Kubernetes environments](https://www.signadot.com/articles/the-ultimate-guide-to-lightweight-kubernetes-environments/). Some teams sidestep the cluster entirely and keep local development on Docker Compose, defining the service set as plain containers. This is the fastest option available and the furthest from production. Compose now ships [a bridge](https://docs.docker.com/compose/bridge/) that generates Kubernetes manifests from Compose files, which narrows the format gap but not the behavioral one, since none of the cluster machinery listed above exists in a Compose stack. A local cluster is the right tool in specific situations: - a small number of services that one machine can hold comfortably - platform components like admission controllers, operators, or [Helm](https://helm.sh/) charts, where the cluster itself is the subject of the work - offline development - CI pipelines that need a disposable cluster per run It breaks down on system size and on state. The resource ceiling is absolute, and no local distribution changes the arithmetic of running fifty services on sixteen gigabytes of memory. Local datastores start empty or rely on seed scripts that age poorly. And the local cluster’s manifests, versions, and configuration drift from production unless someone actively maintains parity, a cost that lands on every individual developer. #### Option 2: Automate the inner loop with sync tools The second approach keeps your code running inside a cluster, local or remote, and automates the loop that gets changes there. These tools watch your source tree and rebuild, redeploy, or sync files into running containers on every change. Editorsource treechangeSync toolSkaffold · TiltDevSpacebuild · syncCLUSTER, LOCAL OR REMOTEyour applogs and status back to the developer Sync tools automate the watch, build, deploy cycle so every save lands in the cluster. Editorsource treefile changeSync toolSkaffold · Tilt · DevSpacebuild or live-syncCLUSTERyour applogs and status Sync tools automate the watch, build, deploy cycle so every save lands in the cluster. - [Skaffold](https://skaffold.dev/), from Google, pipelines the watch, build, tag, deploy cycle. It remains actively developed, shipping regular releases and underpinning Google Cloud Deploy. See how [Skaffold compares to Signadot](https://www.signadot.com/comparison/skaffold/). - [Tilt](https://tilt.dev/) defines the development environment as code in a Starlark Tiltfile and adds live-update rules that sync files into running containers to skip image rebuilds, plus a web interface showing service health and logs. Docker acquired Tilt in 2022 and continues to maintain it, though feature velocity has been low since. See how [Tilt compares to Signadot](https://www.signadot.com/comparison/tilt/). - [DevSpace](https://www.devspace.sh/), a Cloud Native Computing Foundation (CNCF) sandbox project, deploys your application and then swaps a development container into the cluster with bidirectional file sync and port forwarding, so changes hot-reload in place. - [Okteto](https://www.okteto.com/) builds a development platform around the same loop, provisioning a namespace-isolated copy of the application per developer on your own cluster and syncing local files into a development container inside it. It has repositioned in recent years around provisioning those environments for coding agents as well as humans. Sync tools solve a real problem, which is that the unassisted build, push, redeploy loop on Kubernetes is far too slow for iterative work. Applied to a local cluster they make Option 1 more livable. Applied to a remote cluster they remove the laptop resource ceiling, since your code runs in the cluster rather than on your machine. What they do not answer is where everything else runs, and, for remote clusters, who else is using them. A sync tool deploys your in-progress code into whatever cluster it points at, so that cluster must provide isolation. Either each developer or coding agent gets a dedicated cluster, or each gets a dedicated namespace holding a copy of the system’s services. Point two developers at the same namespace and they collide: one engineer’s half-finished deployment starts answering the other’s requests. Okteto is the clearest expression of the isolated model, one namespaced environment per developer, and it works. But it is isolation by duplication: every developer needs their own copy of the dependencies, which sets up the cost problem the comparison below returns to. #### Option 3: Develop locally against a shared Kubernetes cluster The third approach inverts the problem. Instead of bringing the system to your machine, you run only the service you are changing, as a normal local process under your debugger, and connect it into a shared cluster where every dependency is real and current. Tools in this category differ in how they wire the connection. YOUR LAPTOPcheckout (modified)under your debuggertunnelSHARED CLUSTER · DEPENDENCIES AT CURRENT VERSIONSfrontendorderspaymentsother requestscheckoutstablereal datacalls checkoutto your laptop Your requests are redirected down the tunnel to the modified checkout on your laptop. Everyone else's traffic keeps using the stable checkout in the cluster. SHARED CLUSTERfrontendorderspaymentscheckoutstableother requeststunnelYOUR LAPTOPcheckout (modified) Your requests are redirected down the tunnel to the modified checkout on your laptop. Everyone else's traffic keeps using the stable checkout in the cluster. - [Telepresence](https://telepresence.io/), a CNCF sandbox project, creates a virtual network interface connecting your workstation to the cluster and intercepts traffic destined for an in-cluster deployment through a sidecar agent, redirecting it to your local process either globally or per request header. The open source project remains actively maintained. Its commercial story changed substantially, with Ambassador Labs folding the commercial edition into its Blackbird platform in 2025 before being acquired by Gravitee, a shift that pushed many teams to [reevaluate the Telepresence-style toolchain](https://www.signadot.com/blog/the-ultimate-guide-to-telepresence-alternatives-in-2025/). Operationally, the daemon requires elevated privileges for network configuration, and virtual private network (VPN) software on corporate machines is a recurring source of conflict with its network interface. - [mirrord](https://mirrord.dev/), from MetalBear, takes a process-level approach instead of a network-level one. It injects a layer into your local process that hooks system calls, so the process reads the target pod’s environment variables and files and receives mirrored or stolen traffic through an in-cluster agent, without a VPN-style interface or root access. Its enterprise edition adds header-based traffic filtering so multiple engineers can share one target. - [Gefyra](https://gefyra.dev/) takes a related approach for containerized local workloads, bridging local containers into the cluster network. - Signadot connects the workstation to the cluster through an authenticated tunnel and applies the same run-one-service-locally pattern, with the difference that the connection is expressed as a sandbox, a declarative unit the platform manages, rather than an ad hoc intercept. How that model handles many concurrent developers is covered in the sharing section below, and the practical differences from Telepresence and mirrord are broken out in the [Telepresence](https://www.signadot.com/comparison/telepresence/) and [mirrord](https://www.signadot.com/comparison/mirrord/) comparison pages. The strengths of this category are exactly what Options 1 and 2 lack. The feedback loop is a local process restart, seconds rather than a rebuild cycle. Dependencies are the real services at their current versions, with real data and real configuration, so mock drift disappears for everything you did not change. Laptop resource use is one service instead of fifty. The costs are organizational more than technical. There must be a shared cluster that reflects production, and someone must own keeping it healthy, typically a platform team. And once more than a handful of developers connect to the same cluster, their changes can collide, one developer’s modified service answering another developer’s requests. Solving that collision problem is what separates the tools in this category at team scale, and it is where this guide ends up in the final section. #### Option 4: Cloud development environments (CDEs) The fourth approach relocates the development workspace itself. Cloud development environments, often shortened to CDEs and also called remote development environments, give each engineer, or each task, a cloud machine holding the source tree, toolchain, and editor backend, accessed from a thin client or the browser. - [GitHub Codespaces](https://github.com/features/codespaces) provisions per-branch cloud machines defined by devcontainer configuration. It is not Kubernetes-aware by itself, so teams either run kind or minikube inside the workspace or point it at a remote cluster, inheriting the tradeoffs of whichever they choose. - [Coder](https://coder.com/) is a self-hosted platform that provisions workspaces on your own infrastructure from Terraform templates, aimed at organizations that want development environments behind their own network boundary, and increasingly at running fleets of coding agents inside them. - [Ona](https://ona.com/), formerly Gitpod, provisions ephemeral cloud development environments defined as code, with prebuilt workspaces that start in seconds, and has expanded toward orchestrating fleets of coding agents in those same environments. CDEs fit teams that value fast onboarding, standardized toolchains, and code never residing on laptops, which matters in regulated environments. They also fit the emerging pattern of running many coding agents, since agents need environments provisioned programmatically and laptops are not where that happens. What a CDE does not do is answer the testing question. It moves the development environment into the cloud, and nothing else: the services your code depends on still have to run somewhere, and that somewhere is still one of the first three options, a local cluster inside the workspace, a sync tool pointed at an isolated namespace, or a connection to a shared cluster. Choosing a CDE changes where you develop, not how you validate, so the test environment decision remains open and just as consequential as before. #### Choosing an approach: cost, quality, and speed Strip away the tooling details and every Kubernetes development environment is a position on three dimensions. **Speed** is the pace of the inner loop: the time from saving a change to seeing it behave, including any waiting on rebuilds, provisioning, or other people. **Quality** is the fidelity of the signal: how well a pass in the development environment predicts a pass in production. **Cost** is what the environment consumes in infrastructure spend and platform upkeep, multiplied by every person and coding agent that needs one. No traditional setup delivers all three. Each of the standard positions sacrifices a different dimension to get the other two. Speedfast feedbackCostcheap to runQualityhigh fidelityLocal environmentsquality lost to mocksDuplicated environmentscost explodes per copyShared stagingspeed lost to queueingMulti-tenantshared clusterspeed, quality, and cost Traditional setups pick two of the three dimensions and sacrifice the third. A multi-tenant shared cluster is the position that holds all three. Speedfast feedbackCostcheap to runQualityhigh fidelityLocal environmentsquality lost to mocksDuplicated environmentscost explodes per copyShared stagingspeed lost to queueingMulti-tenantshared clusterspeed, quality, and cost Traditional setups pick two of the three dimensions and sacrifice the third. A multi-tenant shared cluster is the position that holds all three. **Local environments choose speed and cost.** Everything from Docker Compose to a kind cluster on your machine (Option 1) is free to run and fast to iterate in. Quality is what gets sacrificed: past a handful of services, most dependencies must be mocked or seeded, and the mocks drift from reality as the real system ships. The faster the organization ships, the faster that drift accumulates. Event-driven and data-heavy systems feel it earliest, because brokers like [Kafka](https://kafka.apache.org/) and realistic datastores are exactly what mocks and seed scripts reproduce worst. **Duplicated environments choose speed and quality.** Give every developer a private copy of the system, a namespace each in the sync tool model (Option 2) or a full cluster each, and iteration is fast against real dependencies with nobody contending. Cost is what gets sacrificed, and it scales the wrong way: linearly with the number of environments. That was survivable when one engineer meant one environment. In the agentic era it is not. Each engineer now runs multiple coding agents producing changes in parallel, every agent needs its own environment to validate in, and duplication multiplied by agents produces a number no budget approves. **Shared staging chooses cost and quality.** One live, continuously deployed copy of the system is the cheapest high-fidelity environment an organization can operate, which is why nearly every organization has one. Speed is what gets sacrificed: with no isolation between changes, developers queue to validate their work, contend for the environment, and a single broken deploy blocks everyone behind it. Connecting laptops to a shared cluster (Option 3) inherits exactly this failure mode once more than a handful of developers connect at the same time, unless something keeps their changes from colliding. Cloud development environments (Option 4) do not occupy a corner of this triangle at all. They relocate the workspace and then inherit whichever position they are paired with, so adopting a CDE still means choosing among the three positions above, or the fourth one below. The fourth position is the center of the triangle: share one live environment and make it multi-tenant, so every change is isolated inside it and sharing does not mean colliding. That keeps the shared model’s cost and quality while removing the queue that made it slow. The final section covers how it works. First, the summary: Approach Cost Quality Speed Breaks down when Local environment (local cluster or Compose) Low. Laptop only Low. Mocked dependencies drift from reality High. Everything at hand The system outgrows the laptop and mocks outnumber real services Environment per developer (sync tools, namespaces) High. One system copy per developer or agent High. Real dependencies in every copy High once provisioned. Copies drift between syncs Copy count multiplies with the team, then again with coding agents Shared staging without isolation Low. One environment for everyone High. Real and continuously deployed Low. Queueing and contention Every concurrent change fights for the same environment Multi-tenant shared cluster Low. One environment plus one service instance per change High. Real dependencies at current versions High. Local process restart, no queue Services do not propagate trace headers Cloud development environment Per-seat workspace pricing Set by the paired approach Set by the paired approach The test environment question is still open #### Getting all three: a multi-tenant shared cluster Every path through the trilemma points at the same destination. A shared cluster is already the cheapest environment an organization runs and the highest-fidelity one. The only thing wrong with it is contention, and contention is fixable. The fix is to make the shared environment multi-tenant, isolating each change inside it rather than duplicating infrastructure around it. For the synchronous traffic between services, isolation works at the request level. The cluster runs one stable version of every service, continuously deployed. A developer working on a change runs only the modified service, typically as a local process under a debugger, registered as an additional version alongside the stable one. Requests carry a routing key in a header, propagated across service hops through standard context propagation such as [OpenTelemetry baggage](https://opentelemetry.io/docs/concepts/signals/baggage/) or [B3 headers](https://github.com/openzipkin/b3-propagation), and the routing layer sends requests tagged with your key to your modified service while all other traffic flows through the stable versions. SHARED CLUSTER · ONE STABLE VERSION OF EVERY SERVICEAB · stableB · modifiedCkeyno keyrouting key propagated in headers across hops Request-level isolation: one live system, with each change reachable only by requests that carry its key. keyno keySHARED CLUSTERAB · stableB · modifiedCrouting key propagated in headers Request-level isolation: one live system, with each change reachable only by requests that carry its key. Measured against the three dimensions, this is the center of the triangle rather than another compromise: - **Cost stays low.** The whole team, and its coding agents, share one cluster. Each concurrent change adds one service instance, not one system copy, so the marginal cost of the fiftieth simultaneous change is a single process. - **Quality stays high.** Every dependency is the real service at its current version, with real data and real configuration. Nothing is mocked, so nothing drifts. - **Speed stays high.** The inner loop is a local process restart, seconds rather than a rebuild or a redeploy, and there is no queue, because requests isolated by key cannot collide with anyone else’s changes. Two requirements follow from the mechanism. Services must [propagate trace context headers](https://www.signadot.com/docs/guides/set-up-context-propagation), which most teams already have through distributed tracing instrumentation. And something in the data path must make routing decisions per request, either an existing service mesh or dedicated sidecars. ##### How Signadot implements the pattern Signadot packages this model as its core primitive. A [sandbox](https://www.signadot.com/docs/concepts/sandbox) is a lightweight environment defined declaratively, holding the changed version of one or more services while everything else resolves to the stable versions in the shared cluster. For local development specifically, [the CLI connects your workstation to the cluster](https://www.signadot.com/docs/tutorials/quickstart/local-development) over an authenticated tunnel, cluster service names resolve from the laptop as if the process were running inside the cluster, and the sandbox maps an in-cluster workload to the local process, pulling down its environment variables and files so the local service starts with in-cluster configuration. Requests carrying the sandbox’s routing key reach the laptop, and all other traffic never sees it. Control planeauth and SSOYOUR LAPTOPmodified serviceSignadot CLItunnelKUBERNETES CLUSTERSignadot Operatorsvc Asvc Bsvc Csidecarroutingsandboxmaps svc B to the local process The sandbox maps one in-cluster workload to the process on your laptop. Only requests with its routing key are sent down the tunnel. Control planeauth and SSOKUBERNETES CLUSTERSignadot Operatorsidecar routingsvc Asvc Bsvc Csandboxmaps svc B to the local processtunnelYOUR LAPTOPmodified serviceSignadot CLI The sandbox maps one in-cluster workload to the process on your laptop. Only requests with its routing key are sent down the tunnel. [Routing](https://www.signadot.com/docs/guides/request-routing) runs through a built-in sidecar or through an existing [Istio](https://istio.io/) or [Linkerd](https://linkerd.io/) mesh. [Route groups](https://www.signadot.com/docs/reference/route-groups/spec) combine multiple sandboxes under a single routing key, so a change spanning several services, some local and some in-cluster, tests as one unit. Access flows through a central control plane with single sign-on rather than through per-developer cluster credentials, which keeps the shared cluster workable for teams that must keep credentials and data centrally controlled. Request routing is only the mechanism for synchronous traffic, not the whole model. For [message queues like Kafka](https://www.signadot.com/docs/guides/set-up-message-queue-isolation), isolation moves into the messages themselves: routing keys carried in message headers decide whether the stable consumer or a sandboxed one processes each message. For databases, sandboxes take [different approaches](https://www.signadot.com/docs/guides/set-up-data-isolation) depending on the engine and the isolation a change needs, from an ephemeral schema or instance per sandbox to branches on copy-on-write databases like [Neon](https://neon.com/). And because these mechanisms sit on an [extensible plugin framework](https://www.signadot.com/docs/reference/resource-plugins), any system in the stack, including internal ones no vendor ships support for, can be made multi-tenant in the same shared environment rather than duplicated alongside it. The same primitives serve the [local development workflow](https://www.signadot.com/solutions/local-development/) and the pull request validation workflow described in the [ephemeral environments guide](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), so the environment a developer debugs in and the environment CI validates in are the same kind of thing. The honest tradeoffs run in the same directions as the rest of Option 3. There is an operator to run and a platform team decision to make, header propagation is a prerequisite, and isolating shared state like databases and message queues requires explicit configuration per resource rather than coming free with the routing. Teams whose systems are small enough to hold on a laptop do not need any of it yet. Develop locally against your real cluster Signadot connects your laptop to a shared Kubernetes cluster so you can run one service under your debugger while every dependency stays real, with sandbox isolation keeping your changes invisible to the rest of the team. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Related reading - [Local development solution overview](https://www.signadot.com/solutions/local-development/) - [Ephemeral environments in Kubernetes: the complete guide](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) - [The ultimate guide to lightweight Kubernetes environments](https://www.signadot.com/articles/the-ultimate-guide-to-lightweight-kubernetes-environments/) - [Local vs remote Kubernetes development environments](https://www.signadot.com/blog/local-kubernetes-dev-environments/) - [The ultimate guide to Telepresence alternatives](https://www.signadot.com/blog/the-ultimate-guide-to-telepresence-alternatives-in-2025/) - [Signadot vs Telepresence](https://www.signadot.com/comparison/telepresence/) and [Signadot vs mirrord](https://www.signadot.com/comparison/mirrord/) #### Frequently asked questions What is the best way to develop locally against a shared Kubernetes cluster? Run only the service you are changing on your machine and connect it to the cluster with a tool that routes requests by header, so your changes are isolated from other developers using the same cluster. Telepresence, mirrord, and Signadot all implement variants of this, differing in connection mechanics, concurrency handling, and how much platform tooling surrounds the core workflow. Can I run Kubernetes locally on my laptop? Yes. minikube, kind, k3s, and Docker Desktop all run real clusters on a development machine, and they are the right choice for small systems and for platform-level work like operators and Helm charts. The limit is system size, since a laptop cannot hold a large microservices deployment with its datastores, so most teams outgrow purely local clusters as the service count climbs into the tens. Do I need a service mesh to share a development cluster? No. Header-based routing needs something making per-request decisions in the data path, and an existing Istio or Linkerd mesh can serve that role, but platforms in this space also ship their own lightweight sidecar routing for clusters without a mesh. The harder requirement is context propagation, since services must forward tracing headers for routing keys to survive multi-hop calls. Should every developer get their own namespace instead? Per-developer namespaces work at small scale and are the natural first architecture to try. Their cost grows linearly with team size, each copy takes minutes to provision and drifts from the live system between syncs, and datastores and third-party dependencies usually end up shared anyway. Teams typically move to request-routed sharing of one environment when the namespace fleet's cost or staleness becomes visible. Is Docker Compose good enough for Kubernetes development? For a small number of services it is often the fastest loop available, and that speed is worth real fidelity costs. What Compose cannot reproduce is cluster behavior, including service discovery, ConfigMaps and secrets, resource limits, ingress, and sidecars, so services pass locally and fail in the cluster for environment reasons. Teams usually pair it with a real cluster stage or replace it once those failures become frequent. Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Staging Environment Challenges: The Bottleneck and How to Fix It Source: https://www.signadot.com/blog/the-staging-bottleneck-why-your-engineering-team-is-slow-and-how-to-fix-it/ Summary: Why one shared staging environment becomes the bottleneck for scaling teams, how per-PR sandboxes on a staging baseline remove the contention, and how request-level isolation cuts Kubernetes test environment costs. ### Staging Environment Challenges: The Bottleneck and How to Fix It Staging was meant to ensure quality, but for many teams it has become the biggest blocker: fragile, shared, and constantly breaking under parallel work. Now that AI coding agents generate far more code, that single shared environment is the main thing slowing teams down. Here is why it no longer scales, and how per-pull-request sandboxes fix it for developers and agents alike. Reading time 14 min Author Arjun Iyer Published September 4, 2025 Updated August 31, 2026 Topics [Ephemeral Environments](https://www.signadot.com/blog/category/ephemeral-environments/) A few weeks ago, I had a conversation that I can’t stop thinking about. I was talking to a Director of Engineering who leads a 100-person team, and I asked him about his biggest development bottleneck. I expected to hear the usual suspects: CI/CD performance, code review cycles, or maybe deployment complexity. His answer was immediate and emphatic: “It’s the staging environment”. He went on to describe a scenario that is painfully familiar to anyone who has worked in a scaling engineering organization. “We have one staging environment,” he said. “At any given time, 3-4 teams are trying to push their changes in for testing. It’s constantly breaking, and we spend hours trying to figure out whose change caused the issue”. I summed it up: “So it’s a race to merge, followed by a blame game?”. “Exactly,” he confirmed. “Devs get frustrated. QA gets blocked. We either delay releases or ship things with less confidence because we couldn’t get a clean testing window”. This story was so resonant that I shared it on LinkedIn. The reaction was overwhelming, sparking a massive discussion with hundreds of comments from engineers, architects, and leaders across the industry. It was clear this wasn’t an isolated problem; it’s a classic scaling challenge that I’ve seen grind velocity to a halt at countless companies. The traditional model of a single, shared, long-lived staging environment simply breaks down under the pressure of multiple teams moving in parallel. It creates a zero-sum game where one team’s progress often comes at the expense of another’s. The very environment meant to ensure quality becomes the biggest single point of failure and contention. Our [complete guide to staging environments](https://www.signadot.com/staging-environments/) covers what the stage is actually for, the three ways the shared copy fails, and the four alternatives compared. But what if we could fundamentally change the game? #### **The usual workarounds, and why they don’t scale** High-performing teams deploy code [973 times more often](https://cloud.google.com/resources/state-of-devops) than low performers, so the pressure on a single shared environment is relentless. (If you are still standing up the environment itself, start with our guide to [Kubernetes staging environments](https://www.signadot.com/blog/kubernetes-staging-environment/).) Before teams rethink the model, they usually try to manage that pressure. None of these workarounds holds up as the team grows: - **Locking staging.** Someone posts “locking staging for the next hour, do not touch” in Slack. Fine for a team of three. Past that it just turns testing into a queue, and the next team still has to reconcile against whatever you merged. - **Cloning staging.** Give each team its own copy. Now you are paying to run, and to keep in sync, several near-production environments. Before long you need a “staging 2” just to test how the clones behave together. - **Spinning up more lower environments.** This is like solving a traffic jam by building more highways. It helps for a week, then you have the same contention at a larger scale, plus mocks standing in for third-party services and a synchronization nightmare. - **Leaning on mocks.** Quick to start, but mocks drift from the real services they imitate, and the false confidence they create is its own source of bugs. (More on that in [why developers shouldn’t write mocks](https://www.signadot.com/blog/why-developers-shouldnt-write-mocks-a-guide-to-modern-testing/).) *Image: Spinning up more lower environments is like solving a traffic jam by building more highways* The irony is that each of these, in trying to fix staging, creates a new problem. What teams need is not more environments. It is a smarter way to use the one they have. #### **A New Mental Model: From Scarcity to Abundance** The old model is built on scarcity, one environment that everyone must share and fight over. The new model is one of abundance. The solution is to give every developer a personal, ephemeral “sandbox” for their feature within the _same_ shared environment. This isn’t about duplicating your entire stack a hundred times over. That would be a cost and complexity nightmare, a valid concern many people raised in the discussion. Instead, the modern approach is far more elegant and efficient. Through [smart request routing](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), we can isolate each developer’s changes from everyone else’s, even though they share the same underlying infrastructure. Imagine Developer A is working on a feature. They can deploy their pull request into a personal sandbox, a [preview environment](https://www.signadot.com/solutions/preview-environments/) that exists just for that change. When they send a test request to the staging cluster with a specific header, the request is intelligently routed to their modified service. For all other dependencies, the request is routed to the stable, baseline services running in the main staging environment. This means Dev A can test their PR without ever being affected by Dev B’s work, and vice-versa. The analogy to source control is almost perfect. The main staging environment is your trunk or main branch, the stable baseline. Each developer’s sandbox is like a feature branch, isolated and independent until you’re ready to merge. Our [guide to microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/) walks through this model end to end. The results we’re seeing from this shift are profound: - **Testing Contention:** Eliminated. - **Environment-Related Release Delays:** Down by over 90%. - **Time Spent Debugging “Who Broke Staging”:** Near zero. The Director’s follow-up question perfectly captured the promise of this new model: “You mean my teams can test in parallel without stepping on each other’s toes?”. Yes. That’s the power of modern development infrastructure. #### **Answering the Hard Questions from the Community** The vibrant online discussion that followed my post surfaced a number of valid and challenging questions. For this approach to be viable, it has to hold up to real-world scrutiny. Let’s tackle the most common discussion topics head-on. ##### **Discussion 1: “This only works if you don’t have shared resources like a database.”** This was, by far, the most critical counterpoint. One commenter articulated the problem perfectly: even with temporary environments, you cannot spin up a temporary database with large test datasets for every developer, so “all these environments end up sharing the same database”. This becomes a huge issue, “especially when a developer needs to make schema changes that are not backward compatible”. This is absolutely correct. The data layer is a crucial piece of the puzzle. The solution requires a multi-faceted approach: 1. **For Most Cases, Share the Database:** For the majority of changes that don’t involve schema modifications, sandboxes can share the main staging database. This works well as long as teams follow best practices, such as not mutating data they didn’t create. The rich, representative data in a shared staging database is incredibly valuable for testing. 2. **For Schema Changes, Isolate the Database:** For cases where full data isolation is required, you must spin up a temporary database with the sandbox. This could be a containerized DB, a separate schema, or a branch if you’re using a modern database that supports it. This temporary DB can be seeded with a snapshot of production data to ensure realistic testing. 3. **Automate the Cleanup:** A valid concern was the cost and complexity of managing these temporary resources, with developers potentially leaving them running after a merge. The key is automation. These temporary resources must be linked to the lifecycle of the sandbox itself. When a sandbox is deleted (either automatically on PR merge, via a TTL, or manually), the associated temporary database is automatically cleaned up with it. ##### **Discussion 2: “This sounds expensive and complex to set up.”** Many commenters worried about the infrastructure costs and setup complexity of ephemeral environments. One was blunt, suggesting “it increases costs a gazillion times”. This is a misconception rooted in the traditional approach to ephemeral environments, where you duplicate the entire stack. The sandbox model I’m proposing is fundamentally different and far more cost-efficient. You are not cloning 15+ services for every developer. You are only spinning up pods for the 1-2 services that are actually changing in a given PR. The rest of the stack is shared. The cost of running a few extra pods in your Kubernetes cluster is minimal compared to the staggering cost of developer downtime, blocked QA teams, delayed releases, and hours spent in “blame game” war rooms. The long-term savings in developer productivity far outweigh the infrastructure costs. As for complexity, building this from scratch is indeed a significant undertaking. You’d need to manage shadow deployments, integrate with a service mesh for routing, handle header propagation via OpenTelemetry, and build a system for spinning up temporary resources. This is precisely why we built Signadot, to provide this capability as a managed platform so teams can focus on their own products. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) ##### **Discussion 3: “Doesn’t this just kick integration problems down the road to production?”** Several people argued that by testing in isolation, you miss the very integration issues that staging is meant to catch. They suggested this might “shift the integration pain to the right” and that “If the changes are still separated, you don’t know if they work _together_ when you push them to production”. This is a critical point, and it highlights a misunderstanding. This approach does **not** eliminate the staging environment or the need for integration testing. It supercharges it. The goal is to “shift left”, to find and fix as many bugs as possible _before_ code is merged into the main branch. By performing integration testing against a stable baseline in a pre-merge sandbox, you gain a high degree of confidence. Post-merge testing on the main staging environment becomes much shorter and smoother because you’ve already ironed out the majority of issues. Furthermore, what if a single feature requires changes across multiple PRs from different teams? Sandboxes can be grouped together, allowing you to test a collection of interdependent PRs as a single, cohesive feature before any of them are merged. You’re still performing integration testing, but you’re doing it earlier, faster, and in a controlled, isolated manner. ##### **Discussion 4: “Why not just fix the process? Use Trunk-Based Development, better CI, or run everything locally.”** A number of comments suggested this was a process or architecture problem, not an environment problem. Suggestions included Trunk-Based Development (TBD), better CI pipelines, or simply having developers run everything on their local machines. While all these practices have value, they don’t fully solve this specific problem at scale: - **Local Development:** Running a complex, distributed system with 20+ microservices, databases, message queues, and cloud resources locally is often impossible. As your system grows, local development can’t replicate the production environment’s complexity, leading to the dreaded “it works on my machine” scenario. - **Trunk-Based Development:** TBD is a fantastic practice, but it’s orthogonal to the issue of testing. You still need a way to validate changes before they land on the trunk, especially when those changes have complex interactions with other services. This sandbox approach provides a powerful way to do pre-merge validation, which perfectly complements TBD. - **Fixing the Architecture:** While better architecture and loose coupling are always good goals, even well-architected systems have dependencies. The need to test how services interact doesn’t disappear. The bottleneck isn’t just about code; it’s about providing a realistic, scalable environment for integration testing. #### **How Uber, Lyft, and DoorDash actually solved it** This is not theoretical. The companies that hit microservices scale first all landed on the same answer: isolate the change, not the whole environment. - **Uber** built SLATE (Short-Lived Application Testing Environment), which lets developers spin up on-demand environments that talk to production instances of their dependencies instead of standing up a full stack each time. - **Lyft** built a control plane for its shared development environment. As its engineering team put it, “instead of providing fully isolated environments, we isolated requests within a shared environment.” That one sentence is the whole idea. - **DoorDash** built a fast feedback loop that lets developers test Kubernetes changes against a realistic environment without waiting on a shared one. The instinct to “just run everything locally” does not scale either. As distributed-systems engineer Cindy Sridharan [observed](https://copyconstruct.medium.com/testing-microservices-the-sane-way-9bb31d158c16), “trying to spin up the full stack on developer laptops is fundamentally the wrong mindset to begin with.” Modern systems are too interconnected: a failure in one service, say payments, often surfaces as a bug in another, like orders, which is what makes interdependencies the hard part of testing. *Image: An e-commerce microservices architecture, where payment, orders, shipping, and other services all depend on each other* The payoff is measurable. AWS [documented](https://aws.amazon.com/blogs/enterprise-strategy/business-value-of-developer-experience-improvements-amazons-15-9-breakthrough/) a 15.9% year-over-year cost reduction and 433% three-year ROI from developer-experience improvements, and Gartner [expects](https://devops.com/platform-engineering-the-2024-game-changer-in-tech/) 80% of large engineering organizations to run platform-engineering teams by 2027, up from 45% in 2022. What once took a dedicated platform team at Uber or Lyft to build is now available off the shelf, so teams of any size can adopt the same request-isolation model today. #### **The staging bottleneck just got bigger: now AI is writing the code** Since I first wrote this, the ground has shifted. A large and growing share of code is now written by AI coding agents like Claude Code, Codex, and Cursor. A single engineer can open more pull requests in a day than a small team used to open in a week. The part we spent a decade trying to speed up, writing the code, is no longer the thing holding us back. The constraint has moved downstream, to validation. When an agent produces ten changes in the time it used to take to hand-write one, every one of those changes still has to be proven correct against the rest of the system. For a cloud-native application that means running it in a realistic environment with its real dependencies, and that is exactly where the old staging model buckles. A laptop cannot hold the full stack, so local testing stays low fidelity. Shared staging can hold it, but now it has even more changes queued for the same single lane. The faster agents write, the longer the line for staging gets. This is why the sandbox model matters more now than when I first described it. Agents do their best work when they can close the loop themselves: make a change, test it against real dependencies, read the result, and try again, without waiting on a person or a shared environment to free up. A per-pull-request sandbox gives them exactly that, an environment that is quick and cheap to create but still high fidelity because it runs against the real baseline. The same request-level isolation that lets a hundred developers test in parallel lets a fleet of agents work at once without stepping on each other. An environment on its own is only half the answer. To let agent-written code merge with confidence, you need a validation layer sitting on top of it. At Signadot that layer is Sandboxes for the environment, plus [SmartTests](https://www.signadot.com/docs/concepts/smart-tests-and-jobs), [Jobs](https://www.signadot.com/docs/reference/jobs), and [Plans](https://www.signadot.com/docs/reference/plans) for the checks that run inside it. SmartTests catch behavioral regressions by comparing the baseline against the change, Jobs run the test suites you already trust against the sandbox, and Plans tie them into one repeatable workflow an agent can run and act on. Together they take a change all the way from generated to verified. I wrote up the longer version of this argument in [validating AI-generated code on Kubernetes](https://www.signadot.com/validate-ai-generated-code-kubernetes/). None of this replaces the staging environment or the integration testing it stands for. It does what shifting left always promised: it moves validation earlier, makes it cheap enough to run on every change, and keeps it high fidelity. For where sandboxes fit in the full lifecycle, see our complete guide to [microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/). That was worth doing when humans wrote the code. Now that agents write most of it, it is the difference between shipping faster and drowning in unverified pull requests. #### **The Way Forward: Platform Thinking and Empowered Teams** Ultimately, solving the staging bottleneck is about more than just tools; it’s a cultural shift. It’s about moving from a rigid, sequential process to a flexible, parallel one. It requires adopting a platform engineering mindset, where the platform team provides self-service tools that empower feature teams to move faster. Instead of a centralized gatekeeper (the staging environment), you create an ecosystem where every developer and every PR gets an isolated slice of the testing workflow, on-demand. The blame game disappears, confidence goes up, and teams can finally realize the core promise of microservices: the ability to develop, test, and ship smaller code changes to production independently and rapidly. The journey from a congested, single-lane road to a multi-lane superhighway for development is challenging, but the destination, faster releases, higher quality, and happier developers, is more than worth the effort. How does your team manage the staging environment bottleneck? I’m keen to hear your strategies. #### Frequently asked questions How do teams share one staging environment without blocking each other? With request-level isolation on the shared baseline. Each change runs in a sandbox that deploys only the services it modifies, requests carrying that sandbox's routing key are steered to the new versions, and everything else uses the baseline. Teams and coding agents test in parallel on the same cluster without queueing or stepping on each other's changes. Why does staging break so often in a microservices organization? Because dozens of teams deploy half-finished changes into one long-lived environment. Any single bad deploy blocks everyone, failures are hard to attribute across overlapping changes, and the environment drifts from production over time. The fix is to keep the baseline continuously deployed from the main branch and move per-change testing into isolated sandboxes instead of deploying unmerged code into the shared environment. How do you make test environments match production more closely? Stop cloning environments and test on a continuously deployed shared baseline instead. A baseline that tracks the main branch with production-like configuration stays current by construction, and sandboxes on top of it give each change isolation without drift. Cloned environments, by contrast, start diverging from the moment they are created. How do you reduce the cost of Kubernetes test environments? Replace per-team or per-PR copies of the stack with request-level isolation on one shared cluster, so each test environment deploys only the services that changed. Teams that make this switch report 85 to 90 percent lower test-infrastructure cost, and Brex saves about $2 million annually after replacing duplicated environments with sandboxes. #### Related Posts *Image: How Uber & DoorDash empower developers to preview every code change in production* ephemeral-environments cases ##### How Uber & DoorDash empower developers to preview every code change in production June 23, 2023 *Image: The Pitfalls of Using Feature Flagging for Testing in Shared Staging Environments* ephemeral-environments ##### The Pitfalls of Using Feature Flagging for Testing in Shared Staging Environments July 9, 2023 *Image: Why Environment Replication Doesn’t Work for Microservices Testing* ephemeral-environments ##### Why Environment Replication Doesn’t Work for Microservices Testing October 25, 2024 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Kubernetes Staging Environments: How to Build, Run, and Share One Source: https://www.signadot.com/blog/kubernetes-staging-environment/ Summary: An opinionated guide to staging on Kubernetes: why most companies need exactly one pre-production environment, a reference architecture and data strategy, staging SLOs, and how test tenants share one environment safely across services, message queues, and databases. ### Kubernetes Staging Environments: How to Build, Run, and Share One An opinionated guide to staging on Kubernetes: why most companies need exactly one pre-production environment, how to build and operate it like a product with SLOs, and how test tenants let every developer and coding agent share it safely. Reading time 9 min Author Arjun Iyer Published July 17, 2026 Updated July 18, 2026 Topics [Ephemeral Environments](https://www.signadot.com/blog/category/ephemeral-environments/) **A Kubernetes staging environment** is a pre-production cluster, or a dedicated slice of one, that mirrors production closely enough that a change passing there is expected to be safe to ship. It is where integration bugs are supposed to die. This guide is the operations manual: how to build staging, how to run it like a product with SLOs, what your data strategy should be, and how to share one environment across every team and coding agent without the usual queueing and breakage. #### What staging is for Staging exists to answer one question with high confidence: will this change work in production? Unit tests and mocks cannot answer it, because in a microservices system most failures live in the interactions, the real datastores, the real message queues, and the real configuration. A good staging environment is the first place a change meets all of those at once. For the wider picture of where staging sits among dev, QA, UAT, and pre-production, and why the single shared copy stops working at microservices scale, see the [complete guide to staging environments](https://www.signadot.com/staging-environments/). That gives you the design principle for everything below: staging earns its keep exactly to the degree that it resembles production and stays current. Every decision that follows, cluster layout, data, sync strategy, sharing model, is in service of that fidelity. #### How many environments do you need before production? This is the question we hear most often, so here is the opinionated answer: for most companies, one. The traditional ladder of dev, QA, staging, and preprod exists mostly as a workaround for unsafe sharing. Each rung was added because the previous environment got too crowded or too broken to trust, and each rung costs real money, drifts from production on its own schedule, and adds a hop between a developer and the truth. Teams do not actually want four environments; they want four moments of isolation, and cloning infrastructure was historically the only way to get them. It no longer is. If one staging baseline can be shared safely, with every change getting its own isolated slice (more on how below), the intermediate rungs stop paying rent. One environment to keep in sync means one environment that is actually in sync, and the money saved on the ladder funds making that single environment excellent. The honest exceptions are specialized environments with a narrow job: sustained load and performance testing that would disturb functional testing, compliance or certification environments that regulators require to be frozen, and the occasional hardware-specific rig. Keep those when they earn their place. What you should not keep is a general-purpose dev or QA clone whose only justification is that staging is too contested to use. #### A reference architecture for staging on Kubernetes Run staging in its own cluster rather than a namespace inside production, so a bad deploy, a runaway job, or a misconfigured operator can never reach production. From there, the architecture question is what to copy exactly and what to shrink. The rule: scale down capacity, never fidelity. Safe to scale down: - **Replica counts.** Two replicas prove the same things twenty do, including that the service survives a pod restart. - **Node size and pool count.** Test traffic is a trickle next to production load. - **Off-hours capacity.** Autoscale toward zero on nights and weekends; non-production environments are a large share of most cloud bills, and idle staging capacity is the easiest cut in the budget. Never cut: - **The Kubernetes version and add-ons.** Same minor version, same service mesh, same ingress controller, same operators. Version skew here is a class of production surprise you paid for staging to catch. - **The configuration shape.** Same ConfigMap and secret layout, same resource limit patterns, same network policies. A change that breaks on config should break in staging. - **The dependency graph.** Real datastores, real message queues, real third-party integrations in test mode. The moment a dependency becomes a mock, deploy-time bugs get a place to hide. #### The promotion pipeline: staging tracks main Deploy to staging through the same GitOps or CI/CD path that deploys to production, promoting the same artifacts, automatically on every merge. Hand-applied manifests are how configuration drift starts, and [drift is what makes staging results untrustworthy](https://www.signadot.com/blog/the-staging-bottleneck-why-your-engineering-team-is-slow-and-how-to-fix-it/). Automatic sync matters more than teams expect. A staging environment that is three days behind main is testing a system that no longer exists, and every test that passes against it is a small lie. Measure the gap explicitly: sync lag, counted in merges behind main, should hover near zero. #### A data strategy in three tiers Most deploy-time surprises come from data and dependencies, not code, so an empty database is a fidelity hole. In practice you need three tiers, applied per datastore: 1. **Synthetic seed data** for the baseline: generated fixtures that match production’s schema and shape. Cheap, safe, and good enough for most functional testing. 2. **Anonymized production snapshots** on a refresh schedule for the datastores where distribution matters: the search index whose relevance depends on real cardinality, the orders table whose edge cases only production has generated. Anonymize on export, refresh on a cadence you alert on, because stale snapshots drift like everything else. 3. **Ephemeral per-change databases** for destructive work: schema migrations and data rewrites get a temporary database or schema provisioned for the change and destroyed after, so the shared baseline’s data stays trustworthy. Tier three is also where sharing gets interesting, which is the next-but-one section. #### Give staging an SLO Here is the reframe that separates teams whose staging works from teams whose staging is a running joke: treat staging as a product with an SLO, not a shared resource with a Slack channel. Three numbers cover it: - **Baseline-green rate**: the percentage of time the staging baseline passes its smoke checks. If this is not alerted on, staging breakage becomes something developers discover, one wasted afternoon at a time. - **Sync lag**: merges behind main, as above. Target near zero; alert past a handful. - **Time-to-test**: how long a developer or coding agent waits between wanting to validate a change and having an environment for it. This is your earliest bottleneck signal, and when it starts stretching, the sharing model, not the cluster size, is usually what needs to change. Put the three on a dashboard, page someone when baseline-green drops, and staging stops being a joke. None of this is heavy: the smoke checks already exist in most CI setups, and the sync lag is a one-liner against the Git history. #### Sharing staging: the test tenant model Now the part the rest of this guide has been building toward. One excellent staging environment is only viable if many teams, and now fleets of coding agents, can use it at once without corrupting it for each other. Locks, calendars, and clones all fail at this in familiar ways: locks become queues, calendars make testing a scarce resource, and clones resurrect the environment ladder you just tore down. (Our [guide to microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/) compares these sharing models in depth.) The model that works is the **test tenant**: each change in flight gets a [logical tenant on the shared baseline](https://www.signadot.com/solutions/kubernetes-test-environments/), identified by a routing key. The tenant is not a copy of anything. It is a thin overlay, only the services the change touches get deployed as sandboxed workloads, and the routing key makes the overlay behave like a private environment across every kind of interaction: - **Synchronous services** use request routing. The routing key travels in request headers via context propagation, and the mesh or a lightweight proxy steers any request carrying the key to the sandboxed version of a changed service. Everything else flows to the baseline. - **Asynchronous flows** use selective consumption, because a message queue has no request path to route. Messages produced under a tenant carry the routing key in their metadata, and sandboxed consumers process only their tenant’s messages while baseline consumers skip them. The same pattern covers [Kafka, SQS, and other brokers](https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/) and [Google Pub/Sub](https://www.signadot.com/blog/tutorial-how-to-do-end-to-end-testing-of-asynchronous-google-pub-sub-flows-using-sandboxes/). - **Databases and stateful dependencies** use tunable isolation. Most tenants read and write the shared baseline datastores, which is exactly the fidelity you want. A tenant doing destructive work gets its own ephemeral database or schema, provisioned through [resource plugins](https://www.signadot.com/docs/concepts/resources) for the tenant’s lifetime. One concept, applied to every interaction type. That is what makes it powerful: the tenant boundary is logical, so its marginal cost is near zero and hundreds can coexist on one cluster, yet every tenant tests against the real baseline, so fidelity is not traded away for isolation. Isolation stops being something you buy with infrastructure and becomes something the platform grants per change. This is the model behind a [Kubernetes sandbox](https://www.signadot.com/kubernetes-sandbox/), and the request-level isolation approach covered in our guide to [ephemeral environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/); nothing about it removes staging. The baseline is still there and still synced. What disappears is the contention over it, which matters twice as much now that coding agents multiply the number of changes needing a production-like environment at the same time. #### Best practices checklist - Run staging in its own cluster, matched to production’s version, add-ons, and config shape. - Scale down replicas, node sizes, and off-hours capacity; never scale down fidelity. - Promote the same artifacts through the same pipeline as production, on every merge. - Seed synthetic data everywhere, refresh anonymized snapshots where distribution matters, and give destructive changes ephemeral databases. - Set staging SLOs: baseline-green rate, sync lag, and time-to-test, with alerts. - Share the environment through test tenants, not locks, calendars, or clones. - Keep specialized environments only where they earn their place, like performance and compliance. One staging environment, a tenant for every change Signadot turns the staging cluster you already run into a multi-tenant platform: every developer and coding agent gets an isolated sandbox across services, message queues, and databases. The free tier is open to every developer. [Start for free](https://www.signadot.com/signup/)[Book a demo](https://www.signadot.com/schedule-a-call/) #### Frequently asked questions What is a Kubernetes staging environment? A Kubernetes staging environment is a pre-production cluster, or a dedicated slice of one, that mirrors production closely enough that a change passing there is expected to be safe to deploy. It typically runs the same services, configuration, and infrastructure primitives as production, with test or anonymized data. How many environments do you need before production? For most companies, one. A single well-run staging environment, shared safely through per-change test tenants, replaces the traditional dev, QA, staging, and preprod ladder, which mostly exists to work around unsafe sharing. Specialized environments can still earn their place for narrow jobs like sustained performance testing or compliance certification. How do I share a staging Kubernetes environment across teams? Give each change a test tenant on the shared baseline: a routing key that follows the change through synchronous calls via header-based routing, through message queues via selective consumption, and through data via ephemeral per-tenant databases or schemas. Teams and coding agents then test in parallel without redeploying or breaking the shared environment. How big should a staging cluster be? Match production's Kubernetes version, add-ons, and configuration shape exactly, then scale down what does not affect fidelity: replica counts, node sizes, and node pool counts. Test traffic is a trickle compared to production load, so staging typically runs well at a fraction of production capacity. How often should staging sync with the main branch? On every merge, automatically, through the same delivery pipeline as production. A useful way to track it is sync lag measured in merges behind main; if staging is more than a handful of merges behind, test results there describe a system that no longer exists. What is the difference between staging and preprod? In most organizations they are the same idea: a production-like environment that sits after CI and before production. Some teams run both, using staging for integration testing and a stricter preprod for release rehearsal, but any long-lived shared environment becomes a queue as team count grows, which is why fewer, better-shared environments win. #### Related Posts *Image: Smart Ephemeral Environments: Share More, Copy Less* ephemeral-environments ##### Smart Ephemeral Environments: Share More, Copy Less January 31, 2025 *Image: How to Improve the Microservice Lifecycle with Developer Environments* ephemeral-environments ##### How to Improve the Microservice Lifecycle with Developer Environments June 2, 2022 *Image: How Bitso Is Scaling Branch-Based Development with Signadot and Neon* cases ephemeral-environments ##### How Bitso Is Scaling Branch-Based Development with Signadot and Neon January 7, 2026 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Kubernetes Namespace vs Cluster: Pros and Cons for Test Environments Source: https://www.signadot.com/blog/namespace-based-environments-for-testing-pros-and-cons/ Summary: How namespaces compare to separate clusters and vClusters as test environment boundaries, where namespace-based environments break down, and what teams move to. ### Kubernetes Namespace vs Cluster: Pros and Cons for Test Environments Namespace-based test environments are cheap and simple to start with, but hard to keep in sync and slow to spin up as teams grow. Here are the real pros and cons, where they break, and what teams move to. Reading time 9 min Author Nica Mellifera Published July 5, 2023 Updated July 17, 2026 Topics [Ephemeral Environments](https://www.signadot.com/blog/category/ephemeral-environments/) **Namespace-based environments** give each team or developer a logical slice of a shared Kubernetes cluster to test in. They are cheap, they are built into Kubernetes itself, and a small team can be up and running with them in an afternoon. They are one of four ways to replace a single shared environment, compared in the [complete guide to staging environments](https://www.signadot.com/staging-environments/). The trouble arrives later, when the number of services and teams grows and keeping every namespace in sync quietly becomes a full-time job. This is an honest look at what namespaces do well as [test environments](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/), where they break down, and what teams adopt when they outgrow them. Pros Cons Simple to set up, core to Kubernetes Each namespace needs its own datastores and seed data Cheap logical isolation within one cluster No built-in way to keep namespaces in sync Per-namespace RBAC and resource quotas Spin-up time grows with app complexity Familiar kubectl workflow Often unmaintained and unreliable at scale #### What a namespace actually gives you A namespace is a logical partition inside a single Kubernetes cluster. It groups a set of resources, pods, services, volumes, and so on, so they can be managed and access-controlled as a unit while still sharing the cluster with everything else. Creating one is about as easy as anything gets in Kubernetes: define the namespace in a YAML file, run `kubectl apply -f namespace.yaml`, and deploy your application into it with the `--namespace` flag. Every kubectl command can be pointed at your namespace, or default to it, so you can experiment freely without worrying about wrecking another team’s services. You get per-namespace RBAC and resource quotas, and because namespaces are core to the Kubernetes spec, you are not depending on obscure add-ons. Namespaces are not fully sealed off from each other either, which is handy for testing: every service gets a DNS entry of the form `..svc.cluster.local`, so if you know a service’s name and namespace, you can reach it from anywhere in the cluster. Namespaces have plenty of uses, but this piece is about one in particular: functional testing, where each engineer gets a production-like environment to try their code in before it merges. *Image: Diagram of four developers each deploying updated services into their own namespace copy of the full environment* _Four developers, four namespaces, four copies of the environment to keep up to date._ #### Namespace vs cluster vs vCluster Namespaces are one of three isolation boundaries teams reach for, so it is worth placing them side by side. A namespace is a logical partition inside one cluster: cheap, simple, and isolated at the application level. A separate cluster is the opposite extreme, a fully independent control plane and data plane, with the strongest isolation and the highest cost. A virtual cluster (vCluster) sits in between: a virtual control plane running inside a host cluster, which gives each tenant cluster-level isolation without another physical cluster to pay for. Namespace vCluster Separate cluster Isolation level Application / resource Control plane (virtual) Full (physical) Relative cost Lowest Low to medium Highest Blast radius Shared control plane Isolated control plane Fully isolated Setup and management Simplest Moderate Most complex Best for Lightweight separation in one cluster Strong isolation without new clusters Hard multi-tenancy or compliance In practice, namespaces and vClusters solve similar problems. Both partition a shared cluster, both support quotas and role-based access control, and both let teams make changes independently. The difference is depth: a namespace shares one control plane with every other tenant, while a vCluster gives each tenant its own API server, operators, and CRDs, at the price of more moving parts. A separate physical cluster remains the strongest boundary, and the right one for hard multi-tenancy or compliance, but it is the most expensive and the slowest to provision. Here is the thing, though: for testing, the choice of boundary matters less than you would hope. Whichever unit you pick, namespace, vCluster, or cluster, a test environment still needs its own copies of services, datastores, and seed data, and something has to keep all of it in sync. That problem is the real subject of this post, and it is why many teams eventually skip stronger partitioning altogether in favor of request-level isolation with [sandboxes](https://www.signadot.com/kubernetes-sandbox/) on a shared cluster. More on that at the end. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### Where namespaces start to break down First, remember what the namespace is for. The point of handing a team its own namespace is more accurate testing: spin up the services and resources you need, run your changes against them, and trust the result. Some teams deploy everything into the namespace; others deploy a subset and mock the rest to save money. That accuracy is exactly what erodes first. Say you create namespaces for two large teams, team-jacob and team-edward. There is no built-in way to keep those namespaces in sync. Changes to datastores, changes to third-party APIs, even routine updates to services neither team is touching, all of it has to be propagated by hand. And while running many namespaces is certainly simpler than running many clusters, it is not much cheaper: the storage and compute for all those duplicated services cost nearly the same wherever the boundary sits. I got a vivid picture of how this plays out from an enterprise operations team that had used namespaces heavily for several years. Early on they were delighted: every team had free rein in its own namespace, and testing accuracy went up. Then the app grew. Spinning up all the services in a namespace took longer and longer, and the needs of different teams caused their namespaces to diverge. There was no simple way for a developer to tell whether their namespace was up to date, so a passing test stopped meaning much about what would happen on staging. Ownership made it worse. Product teams are clearly delineated; operations teams usually are not. Individual namespaces had no owner on the platform side, so when one went stale, nobody was answerable for it. The end state was a collection of half-maintained namespaces that nobody trusted. One by one, developers stopped using them and went back to feature flags and testing on staging, which is exactly the situation the namespaces were supposed to fix. #### The mocking trap Faced with that upkeep, any sensible team starts looking for things to stop maintaining. Instead of updating the namespace every time a third-party API changes, why not mock its responses? The response format changes far more slowly than the service itself. Instead of running a pile of unrelated services, why not emulate them with a localstack-style tool? Each of these swaps buys stability and costs fidelity. The stack gets easier to maintain and less like production at the same time, and the risk of surprises between development, staging, and production goes right back up. Test fidelity was the whole reason we handed out namespaces in the first place. Follow the mocking logic far enough and you end up with an environment so hollowed out that you might as well mock everything and run it on a laptop. #### Deploy-time bugs live in data and dependencies There is a reason fidelity keeps coming up. The bugs that surface at deploy time overwhelmingly come from two places: data and dependencies. Namespaces make the compute side easy, since your services run in the real cluster alongside everyone else’s. Data is the hard part. To be isolated, each namespace needs its own datastore instance, whether that is a managed cloud database or a containerized one inside the cluster, and something has to create those temporary databases and load the right seed data every time an environment spins up. That is a real system you have to build and operate. Third-party dependencies are no better off; a namespace does nothing special to help you test against them. Who hasn’t had code fail in production because only the production database contained [little Bobby Tables](https://xkcd.com/327/)? #### What teams move to To be fair to namespaces: they work well for simple apps with a handful of services, they work for teams with dozens of engineers, and they can keep working at large scale if someone actively maintains them. But the failure mode is a vicious cycle. The moment maintenance slips, sync problems multiply, developers hit bugs that are really environment drift, and they quietly route around the whole thing. The teams that scale past this tend to land on the same insight: deploy only what changed, and share everything else. In a discussion on a private Slack (quoted with permission), Mason Jones described how his previous company got there: > At my previous company as we scaled up we used a shared dev/test cluster and built our own tooling to provide on-demand namespaces. A namespace isn’t a “dedicated instance of infra”, it’s just a logical space in which devs can deploy their own version of something. We often used it with one namespace per team. They only deployed the containers they were changing, and used the shared instances of everything else, so it was actually quite economical. \[…\] there are “hidden” complications to making this work, no question. We customized our service mesh so that requests to another service would first try to target a version of the service in the same namespace, and if there wasn’t one then the request would go to the shared namespace. That allowed devs to run a custom version of a service privately, while others could use the shared one. Notice what did the heavy lifting there. It was not the namespace; it was the request routing layered on top of a shared baseline. [Lyft](https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-3-extending-our-envoy-mesh-with-staging-fdaafafca82f), [Razorpay](https://www.youtube.com/watch?v=1hZY-vg7kSs), and [DoorDash](https://doordash.engineering/2022/06/23/fast-feedback-loop-for-kubernetes-product-development-in-a-production-environment/) all arrived at versions of the same approach, letting individual developers run just the service under test against a high-fidelity shared environment. That request-level isolation model is what our guide to [ephemeral environments in Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) covers in depth. If you want to talk about high-fidelity testing on Kubernetes at scale, or you hated this article and want to tell Nica about it, [join the Signadot Slack](https://join.slack.com/t/signadotcommunity/shared_invite/zt-1estxm8pv-qfiaNfiFFCaW~eUlXsVoEQ) and talk directly with the team. #### Frequently asked questions What is a namespace-based test environment? It is a testing setup where each team or developer gets a dedicated Kubernetes namespace within a shared cluster to deploy and test their services, isolated at the application level from other namespaces. What are the drawbacks of using namespaces for testing? Each namespace needs its own datastores and seed data, there is no built-in way to keep namespaces in sync with each other or with production, spin-up time grows with application complexity, and namespaces often go unmaintained and unreliable as teams scale. Do namespaces scale for large teams? They work well for simple apps or smaller teams, and can work for large teams if actively maintained. At scale, sync and maintenance problems usually push teams toward request-level isolation on a shared baseline instead. What is the difference between a Kubernetes namespace and a cluster? A namespace is a logical partition inside a single Kubernetes cluster, isolating resources at the application level. A cluster is a complete, independent Kubernetes environment with its own control plane and nodes. Namespaces are cheaper and simpler, while separate clusters give stronger isolation at higher cost. What is a vCluster? A virtual cluster (vCluster) is a virtual Kubernetes control plane that runs inside a namespace of a host cluster. It gives each tenant cluster-level isolation, including their own API server and CRDs, without the cost of provisioning a separate physical cluster. Is a namespace the same as a virtual cluster? No. A namespace isolates resources at the application level within one shared control plane, while a virtual cluster provides a separate virtual control plane, which is a much stronger isolation boundary. #### Related Posts *Image: It’s Time To Kill Staging: The Case for Testing in Production* ephemeral-environments ##### It’s Time To Kill Staging: The Case for Testing in Production December 3, 2025 *Image: Testing Microservices with RabbitMQ using Signadot Sandboxes* tutorials-guides ephemeral-environments ##### Testing Microservices with RabbitMQ using Signadot Sandboxes August 29, 2025 *Image: Microservices Testing: 4 Use Cases for Sandbox Environments* ephemeral-environments ##### Microservices Testing: 4 Use Cases for Sandbox Environments March 28, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Testing Kafka-Based Microservices in Kubernetes: The Complete Guide Source: https://www.signadot.com/blog/kafka-step-by-step-tutorial/ Summary: The three isolation strategies for testing Kafka-based microservices (cluster, topic, and message-level), how message isolation works with routing keys and consumer groups, the hard patterns like CDC and batch jobs, and a hands-on tutorial with sandboxes. ### Testing Kafka-Based Microservices in Kubernetes: The Complete Guide How do you test Kafka-based microservices without giving every developer their own cluster? This guide compares the three isolation strategies for Kafka test environments (cluster, topic, and message-level), explains how message isolation works with routing keys and consumer groups, covers the hard patterns like CDC and batch jobs, and walks through a complete hands-on tutorial using Signadot Sandboxes. Reading time 10 min Author Signadot Published November 6, 2024 Updated August 31, 2026 Topics [Tutorials/Guides](https://www.signadot.com/blog/category/tutorials-guides/), [Integration/E2E Testing](https://www.signadot.com/blog/category/integration-e2e-testing/) Asynchronous, event-driven communication is the backbone of most microservice architectures, and Apache Kafka is the most common way teams build it. It is also where testing strategies go to die. Setting up all your microservices plus Kafka locally is painful, and testing in a shared staging environment means one developer’s test messages get consumed by another developer’s consumers. This guide covers how to test Kafka-based applications properly: the three isolation strategies and their tradeoffs, how message-level isolation actually works, the hard patterns (CDC, batch jobs, offsets), and a complete hands-on tutorial you can run on your own cluster. While we focus on Kafka as the concrete example, the same patterns apply to RabbitMQ, Google Pub/Sub, AWS SQS, and [other message queues](https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/). The same routing-key gate also works for durable-execution task queues, as the [Temporal worker tutorial](https://www.signadot.com/docs/tutorials/testing-temporal-workers) shows. #### Why testing Kafka-based microservices is hard Message queues form the backbone of many [microservices architectures](https://www.signadot.com/blog/how-microservices-communicate-with-each-other/), implementing several patterns: many-to-one (multiple producers, one aggregating consumer), many-to-many (event-driven architectures), and one-to-many (a producer broadcasting to many consumers, common in notification systems). Every one of those patterns complicates testing, because the thing you are testing is not a request and a response. It is a message that fans out through the system. Consider an e-commerce platform where an order processing service publishes events that trigger payment processing, inventory updates, and shipping notifications. When developers need to test changes to any service in this workflow, they face the same problems: - **Interference in shared environments.** A developer modifying the order processor affects another developer testing the payment service. When tests fail, it is hard to tell whether the failure came from your change or from someone else’s test running at the same time. - **Coordination overhead.** Developers spend real time booking testing windows, waiting for other teams to finish, and debugging failures that turn out to be someone else’s. Schema changes are the worst case, requiring careful cross-team coordination to avoid breaking existing consumers. - **Kafka is heavy to replicate.** A test environment with Kafka means brokers, cluster management, security, replication, and partitioning configuration, plus every producer and consumer service across different languages and frameworks. [Duplicating that per developer or per PR](https://www.signadot.com/blog/environment-replication-doesnt-work-for-microservices/) is slow to set up, expensive to run, and immediately starts drifting out of date. Slow feedback cycles and low-confidence integration tests are the predictable result. The fix starts with choosing the right isolation boundary. #### The three isolation strategies for Kafka test environments There are three places you can draw the isolation line for a Kafka test environment. (Throughout, a “tenant” means a developer, team, or CI job that needs to run a test scenario in isolation.) ##### Strategy 1: Isolate the Kafka cluster Give each tenant a complete Kafka cluster of their own, along with copies of all producers and consumers. *Image: Diagram of a baseline producer and consumer using the main Kafka cluster while a sandboxed producer and consumer use a dedicated sandboxed Kafka cluster* **Advantages:** the highest isolation between environments. **Considerations:** the highest cost, since the entire infrastructure is duplicated per tenant; complex management of many independent environments; and the need for automation that continuously keeps every copy in sync with the main branch, without which environments go stale fast. ##### Strategy 2: Isolate Kafka topics Share one Kafka cluster and create ephemeral, per-tenant topics. Producers and consumers still need to be duplicated and reconfigured to point at the tenant’s topics. *Image: Diagram of a sandboxed producer and consumer publishing and consuming on a per sandbox topic t1-s1 in the shared Kafka cluster* **Advantages:** meaningful cost savings from sharing the brokers. **Considerations:** automation to create and tear down topics per environment; every producer and consumer still gets duplicated per tenant; and reconfiguring services to point at the right topics is error-prone. ##### Strategy 3: Isolate Kafka messages Run one shared, continuously updated baseline environment containing Kafka and every service, and isolate at the level of individual messages. Each tenant deploys only the service versions under test. Requests and messages are tagged with a routing key and dynamically routed, so the tenant’s messages reach the tenant’s consumers while everything else flows through the baseline. *Image: Diagram of message level isolation where a message on topic t1 is consumed by either the baseline consumer or the sandboxed consumer depending on its context* **Advantages:** no infrastructure to create or tear down per environment; the most cost-efficient model, especially with a complex Kafka setup and many services; minimal operational overhead, since each test environment runs only the changed services; and no stale environments, because the shared baseline is updated by your existing CI/CD pipeline. **Considerations:** services need OpenTelemetry (or equivalent) instrumentation for context propagation, and Kafka consumers need a small amount of logic for selective consumption. If you need infrastructure-level isolation for compliance reasons, this is not the right boundary. For most teams, message-level isolation wins as the system grows: it is the only strategy whose cost does not scale with the number of concurrent tests. The rest of this guide is about making it work. #### How message-level isolation works Message isolation rests on two primitives: context propagation (getting a routing key from the incoming request all the way through Kafka) and selective consumption (each consumer version deciding which messages to process). For synchronous calls, context propagation is a solved problem, standardized by [OpenTelemetry](https://opentelemetry.io/), and routing is handled at the infrastructure layer by a [service mesh or sidecars](https://www.signadot.com/blog/scaling-environments-with-opentelemetry-and-service-mesh/), with a central route service storing the mapping between services and routing keys. Note that you only need OpenTelemetry’s context propagation, not distributed tracing: the baggage mechanism carries the routing key across service boundaries, and [auto-instrumentation](https://opentelemetry.io/blog/2022/instrument-kafka-clients/) can add it to Kafka clients without application code changes. *Image: Request flow being routed to sandboxed Service B based on request headers* Asynchronous flows need three additional pieces, because a service mesh operates at the request level and cannot see individual messages: 1. **Producers propagate the routing key into message headers.** When a request with a routing key triggers message production, the key is copied from the request context into the Kafka message headers. 2. **Each sandboxed consumer joins its own consumer group.** This guarantees that every consumer version (baseline and every sandbox) receives every message on the topic. A simple naming convention is the original consumer group name with the sandbox name appended, which is guaranteed unique per sandbox. 3. **Every consumer runs selective consumption logic.** All versions see all messages; the routing key decides who processes each one. *Image: Kafka Producers and Consumers using headers for selective consumption* ##### The routing key contract In Signadot, the routing key is an opaque value assigned to each [sandbox](https://www.signadot.com/kubernetes-sandbox/) and route group. The selective consumption rules differ slightly for sandboxed and baseline workloads: **A sandboxed consumer** needs the message’s routing key and the set of routing keys it is responsible for: the key of the sandbox that created it, plus the keys of every route group containing that sandbox. If the message’s key is in that set, process it; otherwise skip it. For example, if sandbox `S1` has routing key `rk1` and belongs to route group `RG1` with key `rk2`, then the sandboxed consumer `C1'` processes messages carrying `rk1` or `rk2`. **The baseline consumer** applies the inverse rule: it needs the set of routing keys claimed by any sandbox forked from it, and it processes a message only if the message carries no routing key or a key outside that set. If a second sandbox `S2` (key `rk3`) also forks the consumer, creating `C1"`, then `C1'` handles `rk1` and `rk2`, `C1"` handles `rk3`, and the baseline `C1` handles everything else, including unmatched keys. *Image: Animation of selective consumption where the baseline consumer C1 and the sandboxed consumer C1 prime subscribe to the same topic but only one processes each message* Where does the mapping of routing keys to sandboxes come from? The Signadot Operator exposes it inside the cluster through the [Routes API](https://github.com/signadot/routesapi), a set of gRPC and REST endpoints served by the route server. Consumers pull the current mapping (or stream updates in near real time) and cache it locally. Platform teams typically wrap this lookup plus the selective consumption rules in a small custom Kafka client library, so product teams get message isolation without thinking about it. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### The hard patterns Four situations need extra design attention, and they are where most homegrown implementations stumble. **Change data capture (CDC).** With CDC pipelines such as Debezium, the “producer” is reading a database transaction log, not handling a request, so there is no incoming header to propagate. The routing information has to live in the source rows themselves, typically in a metadata column, which the CDC producer then copies into message headers. The same applies to any flow that does not start with a request: a cron job reading rows and publishing messages needs a plan for which tenant each row belongs to. **Batch processing.** When messages are processed in batches, routing decisions must be made at the batch level. Messages with different routing contexts belong in separate batches, and the processor has to maintain the routing context across the batch lifecycle. This matters most in high-throughput systems where batching is a performance requirement. **Consumer group lifecycle and offsets.** Sandboxed consumer groups should start from the latest offset, so a new sandbox tests new messages rather than replaying history. And when a sandbox is deleted, its consumer group should be cleaned up too, freeing broker resources. Tie the group’s lifecycle to the sandbox’s. **Cache coherency.** Consumers cache the routing key mapping for performance, which means a freshly created sandbox is not instantly visible to every consumer. Keep the cache TTL short (the demo below polls every few seconds) or use the streaming API so consumers converge quickly. #### Tutorial: testing an end-to-end Kafka flow with sandboxes The rest of this guide makes the model concrete with a small demo you can run on your own cluster ([source on GitHub](https://github.com/signadot/examples/tree/main/selective-consumption-with-kafka)). The demo is a Node.js system built around a shared Kafka cluster: a **producer** that publishes each incoming request as a Kafka message, a **consumer** that processes those messages, and a **frontend** for sending messages and watching the results. All three services log their activity to Redis, and the frontend polls those logs every two seconds, so you can see exactly which version of which service handled each message. The [Signadot Operator](https://www.signadot.com/docs/installation/signadot-operator) (v0.15.0 or later, for the Routes API) handles sandbox creation and routing. *Image: Architecture diagram of the demo app with frontend, producer, Kafka and consumer, all writing logs to Redis* In demo terms, the routing key contract plays out in two flows: - **No matching routing key.** The producer publishes without a routing key, so the baseline consumer, in its own consumer group, processes the message and sandboxed consumers skip it. - **Matching routing key.** The producer copies the routing key from the incoming request into the message headers, the sandboxed consumer whose key matches processes the message, and the baseline consumer skips it. ##### Step 1: Deploy the demo and check the baseline Clone the demo repository and follow its README to deploy the Kafka cluster, Redis, the frontend, the producer, and the consumer, then port-forward the frontend to localhost:4000. With no sandboxes created yet, any message you send from the frontend is processed by the baseline consumer: *Image: Kafka demo frontend showing a published message consumed by the baseline consumer, with the frontend, producer, Kafka, and consumer architecture alongside* ##### Step 2: Propagate the routing key in the producer The producer reads the routing key from the incoming request’s baggage header and copies it into the headers of every Kafka message it publishes. In the demo this is a few lines in the producer’s `app.js`; in a real system you can get the same behavior with [OpenTelemetry auto-instrumentation](https://opentelemetry.io/blog/2022/instrument-kafka-clients/), without touching application code. ##### Step 3: Consume selectively in the consumer The consumer implements the three asynchronous pieces described earlier. The code lives in the demo’s `app.js` and `kafka.js` and is short enough to read in one sitting: - **One consumer group per sandbox.** The Signadot Operator injects a `SIGNADOT_SANDBOX_NAME` environment variable into sandboxed pods. The consumer derives its group ID from it (`sandbox-consumer-`) and falls back to `baseline-consumer` when the variable is absent. Separate groups mean separate offsets, so sandboxed consumers never disturb the baseline’s position in the topic. - **Fresh routing keys from the Routes API.** Every five seconds the consumer polls the operator’s Routes API and caches the mapping of routing keys to sandboxes. That cached set feeds the processing decision, and the short interval keeps a newly created sandbox from staying invisible for long (the streaming variant of the API converges even faster). - **A shouldProcess check on every message.** The consumer reads the routing key from each message’s headers and applies the routing key contract: a sandboxed consumer processes only messages whose key is in its set, and the baseline consumer processes messages that carry no key or a key no sandbox claims. - **Offsets start from latest.** New consumer groups begin at the latest offset, so a fresh sandbox tests new messages instead of replaying history. In production setups, platform teams typically wrap these pieces in a shared Kafka client library, so product teams get selective consumption without writing any of this themselves. ##### Step 4: Create the sandboxes Create one sandbox that forks the producer and one that forks the consumer, using ordinary sandbox specs; nothing Kafka-specific goes into the YAML. The operator assigns each sandbox a routing key and injects the environment variables the consumer logic relies on. ##### Step 5: Send messages and watch the routing With both sandboxes running, use the Signadot browser extension to choose which sandbox, if any, your requests are routed to, then send messages from the frontend. Four scenarios cover the whole contract. ###### Scenario 1: baseline producer, baseline consumer With no sandbox selected, messages carry no routing key, so the baseline consumer processes them and both sandboxes stay silent. *Image: Diagram of a baseline producer publishing to Kafka with no routing key, consumed by the baseline consumer while the sandbox consumer ignores it* *Image: Kafka demo log entries showing a message with an empty routing key consumed by the baseline consumer* You can also watch the flow end to end: ###### Scenario 2: baseline producer, sandboxed consumer Select the consumer sandbox in the browser extension and send another message. *Image: Signadot browser extension setting request headers for the consumer-sbx sandbox with its routing key* The routing key rides the request into the message headers, the sandboxed consumer’s key matches, and it processes the message while the baseline consumer skips it. *Image: Kafka demo log entries showing a message with a routing key consumed by the sandboxed consumer* *Image: Diagram of a message with routing key RTK1 bypassing the baseline consumer and being delivered to the sandbox consumer with the matched routing key* ###### Scenario 3: sandboxed producer, baseline consumer Now select the producer sandbox instead. *Image: Signadot browser extension setting request headers for the producer-sbx sandbox with its routing key* The forked producer publishes the message with its own routing key, but no consumer sandbox claims that key, so the baseline consumer treats it as general traffic and processes it. Unmatched keys falling through to the baseline is the contract working as designed. *Image: Kafka demo log entries showing the sandboxed producer publishing a message that the baseline consumer processes* *Image: Diagram of a sandbox producer publishing with routing key RTK2 that no sandbox consumer matches, so the baseline consumer processes the message* ###### Scenario 4: producer and consumer together in a route group Real features often change more than one service at once. A route group combines both sandboxes under a single routing key: point the browser extension (or the group’s preview URL) at it and send a message. The request first hits the forked producer, and the resulting Kafka message is consumed by the forked consumer, end to end, while the baseline and every other developer’s sandbox stay untouched. #### What this looks like day to day From a developer’s perspective, testing changes to asynchronous workflows becomes remarkably straightforward. Say a developer is modifying a service that consumes order events from Kafka and updates the shipping system. They create a sandbox for their modified service through their platform team’s tooling; behind the scenes the platform deploys the service, sets up consumer groups, and configures routing. To test, they trigger a test order through the regular application interface with a header that routes traffic to their sandbox. The platform’s instrumentation propagates that routing information through the entire system, from the initial request, through Kafka, to their modified service. The developer observes how their changes process the test order, while other developers’ tests and regular traffic continue flowing through the system undisturbed. All the complexity of message routing, consumer group management, and context propagation is handled by platform-provided libraries and infrastructure. Companies like [Brex](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/), [DoorDash](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/), and [ShareChat](https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/) run this model in production engineering organizations, giving hundreds of developers isolated Kafka testing on shared clusters. #### Conclusion Testing Kafka-based microservices effectively doesn’t require massive infrastructure duplication. Of the three isolation strategies, message-level isolation is the only one whose cost stays flat as the number of concurrent tests grows: one shared baseline, one Kafka cluster, and a routing key that keeps every tenant’s messages separate. With consumer groups, selective consumption, and Signadot’s sandboxes and Routes API, teams get isolated end-to-end testing of event-driven flows without duplicating brokers or coordinating testing windows. To go deeper: see how the same pattern extends to [SQS, Pub/Sub, and other brokers](https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/), how it applies to [event-driven architectures more broadly](https://www.signadot.com/blog/testing-event-driven-architectures-with-signadot/), and how it fits into the full picture of [microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/). Ready to try it on your own cluster? [Sign up for Signadot](https://www.signadot.com/signup/) and run the tutorial above end to end. #### Frequently asked questions How do you test Kafka-based microservices? There are three isolation strategies: give each test its own Kafka cluster (high fidelity, very expensive), give each test its own topics on a shared cluster (cheaper, but every producer and consumer must be duplicated and reconfigured), or isolate at the message level, where a shared baseline runs everything once and routing keys in message headers decide which consumer version processes each message. Message-level isolation is the most cost-efficient at scale and is the approach this guide covers in depth. Do I need a separate Kafka cluster for testing? Usually not. A dedicated cluster per test environment gives strong isolation but duplicates brokers, producers, and consumers for every tenant, and the copies drift out of date without constant automation. Most teams get the isolation they need by sharing one production-like Kafka cluster and isolating tests at the topic level or, more efficiently, at the message level with routing keys. How does message-level isolation work in Kafka? Producers propagate a routing key from the incoming request into the Kafka message headers, typically via OpenTelemetry context propagation. Each sandboxed consumer version joins its own consumer group, so every version sees every message, and a small piece of consumer logic decides whether to process or skip each message by matching its routing key against the sandbox's keys. Baseline consumers process only messages that carry no routing key or one that no sandbox claims. How is this different from Testcontainers or embedded Kafka? Testcontainers and embedded brokers are excellent for unit and component tests: they give a single test suite a private, throwaway broker. They do not help with end-to-end flows across many real services, datastores, and topics. Message-level isolation on a shared staging baseline covers that integration layer: real brokers, real consumers, real downstream services, with each change tested in its own sandbox. Does this approach work for queues other than Kafka? Yes. The pattern (propagate a routing key in message metadata, run sandboxed consumers in their own groups, and consume selectively) extends to RabbitMQ, Google Pub/Sub, AWS SQS, and other brokers. The mechanics of headers and consumer groups differ per system, but the model is the same. #### Related Posts *Image: How to Run Scalable Performance Tests Using Grafana/K6 and Signadot* tutorials-guides integration-e2e-testing ##### How to Run Scalable Performance Tests Using Grafana/K6 and Signadot February 4, 2025 *Image: Tutorial: Preview Environments for Features Across Multiple Microservices* integration-e2e-testing tutorials-guides ##### Tutorial: Preview Environments for Features Across Multiple Microservices February 6, 2023 *Image: Guide to Shift-left Test Approach in Kubernetes* integration-e2e-testing tutorials-guides ##### Guide to Shift-left Test Approach in Kubernetes September 7, 2022 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## How to Test Event-Driven Architectures Without Duplicating Infrastructure Source: https://www.signadot.com/blog/testing-event-driven-architectures-with-signadot/ Summary: The general model for testing event-driven systems with message-level isolation (a routing key propagated inside every message, consumer-side selective consumption, and a central Routes API), applied to pub/sub fan-out, work queues, sagas, and CDC, cron, and batch flows. ### How to Test Event-Driven Architectures Without Duplicating Infrastructure Event-driven architectures are hard to test because a change fans out through brokers, consumers, and downstream services. This guide explains the general model for testing them with message-level isolation: propagate a routing key inside every message, let each consumer variant decide which messages to process, and resolve those decisions against a central Routes API. Then it applies the model pattern by pattern, from pub/sub fan-out to CDC and batch flows. Reading time 7 min Author Anirudh Ramanathan Published August 16, 2024 Updated August 31, 2026 Topics [Integration/E2E Testing](https://www.signadot.com/blog/category/integration-e2e-testing/) Event-driven architectures decouple services beautifully and complicate testing in equal measure. In a request-driven system, a test is a request and a response, and isolation is a routing problem that service meshes solved years ago. In an event-driven system, a single change fans out: a producer publishes an event, a broker distributes it, several consumers react, and some of those consumers publish events of their own. Testing a change to any one of those pieces means exercising that whole flow, and the traditional answer, duplicating the broker and every consumer per test environment, is [expensive, slow, and permanently out of date](https://www.signadot.com/blog/environment-replication-doesnt-work-for-microservices/). There is a better model. It tests every change against one shared baseline environment, adds no infrastructure per test, and extends to every event-driven pattern in production use. This article describes the model in general terms, then walks through how each common pattern maps onto it. #### The general model: message-level isolation Instead of isolating tests at the infrastructure level (separate brokers) or the channel level (separate topics), isolate at the level of individual messages. Three mechanisms make it work. **1\. Propagate the routing key inside every message.** Each [sandbox](https://www.signadot.com/kubernetes-sandbox/) is assigned an opaque routing key. Synchronous requests already carry it in headers through OpenTelemetry context propagation. The asynchronous extension is simple: when a service publishes a message while handling a request that carries a routing key, it copies the key into the message’s own metadata, such as Kafka headers, RabbitMQ headers, Pub/Sub attributes, or SQS message attributes. The key now travels with the message wherever it goes, independent of the transport path, and [OpenTelemetry auto-instrumentation](https://opentelemetry.io/blog/2022/instrument-kafka-clients/) can do the copying without application code changes. **2\. Decide on the consumer side which instance processes each message.** Every variant of a consumer, the baseline `C1` and any sandboxed versions like `C1'`, subscribes to the same message stream, each through its own consumer group or subscription, so every variant sees every message. A small consumption check then ensures exactly one of them acts: a sandboxed consumer processes only messages whose routing key is in its set (its sandbox’s key, plus the keys of any route groups containing that sandbox), and the baseline consumer processes only messages that carry no routing key or a key no sandbox claims. *Image: Two messages pass through the queue, and only the message carrying routing key rk1 is processed by the sandboxed consumer while the baseline consumer handles the other* **3\. Resolve routing keys against a central Routes API.** The consumption check needs the current mapping between routing keys and sandboxes, and that mapping lives in one place. The Signadot Operator serves it inside the cluster through the [Routes API](https://github.com/signadot/routesapi), a set of gRPC and REST endpoints that consumers can poll or stream and cache locally. Platform teams typically wrap the lookup and the consumption check in a small client library, so application teams get message isolation by importing it. That is the whole model: one broker, one baseline environment, and any number of concurrent tests whose cost does not grow with the number of testers. For the full routing key contract and a complete Kafka implementation, see the [complete guide to testing Kafka-based microservices](https://www.signadot.com/blog/kafka-step-by-step-tutorial/). Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) #### How each event-driven pattern maps to the model Event-driven systems are built from a handful of recurring patterns, and each one reduces to the same three mechanisms. ##### Pub/sub fan-out: one event, many subscribers A checkout event fans out to payment, inventory, and notification services. Each subscribing service applies the consumption check independently, so you sandbox only the subscriber you changed: your test event reaches every subscriber, the sandboxed version of the one service under test processes it, and the baseline versions of every other subscriber handle it as usual. Because the routing key lives in the message rather than the transport path, fan-out needs no special handling at all. ##### Work queues and competing consumers In a work queue, worker instances compete and exactly one takes each job. That guarantee normally comes from sharing a consumer group, which is precisely what sandboxed variants must not do. Instead, each variant (the baseline worker pool and each sandboxed worker) gets its own consumer group or subscription, so each variant observes every job, and the consumption check preserves the one-processor guarantee across variants: the matching variant processes the job, and the others skip it and acknowledge. ##### Multi-hop chains and choreographed sagas Flows like order placed, then payment captured, then shipment created span several producer-consumer hops. The routing key must survive every hop, so each consumer copies the key from the message it processes into any requests or messages it emits, which is the same context propagation rule the synchronous half of the system already follows. When a change spans multiple services in the chain, a [route group](https://www.signadot.com/docs/reference/route-groups/spec) assigns one routing key to several sandboxes, so the whole modified path is exercised together while everything else stays baseline. ##### Flows that do not start with a request: CDC, cron, and batch Change data capture pipelines and scheduled jobs have no incoming request to carry a routing key, so the key has to be established at the source. For CDC tools like Debezium, that usually means a metadata column in the source rows that the producer copies into message headers. For a cron job that reads rows and publishes them, the job tags each message according to the tenant the row belongs to. Batch processors add one more rule: group messages by routing context, so a single batch never mixes messages that belong to different sandboxes. Once the key is in the message, everything downstream works exactly as in the request-driven case. #### The same model across brokers The three mechanisms rely on broker features that are nearly universal: metadata attached to each message and a way for multiple consumer variants to observe the same stream. In Kafka that is headers and consumer groups; in RabbitMQ, headers and per-variant queues bound to the same exchange; in Google Pub/Sub, attributes and per-sandbox subscriptions; in SQS, message attributes. The primitives differ but the contract does not, and the broker-specific details are covered in [testing microservices with message isolation for Kafka, SQS, and more](https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/). #### Seeing it work The fastest way to make this concrete is to run it. The [complete Kafka guide](https://www.signadot.com/blog/kafka-step-by-step-tutorial/) includes a hands-on tutorial with a small demo application where you can watch each case live: a baseline message handled by the baseline consumer, a sandboxed consumer picking up only its own messages, an unmatched routing key falling through to the baseline, and a route group carrying a change through a forked producer and a forked consumer together. #### Conclusion Testing event-driven architectures does not require duplicating brokers, topics, or consumers per environment. Three mechanisms, a routing key propagated inside every message, a consumer-side check that decides which variant processes it, and a central Routes API that holds the mapping, are enough to give every developer and every pull request an isolated end-to-end test path through the real system. The model covers pub/sub fan-out, work queues, multi-hop sagas, and even flows that start in a database log or a cron job, and it works across Kafka, RabbitMQ, Pub/Sub, and SQS. Signadot provides the pieces so you do not build them yourself: sandboxes with assigned routing keys, route groups for multi-service changes, and the Routes API served by the operator in your cluster. [Sign up](https://www.signadot.com/signup/) to try it on your own cluster, or start with the [hands-on Kafka tutorial](https://www.signadot.com/blog/kafka-step-by-step-tutorial/). #### Frequently asked questions How do you test event-driven architectures? Test against a shared baseline environment instead of duplicating brokers and consumers for every test. Each change runs in a sandbox: messages triggered by a test carry the sandbox's routing key in their metadata, every consumer variant sees the message stream, and a small consumption check ensures exactly one variant processes each message. This gives isolated end-to-end tests across producers, the broker, and consumers on one shared infrastructure. How does selective consumption decide which consumer processes a message? Each sandboxed consumer processes only messages whose routing key belongs to it, meaning its own sandbox's key plus the keys of any route groups that include it. The baseline consumer processes messages that carry no routing key or a key no sandbox claims. Consumers make this decision locally against a cached copy of the routing-key mapping served by a central Routes API. Does this approach work with brokers other than Kafka? Yes. The model relies on two broker features that are nearly universal: message metadata (headers or attributes) to carry the routing key, and a way for each consumer variant to see the message stream, such as consumer groups, subscriptions, or queue bindings. It applies to Kafka, RabbitMQ, Google Pub/Sub, AWS SQS, and similar systems. How do you test event-driven flows that do not start with a request, like CDC or cron jobs? There is no incoming request to carry the routing key, so embed the routing metadata at the source instead: a metadata column that the CDC producer copies into message headers, or per-tenant tagging in the job that generates the messages. Once the key is in the message, the same selective consumption applies downstream. #### Related Posts *Image: What's the real ROI of writing Mocks?* integration-e2e-testing ##### What's the real ROI of writing Mocks? September 26, 2023 *Image: The wrong way to use DORA Metrics* integration-e2e-testing ##### The wrong way to use DORA Metrics April 1, 2024 *Image: Why AI Features Break Microservices Testing* integration-e2e-testing ##### Why AI Features Break Microservices Testing July 11, 2025 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Testing Microservices: Message Isolation for Kafka, SQS, More Source: https://www.signadot.com/blog/testing-microservices-message-isolation-for-kafka-sqs-more/ Summary: How the message-isolation pattern maps onto specific brokers, including Kafka, RabbitMQ, Google Pub/Sub, and AWS SQS. ### Testing Microservices: Message Isolation for Kafka, SQS, More Testing async workflows in microservices is a challenge—traditional staging setups are costly and unreliable. The message isolation pattern offers a scalable solution, enabling reliable testing without duplicating infrastructure. This article breaks down how it applies across Kafka, RabbitMQ, AWS SQS, Google Pub/Sub, and NATS. Reading time 7 min Author Arjun Iyer Published April 4, 2025 Topics [Integration/E2E Testing](https://www.signadot.com/blog/category/integration-e2e-testing/) _Originally posted on_ [_The New Stack_](https://thenewstack.io/testing-microservices-message-isolation-for-kafka-sqs-more/)_, by Arjun Iyer._ **The message isolation pattern works across most popular message brokers, while implementation details vary based on architecture and terminology.** When I talk to engineering leaders about testing event-driven microservices, I hear a common pain point: “Our async flows are nearly impossible to test reliably.” Previously, we explored how [OpenTelemetry and message isolation](https://www.signadot.com/blog/kafka-step-by-step-tutorial/) enable testing Kafka-based workflows without duplicating infrastructure. The approach resonated with many teams facing the challenge of testing asynchronous flows cost-effectively, but I’ve received numerous questions about extending this pattern to other message brokers. - “Does this work with AWS SQS?” - “Can we apply this to RabbitMQ?” - “What about Google Pub/Sub?” The short answer is yes. The message isolation pattern works across most popular message brokers but implementation details vary based on each system’s architecture and terminology. #### The Universal Pattern: Message Isolation Before diving into specific platforms, let’s recap the core problem and our approach: ##### The Problem Testing microservices that communicate via message queues presents several challenges: - Setting up separate test environments is expensive and difficult to maintain. - Async workflows are hard to verify without full-system tests. - Integration issues often appear only after code is merged. - Mocks frequently drift from reality, leading to false positives. ##### The Solution Our message isolation approach addresses these challenges through these key principles: 1. **Share infrastructure:** Use a single baseline environment accessible to all sandboxes. 2. **Propagate context:** Pass routing keys in message metadata via OpenTelemetry. 3. **Duplicate messages:** Allow both baseline and sandbox services to receive copies of the same messages. 4. **Selectively process:** Filter messages in consumers based on sandbox routing keys. The goal is straightforward: Enable multiple developers to test their changes in isolation without interference while avoiding the cost and complexity of duplicating your entire messaging infrastructure. #### Apache Kafka: The Reference Implementation Kafka remains our reference implementation for message isolation testing due to its robust consumer group model. In Kafka, multiple consumer groups can independently process the same messages from a topic, creating a natural pattern for our testing approach. With Kafka, each producer includes a routing key in message headers, and consumer groups provide the isolation mechanism. When a developer deploys their service version to test, it joins a unique consumer group (such as `my-service-group-sandbox123`), receiving a copy of all messages while the baseline version continues operating in its original consumer group. *Image: Kafka isolation pattern* #### RabbitMQ: Exchanges and Bindings RabbitMQ’s architecture differs from Kafka because it uses exchanges and bindings as intermediaries between producers and consumers, allowing more flexible routing patterns. In RabbitMQ, exchanges distribute messages to queues through bindings. The message isolation pattern works by creating temporary queues for sandbox services that are bound to the same exchanges as the baseline queues. For example, if your baseline service consumes from a queue bound to a topic exchange, your sandbox version would create a new temporary queue bound to the same exchange with matching routing keys. While RabbitMQ offers broker-level filtering through binding patterns, we still need consumer-side filtering to check the sandbox routing key against a central mapping service. The consumer would extract the routing key from the message headers, call a mapping service to determine if it should process the message and then proceed accordingly. *Image: RabbitMQ isolation diagram* #### Google Cloud Pub/Sub: Subscriptions Google Cloud Pub/Sub organizes messages around topics and subscriptions, making message isolation straightforward. A topic can have multiple subscriptions, and each subscription receives a copy of every message published to the topic – aligning perfectly with our sandbox model. For sandbox testing, create temporary subscriptions to the same topics your baseline services use. The subscriber would implement consumer-side filtering to extract the routing key from message attributes, check against the mapping service and process messages accordingly. *Image: Pub/Sub isolation diagram* #### AWS SQS: The Special Case AWS SQS presents a unique challenge for message isolation because it doesn’t natively support the fan-out pattern we rely on in other brokers. In SQS, messages are consumed by a single consumer; there’s no built-in mechanism for multiple consumers to receive the same message, and messages are automatically deleted after being processed. Therefore, we need to consider alternate approaches: Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) ##### Option 1: SNS + SQS Pattern Use Amazon SNS (Simple Notification Service) as the entry point to fan out messages to multiple SQS queues. Publishers send messages to an SNS topic, which delivers copies to multiple subscribed SQS queues — one for baseline, and separate ones for each sandbox environment. This approach requires no changes to existing consumers as they continue to read from their dedicated queues. ##### Option 2: Dedicated Test Queues Create temporary SQS queues for testing with sandboxed producers and consumers. Deploy a new instance of your producer that sends messages to the temporary test queue and configure your test consumer to read from this new queue. Each sandbox gets its own isolated queue, producer and consumer. For most teams, Option 1 provides the cleanest solution. Setting up an SNS topic that publishes to both your baseline SQS queue and any temporary testing queues maintains the decoupled architecture while enabling the isolation needed for testing. The overhead of message duplication is typically negligible compared to the cost of duplicating your entire infrastructure. *Image: SQS isolation diagram* #### NATS: Subjects and Queue Groups [NATS](https://nats.io/), with its lightweight and high-performance design, offers features well-suited for sandbox testing. We can leverage NATS queue groups, which function similarly to Kafka consumer groups. By creating sandbox-specific queue groups, test services receive copies of messages without interfering with baseline services. Your test service would join a unique queue group (such as `service-sandbox123`), subscribe to the same subjects as your baseline service and implement consumer-side filtering based on routing keys. *Image: NATS isolation diagram* #### Platform Team Implementation The message isolation approach becomes much more maintainable when platform teams build reusable components that handle the sandbox-specific logic. ##### Creating Sandbox-Aware Consumer Libraries Platform teams can create thin wrappers around standard client libraries that automatically handle sandbox filtering: Application developers use this exactly like the standard consumer: This approach makes the sandbox filtering completely transparent to application teams. ##### Sandbox Life Cycle Management Platform teams can provide standardized hooks around the life cycle of sandboxes that automate resource management: *Image: Diagram of sandbox lifecycle hooks that register the sandbox ID in the mapping service, create queue groups and subscriptions, and clean up all sandbox resources on deletion* When a developer creates a new sandbox for testing: - The platform automatically registers the sandbox ID in the central mapping service. - Necessary consumer groups, queues or subscriptions are created with consistent naming `(service-{sandbox-id})`. - When testing completes, all sandbox-specific resources are automatically removed. This hook-based approach makes sandbox isolation part of the platform’s core capabilities rather than a burden on each development team. #### Conclusion Message isolation patterns work across all major message brokers, though implementation details vary based on each system’s architecture. The approach consistently delivers three key benefits: 1. **Cost efficiency:** Share infrastructure instead of duplicating it. 2. **Testing fidelity:** Test against real dependencies instead of mocks. 3. **Developer velocity:** Catch issues earlier in the development process. At [Signadot](https://www.signadot.com/), we’ve implemented these patterns across dozens of customer environments using different messaging systems. Companies like [Brex](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/), [Earnest](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) and [ShareChat](https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/) have used these approaches to transform their microservice testing. If you’re interested in exploring how to apply these concepts to your specific environment, sign up and join our [community Slack channel](https://signadotcommunity.slack.com/join/shared_invite/zt-1estxm8pv-qfiaNfiFFCaW~eUlXsVoEQ#/shared-invite/email). As microservice architectures continue to evolve, effective testing of asynchronous workflows becomes increasingly critical. The message isolation pattern provides a practical, scalable approach regardless of which message broker you’ve chosen. #### Related Posts *Image: Tutorial: Preview Environments for Features Across Multiple Microservices* integration-e2e-testing tutorials-guides ##### Tutorial: Preview Environments for Features Across Multiple Microservices February 6, 2023 *Image: How to Test Event-Driven Architectures Without Duplicating Infrastructure* integration-e2e-testing ##### How to Test Event-Driven Architectures Without Duplicating Infrastructure August 16, 2024 *Image: Who Should Run Tests? On the Future of QA* integration-e2e-testing ##### Who Should Run Tests? On the Future of QA June 28, 2024 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## What Is Shadow Testing? Four Ways to Bulletproof Your APIs Source: https://www.signadot.com/blog/shadow-testing-superpowers-four-ways-to-bulletproof-apis/ Summary: What shadow testing is, how it compares to canary releases and feature flags, whether to run it in staging or production, and four ways teams use it before merge. ### What Is Shadow Testing? Four Ways to Bulletproof Your APIs Shadow testing runs a new version of a service alongside the current one in an isolated pre-production sandbox, sends both the same representative traffic, and compares the responses, so you catch API contract breaks, performance regressions, hidden log patterns, and security issues before they reach production. This guide covers four things shadow testing unlocks, how it differs from canary releases and feature flags, and why it is becoming the way AI coding agents validate their changes in isolation on a shared cluster. Reading time 11 min Author Arjun Iyer Published April 21, 2025 Updated August 31, 2026 Topics [Integration/E2E Testing](https://www.signadot.com/blog/category/integration-e2e-testing/) **Shadow testing means running a new version of a service alongside the current version in an isolated pre-production environment, sending both the same representative traffic, and comparing their responses to catch regressions before release.** No real user ever sees the unreleased version, which is what makes it safe to test changes that would be too risky to canary. I’ve spent the last 20+ years building distributed systems, and one truth remains constant: [microservices testing](https://www.signadot.com/the-complete-guide-to-microservices-testing-from-local-development-to-production/) is challenging. Shadow testing is a powerful approach to validate microservice changes safely because engineering leaders are eager for better ways to test complex [microservice architectures](https://www.signadot.com/blog/how-microservices-communicate-with-each-other/). Before getting into what shadow testing unlocks, it is worth being precise about what it is, and what it is not. #### What Is Shadow Testing? The detail that matters most for everything below is where this runs. Shadow testing happens in an isolated, pre-production sandbox, not against live production. The “same traffic” sent to both versions is usually synthetic or replayed requests crafted to closely mimic real conditions, routed to an isolated copy of the changed service running against the shared baseline. The closer that representative traffic is to the real thing, the more useful the result, but no real user is ever in the loop. ##### Shadow Testing vs. Canary Releases and Feature Flags That is what separates shadow testing from two approaches it often gets confused with: - **Canary releases** roll a change out to a small slice of real users and watch for problems. Failures still reach those users. Shadow testing runs before anyone sees the change. - **Feature flags** turn functionality on and off at runtime. They are useful for controlled rollouts, but they sit late in the lifecycle and do not give you a clean comparison of old behavior against new. Shadow testing is a shift-left technique: it catches regressions, contract breaks, and performance issues early, inside a sandbox, without the brittleness of hand-maintained integration tests. The real magic happens when we leverage this parallel execution to derive actionable insights that traditional testing methods simply can’t provide. Let’s explore four powerful testing approaches that shadow testing enables, each providing unique signals that help developers ship with confidence. #### 1\. API Contract Testing: Detecting Breaking Changes API contract testing is perhaps the most immediately valuable application of shadow testing. Traditional [contract testing relies on mock services](https://www.signadot.com/blog/why-developers-shouldnt-write-mocks-a-guide-to-modern-testing/) and schema validation, which can miss subtle compatibility issues. Shadow testing takes contract validation to the next level by comparing actual API responses between versions. Here’s how it works: 1. Deploy your updated service alongside the baseline version. 2. Route identical traffic to both versions. 3. Compare the responses in real time. 4. Identify any divergence that indicates potential contract breaks. This approach catches breaking changes that would be invisible to conventional testing: field type changes, new required fields, altered error responses and even performance degradation that might violate service-level agreements (SLAs). This approach combines the best of specification-based contract testing with runtime validation. Rather than just checking if your new API implementation conforms to a static specification, you’re directly measuring compatibility with everything currently consuming it. *Image: API Contract Testing with Shadow Testing* For instance, when a team at a fintech company implemented this approach, it caught a subtle breaking change where a field was being converted from string to integer, something its OpenAPI validators hadn’t flagged, but that would have broken several downstream consumers. The shadow testing system highlighted the discrepancy immediately, allowing the team to fix it before merging. #### 2\. Performance Testing: Compare Side by Side Performance testing is another area where shadow testing shines. [Traditional performance testing usually happens late in the development cycle](https://www.signadot.com/blog/microservices-testing-cycles-are-too-slow/) in dedicated environments with synthetic loads that often don’t reflect real-world usage patterns. With shadow testing, you can: 1. Run your new code against realistic, production-like traffic patterns. 2. Compare key metrics against the baseline version in real time. 3. Identify performance regressions before they affect users. 4. Validate that optimizations actually deliver expected improvements. This approach is particularly powerful when combined with canary analysis tools like [Kayenta](https://github.com/spinnaker/kayenta), which can automatically analyze statistical significance in performance differences. *Image: Performance/Load Testing with Shadow Testing* A retail platform I worked with used this approach to validate a major database query optimization. While its synthetic benchmarks showed a 40% improvement, [shadow testing against real traffic](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/) revealed edge cases where certain user queries were performing worse. The team was able to address these issues before deploying, avoiding what would have been a serious production incident during the company’s peak shopping season. The beauty of this approach is that it doesn’t just test whether your code functions correctly, it tests whether it functions correctly under real-world conditions with diverse traffic patterns that would be nearly impossible to simulate accurately. #### 3\. Log Analysis: Uncovering Hidden Issues Log analysis is often overlooked in traditional testing approaches, yet logs contain rich information about application behavior. Shadow testing enables sophisticated log comparisons that can surface subtle issues before they manifest as user-facing problems. With log-based shadow testing, you can: 1. Capture logs from both baseline and test versions. 2. Apply machine learning (ML) clustering to identify new or changed log patterns. 3. Highlight potentially problematic log sequences. 4. Discover errors, warnings or unexpected behaviors that might not trigger test failures. *Image: Log Analysis with Shadow Testing* I’ve seen this approach catch issues that would have slipped through every other testing layer. One engineering team discovered their new code was generating a cluster of database connection warnings that weren’t present in the baseline version. While these warnings didn’t cause immediate failures, they were an early indicator of connection pool exhaustion that would have eventually led to cascading timeouts under load. This approach bridges testing and observability, creating a feedback loop that helps developers understand the operational impact of their changes before deployment. #### 4\. API Security Analysis: Shift-Left Security Validation Perhaps the most innovative application of shadow testing is in the security domain. Traditional security testing often happens too late in the development process, after code has already been deployed. Shadow testing enables a true shift left for security by enabling dynamic analysis against real traffic patterns. The approach works like this: 1. Deploy your service changes to a sandbox environment. 2. Run security scanning tools like OWASP ZAP against the sandboxed version. 3. Identify and fix security vulnerabilities before merging your code. 4. Prevent security issues from reaching production in the first place. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) ##### Runtime Security Analysis With Shadow Testing Zed Attack Proxy (ZAP) is an open source security tool that acts as a “man-in-the-middle” proxy, intercepting and inspecting messages between client and server. It automatically scans for security vulnerabilities by analyzing responses and simulating attacks to discover weaknesses like SQL injection, cross-site scripting and authentication flaws. *Image: Runtime Security Analysis with Shadow Testing* This approach is particularly powerful for detecting issues like new API endpoints that might be missing authentication checks, input validation flaws or information disclosure vulnerabilities, all before your code gets merged. Automated security testing embedded in CI/CD pipelines has moved from a differentiator to table stakes, and shadow testing provides an ideal framework for this kind of automated security validation. By integrating security scanning directly into your pre-merge testing workflow, you catch vulnerabilities during development when they’re easiest and cheapest to fix. This eliminates the traditional security bottleneck where issues are discovered late in the development cycle, requiring costly rework and delaying releases. #### Self-Maintaining Tests: Automatic Pattern Detection What makes these shadow testing approaches particularly valuable is their inherently low-maintenance nature. Unlike traditional testing approaches that require constantly updating test suites, mocks and assertions, shadow testing uses representative traffic and automated comparisons to detect issues with minimal human intervention. The power lies in the baseline comparison: by running both versions side by side and automatically identifying differences in behavior, these tests essentially write themselves. They can detect subtle issues, emerging patterns and regressions without requiring engineers to anticipate every possible edge case. This fundamentally changes the testing paradigm. Instead of spending countless hours maintaining brittle test fixtures, teams can focus on building features while automated differential analysis provides the safety net. The pioneers of microservices at companies like Netflix and Uber have been using variations of these techniques for years. The difference now is that modern tools are making these low-maintenance, high-signal testing approaches accessible to engineering teams of all sizes. #### How shadow testing works in practice The mechanics are the same wherever you run it, and the pattern was pioneered by tools like [Diffy](https://blog.x.com/engineering/en_us/a/2015/diffy-testing-services-without-writing-tests), built at Twitter to test services by comparing responses instead of writing assertions. Three things happen: - **Traffic execution.** The new version (V-Next) runs alongside the current version (V-Current), and both receive the same requests. That gives you a direct, apples-to-apples comparison of behavior. - **Response comparison.** Outputs are captured and diffed to surface regressions. A good implementation uses a [relevancy model](https://www.signadot.com/blog/rest-api-testing-using-relevancy-weighted-diffs/#calculating-diff-operation-relevance) to decide which differences matter and which are benign noise, like timestamps or reordered fields, so you are not buried in false positives. - **Observability and metrics.** Performance and error patterns from both versions are analyzed to confirm the change is stable before it goes any further. As Microsoft’s [Engineering Fundamentals Playbook](https://microsoft.github.io/code-with-engineering-playbook/automated-testing/shadow-testing/) describes it, shadow testing captures the differences between the current environment and a candidate environment, then reduces risk before you introduce the new release. *Image: Shadow testing: a new version runs alongside the current one, both get the same traffic, their behavior is compared, and the new version is validated* ##### Where Do You Run Shadow Testing: Staging or Production? Where you run it is a choice. **Staging shadow testing** is easier to set up, sidesteps compliance and data-isolation concerns, and uses synthetic or anonymized traffic. **Production shadow testing** gives the most accurate signal from live traffic but needs real safeguards for data handling and workload isolation. For most teams an isolated sandbox on a shared pre-production cluster hits the sweet spot. That is exactly what [SmartTests](https://www.signadot.com/docs/concepts/smart-tests-and-jobs) are in Signadot. Shadow testing is the technique; a SmartTest is that technique packaged as a runnable test. Each run spins up an isolated sandbox for a branch, sends representative traffic to the changed service alongside the baseline, and compares request and response behavior in real time, using a relevancy model to separate meaningful regressions from benign noise. There are no assertions to write and no mocks to maintain, and it runs in Kubernetes with Istio, Linkerd, or no service mesh at all. *Image: Signadot SmartTests comparing a baseline and a sandboxed version of a service* #### Why this matters more now that agents write the code A growing share of code is now written by AI coding agents like Claude Code, Codex, and Cursor, and they produce changes far faster than anyone can hand-review them. Writing the change is no longer the hard part. Knowing whether it is safe to merge is. That is exactly the signal shadow testing produces. Shadow testing also fits how agents work better than almost any other method, because it needs no hand-written assertions. The agent makes a change, its version is deployed into an isolated sandbox on the shared cluster, the same representative requests are sent to both the agent’s version and the baseline, and the differences are compared automatically. The agent does not have to anticipate every edge case or maintain a brittle suite. It gets a direct, behavioral answer: here is what your change does differently, and whether that difference is a regression. The isolation is what makes this work at agent speed. Each change is tested against the real, shared baseline without standing up a full environment of its own and without colliding with the other agents and developers doing the same thing. Many changes can be validated in parallel on a single cluster. This is the same request-level isolation behind [ephemeral environments on Kubernetes](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/), applied to differential testing. In Signadot this is delivered through [SmartTests](https://www.signadot.com/docs/concepts/smart-tests-and-jobs), which let an agent kick off a shadow comparison the same way it runs any other test. Paired with [Jobs](https://www.signadot.com/docs/reference/jobs) and [Plans](https://www.signadot.com/docs/reference/plans), an agent can run the comparison, read the result, and decide whether its change is ready, all before it opens a pull request. For the wider picture, see [validating AI-generated code on Kubernetes](https://www.signadot.com/validate-ai-generated-code-kubernetes/). #### Conclusion Shadow testing is unlocking a new generation of testing approaches that provide deeper insights and more confidence than traditional methods. By detecting API contract issues, performance regressions, suspicious log patterns and security vulnerabilities before they reach production, teams can ship faster with greater confidence. If you’re interested in exploring how shadow testing could transform your microservices testing strategy, I’d love to continue the conversation. Check us out at [signadot.com](https://www.signadot.com/) or join our community discussions. The future of microservices testing isn’t just about running more tests earlier, it’s about getting better signals that truly predict production behavior. Shadow testing is leading this evolution, proving that with the right approach, we can have both speed and quality. #### Frequently asked questions What is shadow testing? Shadow testing runs a new version of a service alongside the current version in an isolated pre-production sandbox, sends both the same representative traffic, and compares their responses to catch contract breaks, performance regressions, and other issues before release. Is shadow testing done in production? Usually not. Shadow testing typically runs in an isolated pre-production sandbox using synthetic or replayed traffic that closely mimics real conditions. Some teams mirror live production traffic into a shadow copy, but that requires strict safeguards for data handling, and no real user ever receives a response from the unreleased version. What is the difference between shadow testing and a canary release? A canary release rolls a change out to a small slice of real users, so failures still reach those users. Shadow testing compares the new version against the baseline on the same traffic before any user sees the change, making it a shift-left technique rather than a rollout strategy. How do Signadot SmartTests relate to shadow testing? SmartTests are shadow testing packaged as a runnable test primitive. Each run spins up an isolated sandbox, sends representative traffic to the changed service alongside the baseline, and uses a relevancy model to surface meaningful differences. AI coding agents use them to validate changes automatically before opening a pull request. #### Related Posts *Image: Why large engineering teams are testing on Kubernetes* integration-e2e-testing ##### Why large engineering teams are testing on Kubernetes May 3, 2023 *Image: Testing Event-Driven Architectures with OpenTelemetry* integration-e2e-testing ##### Testing Event-Driven Architectures with OpenTelemetry August 9, 2024 *Image: Improve Developer Velocity by Decentralizing Testing* integration-e2e-testing ##### Improve Developer Velocity by Decentralizing Testing March 23, 2024 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- # Customer Case Studies ## Brex Source: https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/ Summary: How Brex scaled developer testing across 100s of engineers and coding agents, cutting preview infrastructure costs by 99% and saving about $2 million annually by replacing full environment duplication with Signadot sandboxes. *Image: Brex logo* ### How Brex Uses Signadot to Scale Developer Testing Across 100s of Engineers and Coding Agents Brex ran preview environments the way many fast-growing platform teams do. Any developer who wanted to test a change got a duplicated Kubernetes namespace running the entire application. At 800+ microservices, that model stopped working. The environments were pushing the scaling limits of a single Kubernetes control plane, the compute bill for running hundreds of services per developer was enormous, and they broke often enough that teams stopped maintaining them and pushed their testing into staging instead. Brex replaced that model with Signadot, which creates isolated sandboxes (lightweight ephemeral environments) inside a single shared cluster. Only the deltas of the one or two services a developer or a coding agent are working on get duplicated. Every other dependency is served by the shared cluster, with real data and real traffic patterns. > “Signadot for the preview environments use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff that we were looking at. And the return on the investment was obvious… just in infrastructure costs, it saves us about $2 million annually.” Phil Burrows · Head of Platform Engineering, Brex #### About Brex [Brex](https://www.brex.com/) is the finance platform that startups and enterprises use to run corporate cards, expenses, bill pay, banking, and accounting in one system. Their product strategy is built around intelligent finance: AI that reads receipts, drafts expense reports, codes transactions to the general ledger, and enforces spend policy on its own, to the point where the majority of expenses on the platform are prepared with no human involvement at all. Delivering that requires real engineering scale: - **800+ microservices** running on Kubernetes - **300+ engineers** shipping into a shared monorepo - A platform team responsible for the testing and preview infrastructure all of them depend on Brex is also at the forefront of agentic engineering inside its own organization, with autonomous coding agents and agent-driven workflows adopted deeply across the engineering team. Their engineering blog documents that work in posts like [Building autonomous agents for technical tasks](https://www.brex.com/journal/building-autonomous-agents-for-technical-tasks). Signadot is a big part of the infrastructure that supports it, giving engineers and agents alike realistic environments to validate their changes in. #### Results at a Glance Infrastructure Cost −99% about $2 million saved annually Service Preview <5 mins down from 30 to 60 minutes Developer CSAT +28 pts versus the previous platform tooling #### The Problem: Preview Environments Nobody Maintained Preview environments in Kubernetes namespaces were powerful when Brex first built them. Each one was a duplicated namespace that gave a developer an isolated copy of the application to test and experiment against. The model degraded as the service count climbed: - Each environment ran enough microservices to push the scaling limits of a single Kubernetes control plane - Availability problems made the environments unreliable, and unreliable environments do not get maintained - Teams routed around them and tested in staging instead, which broke staging more often and blocked everyone else - Replicating 800+ services so a developer could change one or two of them was extraordinarily expensive > “The primary problem is just the cost of getting something wrong or breaking something in a preview environment was never high enough to prevent folks from leaving things broken. And so they were constantly in a state of disrepair.” Connor Braa · Software Engineering Manager, Brex ##### Teams routed around the problem The downstream effect was that entire groups abandoned realistic testing. As Connor Braa, Software Engineering Manager at Brex, described it, “There was a group of teams building very important product features that just eschewed development against preview environments entirely, and instead focused on unit tests. After unit tests, it was tested on Staging, and were required to use feature flags way more heavily. It made the data quality and reliability problems with moving to staging way worse.” When the first high-fidelity test of a change happens in staging, staging breaks more often, other teams get blocked, and delays compound across the org. ##### The cost of duplicating everything The reliability problems came with a bill attached. > “The other big problem is cost, having isolated environments for our internal software that’s hundreds of microservices solely for the purpose of testing gets insanely expensive. We’re talking about replicating 800+ services just so a developer can test changes on 1-2 services. That’s a great deal of compute and memory.” Connor Braa · Software Engineering Manager, Brex There are hidden costs too. When a team does not feel like it is working at its best, that hurts retention, job satisfaction, and performance. Connor describes it as developers not feeling like they have the tools to ship the quality of software they want to ship. With engineering hires costing six figures, it is worth asking whether your team can afford to lose people because they are frustrated at not being able to ship. #### The Solution: Isolation Inside the Shared Cluster Signadot changed what has to be duplicated. Instead of standing up a copy of the application per developer, a sandbox holds only the changed versions of the one or two services being worked on. Requests carrying a routing key are directed through those sandboxed services, and every other call is served by the stable version already running in the cluster. Sandboxes spin up in seconds because there is almost nothing to start, and a time-to-live setting shuts them down automatically, so abandoned environments stop accumulating cost. requestrouting key: alice-1Kubernetes clusterSandboxservice-1'service-1service-2 The routing key sends one hop through the Sandbox. Every other hop is served by the shared stable cluster. requestrouting key: alice-1Kubernetes clusterSandboxservice-1'service-1service-2 The routing key sends one hop through the Sandbox. Every other hop is served by the shared stable cluster. ##### Testing on staging without the blast radius The switch did not require Brex to change how developers work, and that was part of the appeal. What it changed is where the first realistic test happens. Because a sandbox costs almost nothing to create and needs no upkeep, running integration tests alongside unit tests in the inner loop became the default rather than a luxury, and integration problems started surfacing before code review instead of after merge. It also dissolved the maintenance problem that had killed the old preview environments. Staging is an environment with real consequences attached, so it stays healthy as a matter of course, and sandboxes inherit that health rather than depending on each team’s willingness to maintain a separate environment. > “Staging has always been a place where we have a bit higher standard. It needs to be working, and there are real business consequences when it breaks. Being able to run Signadot in Staging alleviates this pressure where no one wants to maintain a separate dev environment just for dev testing.” Connor Braa · Software Engineering Manager, Brex ##### Data quality nobody has to fight for Testing in staging also solved a problem that replicated environments never could: the data. Connor is direct about this. The data quality on staging and production is far higher than anything a replication environment offers, which makes testing there fundamentally more realistic. Brex could have invested in making dev environment data realistic. But that would have required a huge cultural shift across every team to prioritize it, and in his words, changing everyone’s behavior is not a road a platform team wants to go down. With Signadot, realistic data is simply a property of the environment the sandboxes already live in. #### Accelerating Testing: A Tale of Two Loops Any engineering org larger than a few people tests code changes in two loops: - **The inner loop.** A developer or an agent changes the code and sees the result right away, while the change is still fresh and the context is still loaded. - **The outer loop.** Changes are validated after code has been reviewed and merged to main, where a failure costs far more to diagnose and fix. Brex wants as many bugs as possible caught on the inner loop. With Signadot, an individual developer or coding agent creates a sandbox and runs an accurate test of their service against every dependency it needs, on the shared cluster. Combined with unit tests, that pulls a large class of integration problems forward, ahead of the pull request rather than after it. That matters more as agents write more of the code. An agent that can only run unit tests hands its work back to a person for real validation. An agent with its own sandbox can exercise the change against live dependencies and iterate until it passes, so what arrives at the pull request has already been checked. #### The Results ##### Cost With Signadot, only the services being tested are replicated. With duplicated environments, Brex was running 800+ services so that a developer could work on one or two of them. Connor puts the waste in blunt terms: on the margin, 99.8% of a duplicated environment’s infrastructure cost went to services nobody was testing, a figure he notes sounds like an exaggeration but is not. Eliminating that waste is what produces the roughly $2 million in annual infrastructure savings, and it is why the return on investment was obvious to Brex’s platform engineering leadership from the start. ##### Velocity The cost savings changed the budget. The speed changed the day-to-day experience. Standing up a namespace-based preview environment meant deploying hundreds of services and waiting for all of them to become healthy. A sandbox deploys one. > “A typical deploy in our Signadot based tooling, end-to-end, is less than five minutes versus the 30-60 minute deploy times we would see with preview environments. Local sandboxes allow us to take that down to almost instantaneous testing.” John Salem · Senior Software Engineer, Brex A preview in under five minutes keeps a developer in flow while the change is still fresh. For coding agents it matters even more, since a fast environment is the difference between validating every iteration and validating none of them. ##### Satisfaction For a platform team, the development org’s Customer Satisfaction (CSAT) score is the number that says whether the tooling actually works for the people using it. Brex measures CSAT on its internal platform tooling, and John Salem reports that the Signadot-based tooling scored 28 points higher than the older platform engineering tech it replaced. Taken together with the cost and speed numbers, the platform team got something rare: an infrastructure change that saved money, sped developers up, and made them happier at the same time. #### Conclusion: Signadot for Developer Velocity Moving preview environments to Signadot addressed the cost, reliability, and efficiency problems that had made Brex’s previous system unusable. Isolated sandboxes inside a shared staging cluster gave developers realistic testing without the overhead of maintaining hundreds of duplicated services, and without the risk of one person’s broken change blocking everyone else. As coding agents become a bigger part of the workflow at Brex, the same isolation and speed that accelerated human developers now gives agents the infrastructure to validate their own changes autonomously. That is the piece that turns an agent from something that writes code into something that ships it. To see how lightweight ephemeral environments can work for your team, [sign up for free](https://www.signadot.com/signup/) or [book a demo](https://www.signadot.com/schedule-a-call/). More Customer Stories [ *Image: Laurel logo* How Laurel Brings Production‑Ready Validation to AI‑Native Development Read case study → ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/)[ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Bitso logo* How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Read case study → ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## DoorDash Source: https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/ Summary: How DoorDash developers achieved 10x faster feedback loops on code changes using Signadot's ephemeral sandbox environments. *Image: DoorDash logo* ### How Developers and Coding Agents at DoorDash Get 10x Faster Feedback on Code Changes *Image: How Developers and Coding Agents at DoorDash Get 10x Faster Feedback on Code Changes* #### DoorDash Overview DoorDash is a technology company that connects consumers with their favorite local businesses in more than 25 countries across the globe. Founded in 2013, DoorDash builds products and services to help businesses innovate, grow, and reach more customers. DoorDash employs a multi-tenant architecture consisting of 100s of microservices operating on Kubernetes. Due to their on-demand service, the company’s extensive engineering team must innovate rapidly while ensuring minimal disruption for customers. To achieve this, DoorDash leverages end-to-end feature testing on their production environment. * * * #### Before Signadot Spinning up new Docker images for changes proved to be a time-consuming process, taking more than 30 minutes for each deployment. Additionally, if a team introduced a new change with regressions, staging would break. This significantly impacted other teams waiting for the change to be fixed or rolled back, causing further delays and inefficiencies. Relying on unit and mocked CI tests proved inadequate since they did not address the dynamic end-to-end functionality. Furthermore, developers wanted greater control over the specific user flows that required testing. Maintaining the accuracy and reliability of the staging environment independently proved to be a challenging task at the scale the team was operating. The difficulties in ensuring the fidelity of the staging environment made it harder for developers and agents to accurately test their changes before deploying them to production. These challenges created a bottleneck in the development process and hindered the team’s ability to deliver features quickly and efficiently. * * * #### After Signadot Signadot’s vision of providing developers and agents with early access to high fidelity testing in the development workflow aligned with DoorDash’s long term vision. Recognizing the potential benefits, DoorDash made the strategic decision to remove the staging environment entirely and adopt Signadot’s approach. As a result, developers and agents at DoorDash now have the ability to safely test their changes directly in the production environment from their laptops or agent runtimes. This shift allows for more efficient and streamlined testing, enabling developers and agents to iterate and refine their work with greater speed and accuracy. * * * #### How Developers use Signadot DoorDash developers make code changes to their microservice(s) locally on their workstations, creating a “Local Sandbox” environment that has a unique identifier. In order to test these changes end-to-end in production, developers access the Web front end and utilize a Chrome Extension to specify the identifier associated with their Local Sandbox. Signadot ensures that these end-to-end flows are routed to the correct local workstation based on the unique identifier. *Image: doordash screenshot 2 copy* When it comes to testing from the mobile App, they use a debug version of the mobile app that enables them to enter the identifier corresponding to their Local Sandbox. By leveraging Signadot’s operator, all requests from this session are routed to the version of the backend Service(s) running on the developer’s workstation. This setup enables the locally running service to interact with the services running in the production environment, facilitating end-to-end testing. *Image: doordash screenshot copy* With this workflow in place, developers now have the capability to thoroughly test specific user flows in the production environment from the front end. This approach gives them a high level of confidence in the functionality and stability of their code changes when deployed to production. By eliminating the need for a separate staging environment, this streamlined process enables developers to iterate and refine their work more efficiently, reducing potential bottlenecks and improving overall development speed. > “Our vision when we started talking to Signadot was that we wanted to have the same stack for testing and production. Signadot has allowed us to do just that, bringing down the lead time for our developers to test changes from 30 minutes to literally 60 seconds.” Amit Gud · Software Engineer, DoorDash * * * #### Results **30 minutes → 60 seconds.** DoorDash developers and agents now test changes end-to-end against the production environment in under a minute — with fewer rollbacks, reduced production incidents, and significantly lower cloud costs. The implementation of Signadot’s workflow has significantly reduced the time required for high-fidelity testing from the front end during each iteration. Previously, developers had to wait for CI or deployments to the staging environment, which took around 30 minutes. Now, with the new approach, developers can complete their testing within a few minutes directly from the front end. *Image: DoorDash development workflow from local development and local testing to pull request validation and production* Developers benefit from a rapid iteration process on their local workstations. With Signadot, each change is quickly [tested end-to-end against the production environment](https://doordash.engineering/2022/06/23/fast-feedback-loop-for-kubernetes-product-development-in-a-production-environment/) within a few minutes. This also incentivizes developers and agents to engage in more ad-hoc testing, allowing them to validate their code changes effectively. As a result, the number of rollbacks and production incidents has decreased, saving valuable developer time. With fewer disruptions caused by issues or bugs, developers and agents can focus their efforts on building new features, enhancing productivity and enabling teams to make progress in delivering innovation to users. Additionally, the elimination of the pre-production environment has significantly reduced cloud costs for DoorDash. Resources are allocated more efficiently, resulting in a more streamlined and cost-effective development process that scales naturally as agents increase the volume of changes flowing through the pipeline. More Customer Stories [ *Image: Laurel logo* How Laurel Brings Production‑Ready Validation to AI‑Native Development Read case study → ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/)[ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Bitso logo* How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Read case study → ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Earnest Source: https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/ Summary: How Earnest shifted testing left, empowering developers to catch bugs earlier in the development cycle with isolated sandbox environments. *Image: Earnest logo* ### Shifting Left with Signadot: How Earnest Empowered Developers for Early Testing *Image: Shifting Left with Signadot: How Earnest Empowered Developers for Early Testing* ##### Enabling more reliable release process and a better Developer Experience Fintech company Earnest is a technology-lender that brings low-interest loans to high-potential people. With both a platform engineering and developer experience team, Earnest maintains focus on a secure, efficient release process with as few surprises as possible. With Signadot, the Developer Experience (DevEx) team was able to automate end-to-end and integration tests. This gave engineers better insight into how their services are running during a test, and caused more reliable commits to Staging. I recently got the chance to sit down with Early Ehlinger, lead on the Earnest DevEx team, and Daniel Jimenez, Infrastructure DevEx Engineer, to talk about their journey to test automation with Signadot. * * * #### Why Earnest needed Signadot As we at Signadot have written in the past, testing and experimentation can become quite difficult as microservice architecture gets more complex. When you don’t have reliable, high-accuracy integration tests before pushing to staging, the result is more out-of-band bug fixes as your team tries to diagnose problems. Without Signadot, developers at Earnest didn’t have ready access to a testing Sandbox that included up-to-date dependencies for their service. This meant that releases were often handed off without 100% confidence that the code would pass integration testing. This meant having a separate team identify the problem, try to diagnose it, and then reach out to the original product team with a description of the problem — adding friction and hurting developer velocity. > “Signadot is a key part of our solution for the most critical parts of our testing pyramid. For integration and end-to-end testing we need to have a sandbox up and running because they need a live service to talk to.” Early Ehlinger · Dev Experience Lead, Earnest Signadot uses requests isolation to let multiple teams use a single high-fidelity cluster for testing and to try out new features, without their changes impacting other teams. For Earnest, their first use of Signadot was to allow users to create sandboxes manually: designating the services that the engineer wanted to ‘fork’ and letting this forked service interact with the baseline environment. * * * #### Moving to automated Sandboxes From manual sandboxes, the Developer Experience team found it easy to move to an automated system: “We’d been trying Signadot, letting people manually create sandboxes, for a while so switching over to automatically creating sandboxes and running tests was a pretty smooth process.” — Daniel Jimenez, Infrastructure DevEx Engineer, Earnest The team was highly motivated to improve the performance of integration testing. As Early put it: “We were looking for what can we do from an infrastructure perspective without going in and rewriting all the tests to make them fast? Previously we were parallelizing tests, but we’re doing it by hand. So you’d still end up with chunks of like 10 or 20 tests that would run in series and so they would take like, you know, 30 minutes to an hour. Whereas, the longest run on any individual test might have been 10 minutes.” This led the team to migrate Testkube so that the same tests, with the same execution time, could run faster by running in parallel. Early described the advantages: “What’s nice about Testkube is you can very easily set things up so that an individual source file in your Cypress repo or your Mocha repo or whatever, correlates to a single test in Testkube. If you design things right, we can run all of the tests in a suite in parallel. If you parallelize it, that whole chunk takes only 10 minutes instead of an hour. And we saw really drastic improvements in terms of speed just by letting something run everything in parallel for us.” Once that work was done, all that was needed to integrate Signadot was to make sure the [routing key](https://www.signadot.com/docs/concepts/sandbox) was available for the test suite, so that it could supply the appropriate request header while testing. As Early noted, “Our Dev Ex team is able to maintain all the test setup and sandbox spec in our Jenkins library. With a standard naming convention, you can automatically flag a deploy to create a sandbox for testing.” Teams leverage Cypress to automate end-to-end testing of applications deployed in Kubernetes clusters, ensuring each component interacts seamlessly across the orchestrated environment. **Before Signadot:** 30–60 minute test cycles, sequential execution, issues discovered post-staging. **After Signadot:** 10-minute parallel test runs, developer-first issue detection, reliable automated integration tests for every commit. * * * #### Testing the critical paths For fintech companies like Earnest, the steps a user takes on a path to conversion can be extremely high-stakes. Earnest helps students apply for financial services, and the steps along that path need to work with every deployment. Daniel Jimenez described the process: “Basically an integration test goes through the flow of any of our products and emulates a user interaction. There are tests to emulate every critical part of our flow, such as document signing. There’s a test to create a loan application, and check to see if the applicant was approved or not, whatever it’s expecting. Then a separate test that will go into an existing application, see that an offer has been made, and verify that you get a .pdf and that you can sign it.” One of the key benefits of Signadot is the amount of insight offered into the services under tests: > “People really like Signadot. They like being able to go in and see their service’s logs, and they find it really useful to go in and see the errors from their service during a test, catching problems before they emerge on Staging.” Daniel Jimenez · Infrastructure DevEx Engineer, Earnest While any organization can take the time for extensive testing on Staging, the key advantage of a Signadot-enabled process is that it’s the developers who are aware of a problem first, before their code reaches staging. This means that the person working on the feature has direct knowledge of the problem and can work on a fix directly, rather than waiting for later feedback from a software testing team. * * * ##### Front-end focused testing with Signadot Signadot isn’t just a tool for backend developers maintaining a microservice, it also helps developers working closer to the frontend to preview changes that involve one or multiple updated microservices. Kai Rillet, a software engineer at Earnest, led an effort to get more developers to preview changes using Signadot’s routing key right from their browser. By adding a header with a simple browser plugin, any developer can preview a sandbox based on their or another developer’s branch. This ability to preview frontend changes with all the normal dependencies hosted in a shared cluster means that developers can be more confident their changes interact with every other service correctly. * * * #### Giving testing power to the developers While the initial setup of the Signadot integration and end-to-end tests was completed by the developer experience team, the Earnest engineering org would like to move toward a model where developers manage these more complete tests directly. > “Developer Experience had a really easy time setting up the integration and migrating our current suite of integration tests to using Signadot. As an org we want to migrate to having the developers maintain these. Individual developers don’t mind writing unit tests, but it requires a cultural shift to have them write and maintain integration tests.” Early Ehlinger · Dev Experience Lead, Earnest However this breakdown of work develops, Signadot will remain a key component of the process for creating highly accurate test environments to test new changes. * * * #### Conclusion: meeting testing and reliability challenges Earnest’s integration of Signadot into their release process represents a significant leap forward in the realm of automated testing and reliable deployment strategies. By leveraging Signadot’s capabilities for creating isolated sandboxes and automating end-to-end and integration tests, Earnest has not only streamlined their development workflow but also enhanced the reliability and security of their releases. This approach has empowered developers with direct insights into their service’s performance during tests, enabling quicker identification and resolution of issues before they escalate to staging environments. The shift towards automated sandbox creation and the emphasis on testing critical user paths reflect a proactive approach to software development that prioritizes user experience and system reliability. Tools like Signadot are not just facilitating more efficient testing processes; they are reshaping the very dynamics of team collaboration and product development. More Customer Stories [ *Image: Laurel logo* How Laurel Brings Production‑Ready Validation to AI‑Native Development Read case study → ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/)[ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Bitso logo* How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Read case study → ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Bitso Source: https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/ Summary: How Bitso scaled branch-based development for 250+ engineers and 200+ microservices, with coding agents validating changes in isolated environments per PR. *Image: Bitso logo* ### How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% [Bitso](https://bitso.com/), a leader in digital financial services in Latin America, spent years trying to solve the shared staging problem. With 200+ microservices, ~100 databases, and 250+ engineers all pushing changes into the same environments, something was always broken. Their homegrown preview environments solution required replicating the full stack per PR. This was already too expensive and too unreliable to sustain at scale, and then coding agents quickly made it impossible. Signadot gave them a different model. Instead of duplicating environments, Bitso now forks only the changed services per PR and routes traffic through a single, stable cluster. This became the foundation of an internal initiative the team calls RISE (Robust Isolated Staging Environment), consolidating four fragile environments into one. As AI coding agents have driven a surge in the volume of changes flowing through the pipeline, this architecture has proven essential, giving Bitso the validation infrastructure to keep shipping safely at a pace that would have overwhelmed their previous setup. Open-to-Deploy 62% faster 12.1 days → 4.6 days Deploy Frequency 2.1× 664/week → 1,400/week Change Failure Rate −83% 5.2% → 0.9% across all severities #### The Challenge: Shared Environments Buckling Under Agentic Scale Bitso’s platform is built on roughly 200 Java Spring Boot microservices communicating over gRPC, ~100 Postgres databases, 20+ Redis caches, and asynchronous messaging across Kafka, SQS, and Redis Streams. It is not feasible to run this stack locally. Engineers and their coding agents depend on remote environments to validate their work. **250+** engineers ↓↓↓ 200+ microservices + ~100 Postgres databases + 20+ Redis caches + async messaging KafkaSQSRedis Streams As the team scaled to over 250 engineers and adopted agentic coding tools across the organization, that dependency became a bottleneck. Bitso maintained four separate non-production environments, each with varying degrees of stability, and none of them delivered the confidence engineers needed to ship with speed. The core problem was contention. Hundreds of engineers were pushing changes into shared environments where one faulty deployment could break the pipeline for everyone. The development environment was built around an unprotected branch that any engineer could push to directly. > “Everyone pushing changes onto a shared development branch… it was constantly broken. And if you break something, you break it for everyone using that environment.” Joe Horsnell · Principal Platform Engineer, Bitso Coding agents compounded the problem. Over the past year, the number of PRs flowing through the pipeline per developer increased by 60%, adding load to their testing infrastructure that was already bottlenecked. > “We spent a few years implementing our own preview environments solution, and it was always very expensive, both in time and cost, because we had been trying to replicate full environments per PR. We had a working solution, but in terms of speed and reliability, it was not great.” Marcus Tavares · Staff Software Engineer, Bitso The deployment process compounded the problem further. Engineers and agents would deploy changes to staging, where they mingled with other people’s changes, and then deploy a separate build to production. The code running in production was never identical to what had been validated in staging. Bitso’s vision was clear: collapse down to a single stable non-production environment where engineers and their agents could validate changes in isolation without stepping on each other. They needed infrastructure that could provide isolation at the scale of their architecture, and at the velocity of agentic development, without replicating it entirely. #### The Solution: Signadot and RISE Signadot’s lightweight ephemeral environments gave Bitso the next step forward: per-PR sandboxes that fork only the changed services while routing traffic through a stable shared cluster. Instead of replicating the entire environment, Signadot uses routing keys to direct traffic to only the modified services, with all other dependencies served by the stable cluster. This approach spins up in seconds rather than minutes and costs a fraction of full-environment duplication. Before Replicate the full stack per PR PR #1 × every open PR Minutes to spin up · expensive After Fork only what changed PR #1 PR #2 PR #3 stable environment · shared changed service + Neon branch per PR Seconds to spin up · fraction of the cost Because each PR gets its own isolated environment automatically, the system scales linearly with the increase in changes flowing through the pipeline. There is no shared environment to bottleneck, no queue of developers waiting to deploy to staging. This was critical for Bitso as agent-driven PRs increased the volume of changes far beyond what shared environments could absorb. Critically, this also unlocked artifact promotion. > “When you test, you are testing your changes in isolation, in your sandbox. When we deploy to production, it is precisely the same artifact that was tested in the sandbox, the container image, that we promote.” Joe Horsnell · Principal Platform Engineer, Bitso Bitso formalized this new architecture under an internal initiative called RISE: Robust Isolated Staging Environment. The architecture pairs Signadot for compute-layer isolation with [Neon](https://neon.com/) for data-layer isolation, providing instant Postgres database branches per sandbox for services that require schema changes or write-heavy testing. The combination gives engineers and agents production-like fidelity without resource contention. > “We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” Marcus Tavares · Staff Software Engineer, Bitso Signadot has become a core part of Bitso’s agent workflows. All affected services within a PR receive a sandbox automatically, and some services have either deterministic integration tests or custom agent skills that validate the behavior of those sandboxes. The result is a tighter feedback loop: agents generate code, Signadot provisions the isolated environment, and validation runs against it before the change is merged. Looking ahead, the team is exploring [Signadot’s Plans feature](https://www.signadot.com/blog/signadot-plans/), which provides agent-native validation workflows purpose-built for the inner loop, giving coding agents the ability to validate their own work inside sandboxes before a PR is published. #### Using Signadot for the Inner Loop with Coding Agents As Bitso adopted coding agents across the organization, a pattern emerged. The agents could generate large volumes of code and clear the cheap checks on their own (unit tests, lints, and mocked dependencies), but anything beyond that had to be handed back to engineers. In a system of 200+ interdependent microservices, the behavior that actually matters only shows up when a change runs against real services, real data, and real messaging. Mocks cannot represent that, so the agent’s work stalled at the point where a human had to take over and validate it in a shared environment. Signadot enabled Bitso to move more of that validation surface into the inner loop for their coding agents. Using Signadot’s [local development capabilities](https://www.signadot.com/solutions/local-development/), an engineer or an agent can run the service being changed locally and connect to the staging cluster for every other dependency, without the sidecar overhead or deployment restarts that came with Telepresence, which they were using previously. The agent gets the same routing keys, isolation model, and sandbox infrastructure that drives per-PR validation in CI, which means it can exercise its change against realistic dependencies as it writes it. agent writes code → runs the service locally → validates against real dependencies ↺ iterate until it passes → ✓ PR opens validated ↺ iterate until it passes The effect is a tighter, more realistic feedback loop. Instead of generating code, clearing only the shallow checks, and handing off, agents can validate against production-like behavior before they open a PR. More of the work arrives already validated, and engineers spend less time confirming what the agent could have confirmed itself. #### The Results Since launching RISE and adopting Signadot alongside AI-assisted development and broader developer platform investments, Bitso has seen dramatic improvements across their key engineering velocity and quality metrics: Metric Before After Change Open-to-Deploy time 12.1 days 4.6 days 62% faster Deploy frequency 664/week 1,400/week 2.1× increase Change Failure Rate 5.2% 0.9% 83% reduction These gains reflect the combined impact of Signadot, AI coding agents, and broader platform investments. But the relationship between these factors is reinforcing, not incidental. Coding agents drive velocity. Signadot provides the validation infrastructure that makes shipping at that velocity safe. The change failure rate improvement is especially striking. Even as deployment frequency more than doubled, incidents dropped from 5.2% to 0.9% across all severity levels (P4 through P1). Per-PR isolation means engineers and agents catch problems before code reaches the shared cluster, rather than discovering them in production. #### Conclusion Signadot gave Bitso isolated validation across a complex distributed architecture, at the velocity that coding agents demand. Agents and engineers can test changes against realistic dependencies in the inner loop before a PR exists, every PR gets its own sandbox automatically in CI, and the exact artifact that was validated is what ships to production. The result is a team that ships more than twice as often, with a fraction of the failures, on a foundation built to scale with the next wave of agentic development. > “Signadot has been key in our strategy to provide a faster, better, and more secure pipeline for our projects.” Marcus Tavares · Staff Software Engineer, Bitso To see how lightweight ephemeral environments can work for your team, [sign up for free](https://www.signadot.com/signup/) or [book a demo](https://www.signadot.com/schedule-a-call/). More Customer Stories [ *Image: Laurel logo* How Laurel Brings Production‑Ready Validation to AI‑Native Development Read case study → ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/)[ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Wealthsimple logo* How Signadot Helped Wealthsimple Speed Up Microservice Testing and Unblock Developers Read case study → ](https://www.signadot.com/case-studies/how-signadot-helped-wealthsimple-speed-up-microservice-testing-and-unblock-developers/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Laurel Source: https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/ Summary: How Laurel brings production-ready validation to AI-native development inside its own cloud, giving every pull request a production-like sandbox on its own EKS cluster and cutting change failure rate from 1.1% to 0.2% as agents author 76% of engineering PRs. *Image: Laurel logo* ### How Laurel Brings Production‑Ready Validation to AI‑Native Development [Laurel](https://www.laurel.ai/), a leading AI-native company building AI timekeeping and work intelligence software for professional services, faced a validation problem most engineering organizations will meet soon enough: coding agents were authoring an ever-larger share of its code, and every one of those changes needed production-grade validation before merge, without code or customer data leaving Laurel’s own cloud. Across a team of approximately 60 engineers, agents now author 76% of Laurel’s engineering pull requests, and the team merges about 9 PRs per engineer per week. With a rising volume of code changes moving through the pipeline, Laurel needed a dependable way to validate multi-service changes with production-like fidelity before they merged. Two constraints made the usual options hard. Laurel’s previous approach, using [Vercel](https://vercel.com/) preview environments, could not accurately replicate the full application stack and production infrastructure, which caused regular issues. And because many of Laurel’s clients are law and accounting firms, sending code or customer data to an external vendor’s cloud meant subprocessor reviews and compliance friction the team wanted to avoid. With Signadot, automation owned by Laurel’s infrastructure team stands up [per-PR sandboxes](https://www.signadot.com/docs/guides/set-up-pr-sandboxes) directly on its own [Amazon EKS](https://aws.amazon.com/eks/) cluster, managed with infrastructure as code and GitOps, and never leaving Laurel’s AWS account. Demand for this capability was high and the configuration work was light, so adoption at Laurel has been fast. Agent-Authored PRs 76% up from 55% three months earlier Change Failure Rate −82% 1.1% → 0.2% Throughput 9 PRs merged per engineer, per week, across ~60 engineers #### The Challenge: Validating a Flood of AI-Generated Changes, Without Leaving Their Own Cloud Laurel runs a Kubernetes stack on Amazon EKS: roughly 40 backend services (mostly Node.js, with some Python services for data enrichment) plus a single front-end monorepo of four services, which is its largest Signadot use case. Data lives in [MongoDB Atlas](https://www.mongodb.com/atlas) and Postgres on [AWS Aurora](https://aws.amazon.com/rds/aurora/), messaging runs on [Kafka](https://kafka.apache.org/), and observability is [OpenTelemetry](https://opentelemetry.io/)\-based. The team runs no service mesh. The demand for validation came from three directions at once: engineers wanting to spin up a change and preview it manually, a push to run automated end-to-end tests in CI, and, most importantly, a need to give coding agents a tight, realistic validation loop. As a frontier AI-native engineering team, Laurel was generating more change than a divergent preview setup could safely absorb. > “We were using Vercel for preview environments, and it was just different enough from our production, staging and development environments that it caused regular issues.” Naomi Klein · Lead Infrastructure Engineer, Laurel The deeper issue was where that validation could run. Serving law and accounting firms, Laurel keeps customer data inside its own AWS environment wherever possible, and every external vendor that touches that data is another subprocessor conversation the team would rather avoid. So the selection criteria were strict: run inside their own AWS, work with GitOps, and build directly off their own development Kubernetes cluster. Signadot met all three, which made it the only obvious choice. #### The Solution: Per-PR Sandboxes on Their Own EKS Cluster Instead of duplicating environments, Signadot forks only the changed services into a [sandbox](https://www.signadot.com/docs/concepts/sandbox), a lightweight ephemeral environment, and uses [routing keys](https://www.signadot.com/docs/guides/request-routing) to send the relevant traffic to them, while every other dependency is served by a stable shared environment, all running in Laurel’s own cluster. Sandboxes are provisioned per pull request, and everything runs on their EKS cluster, owned by the infrastructure team and provisioned using the same GitOps, infrastructure-as-code approach as the rest of their platform. Laurel's AWS account dev EKS cluster · GitOps managed PR #241 PR #242 \+ every PR changed services only · routed by routing key via DevMesh stable shared environment · every other service No code or customer data leaves Laurel's AWS account Because Laurel hasn’t adopted a service mesh, Signadot’s [DevMesh](https://www.signadot.com/docs/guides/request-routing/devmesh) filled that gap directly. To coordinate changes that span multiple repositories, the team ties a routing key to each [Linear](https://linear.app/) ticket, so a single key can bring up matching sandboxes across the front-end monorepo and the backend services a change touches. > “We regularly create Signadot environments on every PR for almost every microservice. Our engineers can build and test changes across multiple services directly on top of our development environment, both locally and through our CI tooling.” Naomi Klein · Lead Infrastructure Engineer, Laurel #### Testing and Coding Agents on the Same Path Two of Laurel’s biggest use cases run on this foundation. On the testing side, Laurel rebuilt its E2E suite on Signadot, carrying over some parts of its existing [Playwright](https://playwright.dev/) logic, using Signadot’s [Smart Tests](https://www.signadot.com/product/smart-tests/) and routing keys. > “We have built a new suite for end-to-end testing on top of Signadot, work that would have been significantly more complex beforehand. Multiple engineers have discussed how Signadot helped significantly in uncovering bugs in their changes or in validating their features.” Naomi Klein · Lead Infrastructure Engineer, Laurel On the agentic side, Laurel is seeing an influx of fully AI-generated PRs alongside AI-assisted and human-written ones. Because every PR gets its own production-like sandbox automatically, all three go through the same validation path. The coding agents, [Claude Code](https://www.claude.com/product/claude-code), [Codex](https://openai.com/codex/), and others, wired in through Laurel’s own CLI tooling and AI skills, get the same isolated, realistic environment a human engineer would. That is the point: one place to validate a change, whoever or whatever wrote it. engineerengineer + AIcoding agentsClaude Code · Codexpull requestper-PR sandboxon Laurel's EKSmanual previewPlaywright e2e suiterun as Smart Testsmerge · 0.2% change failure rate Every change, human- or agent-written, gets the same per-PR sandbox and the same validation before merge. engineerengineer + AIcoding agents · Claude Code · Codexpull requestper-PR sandboxon Laurel's EKSmanual previewPlaywright e2e suite · Smart Testsmerge · 0.2% change failure rate Every change, human- or agent-written, gets the same per-PR sandbox and the same validation before merge. #### The Results: More AI-Written Code, Fewer Failures The qualitative wins landed first: easier end-to-end testing, a new test suite built on Signadot, and engineers catching bugs and validating features earlier than they could before. The numbers now back them up. For context on the scale Signadot now supports: over a recent 30-day window, Laurel’s team of roughly 60 engineers merged 2,873 pull requests. Setting aside automation traffic, about 20% of the total, that is roughly 2,300 engineering PRs: 538 per week, or about 9 merged PRs per engineer, per week. Metric Before After Change Agent-authored engineering PRs 55% 76% +21 pts Change Failure Rate 1.1% 0.2% 82% reduction The change failure rate is what makes the throughput credible. Over the same three months in which the agent-authored share of engineering PRs climbed from 55% to 76%, change failure rate did not just hold under the added volume. It fell from 1.1% to 0.2%. That was the whole point of the investment: push a higher volume of increasingly AI-generated changes without a matching rise in incidents. Laurel is shipping more AI-written code and breaking production less. #### Conclusion For an AI-native team carrying the compliance obligations of serving law and accounting firms, Signadot gave Laurel what the other options couldn’t: production-grade validation it could own and run entirely inside its own AWS and Kubernetes, scaling per PR, covering nearly every microservice in its most critical repos, and providing a single validation surface for both engineers and coding agents. > “Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test.” Naomi Klein · Lead Infrastructure Engineer, Laurel To see how Signadot can help your team ship safer agent-written code at scale, [sign up for free](https://www.signadot.com/signup/) or [book a demo](https://www.signadot.com/schedule-a-call/). More Customer Stories [ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Bitso logo* How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Read case study → ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/)[ *Image: Wealthsimple logo* How Signadot Helped Wealthsimple Speed Up Microservice Testing and Unblock Developers Read case study → ](https://www.signadot.com/case-studies/how-signadot-helped-wealthsimple-speed-up-microservice-testing-and-unblock-developers/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## ShareChat Source: https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/ Summary: How ShareChat eliminated shared staging bottlenecks and enabled parallel development with Signadot sandboxes. *Image: ShareChat logo* ### ShareChat Chooses Signadot, Giving Devs High Quality Testing Feedback Enabling Faster Time-to-Market *Image: ShareChat Chooses Signadot, Giving Devs High Quality Testing Feedback Enabling Faster Time-to-Market* #### The Challenge ShareChat is an Indian social media startup that caters to over 1 billion wireless network users. It offers a content consumption and sharing platform in 15 vernacular Indian languages. ShareChat has an engineering team of more than 300 members and manages over 100 microservices running on Kubernetes. They needed a way to test every feature independently before merging to production. They wanted a separate environment similar to staging to integration test their microservices and ensure that API contracts weren’t broken. Knowing the cost and development effort required to build a testing solution in-house, ShareChat was looking for a turnkey solution that could easily integrate into their existing architecture. * * * #### The Solution Signadot’s approach to ephemeral environments ultimately drove ShareChat to purchase Signadot as it allowed them to automate integration testing in their staging environment for 100+ microservices. They also didn’t have to worry about runaway infrastructure costs or operational burden. ShareChat integrated Signadot into their CI tool to automate integration testing for every PR. Developers were also able to write integration tests using their framework of choice running on Sandbox Environments. > “Signadot helps ShareChat to set up an extremely efficient rollout of an end-to-end integration test environment and allows developers to test for backward compatibility without having to worry about maintaining various versions of their services.” Harshal Vora · Sr. Engineering Manager, ShareChat * * * #### The Results **Independent testing for every PR.** ShareChat developers can now spin up a sandbox for every pull request, self-identify errors, and fix them before deploying to production — leading to more frequent deployments with fewer rollbacks and fewer production incidents. By adding Signadot to their deployment and review pipeline, ShareChat is able to spin up a Sandbox for every PR for developers to test their features independently. Developers are now able to self identify errors and fix them before deploying to production. Automated integration testing with Signadot has led to more frequent deployments while minimizing rollbacks and decreasing issues in production. To read or download the entire ShareChat case study, [click here](https://signadot-public.s3.us-west-2.amazonaws.com/sharechat-case-study.pdf). More Customer Stories [ *Image: Laurel logo* How Laurel Brings Production‑Ready Validation to AI‑Native Development Read case study → ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/)[ *Image: Miro logo* How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Read case study → ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/)[ *Image: Bitso logo* How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Read case study → ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## All Customers Source: https://www.signadot.com/customers/ Summary: Customer success stories and video testimonials from engineering teams using Signadot. ### Case Studies See how engineering teams at leading companies use Signadot to accelerate development, reduce costs, and ship with confidence. [ *Image: How Brex Uses Signadot to Scale Developer Testing Across 100s of Engineers and Coding Agents* ###### How Brex Uses Signadot to Scale Developer Testing Across 100s of Engineers and Coding Agents Signadot replaced Brex's namespace-based preview environments across 800+ microservices, cutting infrastructure costs by 99%, taking service previews from 30 to 60 minutes down to... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/brex-uses-signadot-to-scale-developer-testing-across-100s-of-engineers/) [ *Image: How Laurel Brings Production‑Ready Validation to AI‑Native Development* ###### How Laurel Brings Production‑Ready Validation to AI‑Native Development Laurel, an AI-native company where agents author 76% of engineering PRs, uses Signadot to give every pull request a production-like sandbox on its own EKS cluster, cutting change... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/) [ *Image: How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot* ###### How Miro's AI Team Builds and Tests Agentic Features at Scale with Signadot Miro's AI team adopted Signadot as the runtime validation layer for agentic development, testing agent tools and agent-generated code against real services. Adoption spread across... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-miro-builds-and-tests-agentic-features-at-scale/) [ *Image: How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83%* ###### How Bitso Scaled Delivery with Coding Agents While Cutting Change Failure Rate by 83% Bitso replaced broken shared staging with Signadot's lightweight ephemeral environments, giving 250+ engineers and their coding agents isolated per-PR sandboxes across 200+... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) [ *Image: How Signadot Helped Wealthsimple Speed Up Microservice Testing and Unblock Developers* ###### How Signadot Helped Wealthsimple Speed Up Microservice Testing and Unblock Developers Wealthsimple cut weekly staging deployments nearly in half by adopting Signadot, eliminating staging conflicts and giving developers fast, isolated sandboxes that integrate with... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-signadot-helped-wealthsimple-speed-up-microservice-testing-and-unblock-developers/) [ *Image: How Arkestro Supercharged Developer Efficiency and Slashed Costs with Signadot* ###### How Arkestro Supercharged Developer Efficiency and Slashed Costs with Signadot Arkestro's 40-person engineering team saves over $1M in annual developer bandwidth by running pre-merge tests in Signadot sandboxes — reducing regressions and freeing engineers to... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-arkestro-supercharged-developer-efficiency-and-slashed-costs-with-signadot/) [ *Image: Shifting Left with Signadot: How Earnest Empowered Developers for Early Testing* ###### Shifting Left with Signadot: How Earnest Empowered Developers for Early Testing Earnest automated end-to-end testing with Signadot sandboxes, parallelizing test suites to cut cycle times from 60 minutes to 10 — and ensuring developers catch issues before code... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-earnest-empowers-developers-for-early-testing/) [ *Image: Yellow.ai and Signadot: Pioneering Parallel Feature Development for Faster Releases* ###### Yellow.ai and Signadot: Pioneering Parallel Feature Development for Faster Releases Yellow.ai achieved a 2–3x improvement in developer productivity by replacing per-developer virtual clusters with Signadot's request isolation, letting 100+ developers test... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-yellow-ai-enabled-parallel-feature-development-using-signadot/) [ *Image: How Developers and Coding Agents at DoorDash Get 10x Faster Feedback on Code Changes* ###### How Developers and Coding Agents at DoorDash Get 10x Faster Feedback on Code Changes DoorDash eliminated their staging environment and gave developers the ability to test directly against production from their laptops — cutting feedback time from 30 minutes to 60... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/how-developers-at-doordash-get-10x-faster-feedback/) [ *Image: Levo Saves 90% of Time on Integration Tests, Improves Developer Efficiency with Signadot* ###### Levo Saves 90% of Time on Integration Tests, Improves Developer Efficiency with Signadot Levo achieved 90% time savings on integration testing by running automated end-to-end tests in Signadot sandboxes before every merge — eliminating post-merge bugs and rollbacks. Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/levo-saves-time-on-integration-tests-improves-developer-efficiency-with-signadot/) [ *Image: ShareChat Chooses Signadot, Giving Devs High Quality Testing Feedback Enabling Faster Time-to-Market* ###### ShareChat Chooses Signadot, Giving Devs High Quality Testing Feedback Enabling Faster Time-to-Market ShareChat integrated Signadot into their CI pipeline to give 300+ developers independent sandboxes for 100+ microservices — dramatically reducing production issues and enabling... Read Case Study *Image: arrow icon* ](https://www.signadot.com/case-studies/sharechat-chooses-signadot-giving-devs-high-quality-testing-feedback/) #### And many more Signadot is trusted by engineering teams at companies of all sizes *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Take Signadot for a whirl Learn more about how to scale pre-merge testing with microservices [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) --- ## Integrations Source: https://www.signadot.com/integrations/ Summary: Signadot integrations for service meshes, CI/CD, testing frameworks, coding agents, and observability tools. ### All your critical tools and infrastructure in one place Work with the tools your team already uses — GitHub, GitLab, Jenkins, and more. Filter Apps *Image: Apollo GraphQL logo* Apollo GraphQL Apollo GraphQL *Image: arrow icon* Enables safe testing of federated GraphQL schema changes in isolated, per-Pull Request environments. By combining Apollo's Variants with Signadot's Sandboxes, developers can validate subgraphs and router changes without affecting the production supergraph. [ Documentation *Image: arrow icon*](https://www.signadot.com/blog/using-sandboxes-with-apollo-graphql/) API Frameworks *Image: Backstage logo* Backstage Backstage *Image: arrow icon* A plugin to bring your ephemeral test environments directly into Backstage. Get a unified view of both production and sandboxes, enabling your developers to manage and view environments in one place. [ Documentation *Image: arrow icon*](https://github.com/signadot/backstage-plugin) Internal Developer Portals *Image: Bitbucket logo* Bitbucket Bitbucket *Image: arrow icon* Use Bitbucket pipelines to automate the creation and testing of sandboxes for your commits and pull requests, securing your API key with environment variables. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/integrate-ci/bitbucket) CI/CD Tools *Image: Claude Code logo* Claude Code Claude Code *Image: arrow icon* Use Signadot's MCP server with Claude Code to manage sandboxes, run tests, and interact with your ephemeral environments directly from your AI coding assistant. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp/claude-code) AI Coding *Image: Codex logo* Codex Codex *Image: arrow icon* Integrate Signadot's MCP server with OpenAI Codex to automate sandbox creation, run tests, and manage ephemeral environments from your AI development workflow. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp/other-clients) AI Coding *Image: Cursor logo* Cursor Cursor *Image: arrow icon* Connect Signadot's MCP server to Cursor and let your AI coding assistant create sandboxes, check test results, and manage ephemeral environments without leaving your editor. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp/cursor) AI Coding *Image: Cypress logo* Cypress Cypress *Image: arrow icon* Integrate with your CI/CD pipelines to run Cypress tests in ephemeral environments, using a routing key to ensure each test runs against its own isolated sandbox. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/testing-frameworks/cypress-integration) Test Frameworks *Image: GitHub Actions logo* GitHub Actions GitHub Actions *Image: arrow icon* Integrate with your CI workflow to create and test sandboxes directly from pull requests, with automatic status updates and cleanup. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/integrate-ci/github) CI/CD Tools *Image: GitLab logo* GitLab GitLab *Image: arrow icon* Easily set up CI/CD pipelines to manage sandboxes for your merge requests, using the Signadot CLI to apply, test, and delete environments. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/integrate-ci/gitlab) CI/CD Tools *Image: Google Pub/Sub logo* Google Pub/Sub Google Pub/Sub *Image: arrow icon* Perform isolated end-to-end testing for your asynchronous Google Pub/Sub flows. Sandbox-specific routing keys are used to ensure that messages are only processed by the correct environment. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/set-up-message-queue-isolation) Message Queues *Image: Istio logo* Istio Istio *Image: arrow icon* Achieve request-level isolation for ephemeral environments in Istio ambient mode, providing a cleaner and more efficient way to test your applications without the "sidecar tax." [ Documentation *Image: arrow icon*](https://www.signadot.com/blog/signadot-operator-cli-hit-1-0-now-with-istio-ambient-support-and-enhanced-local-dev/) Infrastructure *Image: Jenkins logo* Jenkins Jenkins *Image: arrow icon* Configure your Jenkins free-style projects to manage sandboxes using a simple build script, securely accessing the API key via Jenkins credentials. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/integrate-ci/jenkins) CI/CD Tools *Image: Kafka logo* Kafka Kafka *Image: arrow icon* Enable isolated end-to-end testing for your Kafka-based microservices. Use routing keys and selective message consumption to test changes in sandboxes without interfering with other environments. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/set-up-message-queue-isolation) Message Queues *Image: Kubernetes logo* Kubernetes Kubernetes *Image: arrow icon* Seamlessly integrate with your Kubernetes clusters to establish a secure connection, enabling authenticated previews and isolated ephemeral environments. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/admin/security#kubernetes) Infrastructure *Image: Linkerd logo* Linkerd Linkerd *Image: arrow icon* Leverage DevMesh to set up sandbox routing for your Linkerd-powered applications, creating high-fidelity testing environments with ease. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/installation/signadot-operator#linkerd) Infrastructure *Image: MySQL logo* MySQL MySQL *Image: arrow icon* Spin up temporary MySQL databases linked to the lifecycle of Sandboxes using Resource Plugins. [ Documentation *Image: arrow icon*](https://github.com/signadot/plugins) Databases *Image: Neon logo* Neon Neon *Image: arrow icon* Spin up temporary Neon databases linked to the lifecycle of Sandboxes using Resource Plugins. [ Documentation *Image: arrow icon*](https://github.com/signadot/plugins) Databases *Image: Open Telemetry logo* Open Telemetry Open Telemetry *Image: arrow icon* Integrate with the OpenTelemetry standard for automatic context propagation. Use the sd-routing-key within baggage and tracestate headers to ensure your test traffic is routed correctly. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/set-up-context-propagation) Distributed Tracing *Image: Playwright logo* Playwright Playwright *Image: arrow icon* Run your end-to-end tests in isolated sandboxes. Configure Playwright to use a routing key, enabling you to test changes on a per-pull request basis. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/testing-frameworks/playwright-integration) Test Frameworks *Image: Postgres logo* Postgres Postgres *Image: arrow icon* Spin up temporary PostgreSQL databases linked to the lifecycle of Sandboxes using Resource Plugins. [ Documentation *Image: arrow icon*](https://github.com/signadot/plugins/tree/main/postgres-vault) Databases *Image: Postman logo* Postman Postman *Image: arrow icon* Use Postman's CLI, Newman, to run API tests against sandboxes. By passing a routing key, you can automatically route test traffic to the correct isolated environment. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/guides/testing-frameworks/postman-integration) Test Frameworks *Image: RabbitMQ logo* RabbitMQ RabbitMQ *Image: arrow icon* Isolate RabbitMQ consumers for safe, parallel testing. By creating temporary, sandbox-specific queues and exchanges, you can test changes in an isolated environment without the overhead of duplicating your infrastructure. [ Documentation *Image: arrow icon*](https://www.signadot.com/blog/testing-microservices-with-rabbitmq-using-signadot-sandboxes/) Message Queues *Image: SQS logo* SQS SQS *Image: arrow icon* Test your SQS-based microservices by using a dedicated SQS queue for each sandbox. This approach, which often leverages SNS for message fan-out, ensures proper isolation and simplifies testing. [ Documentation *Image: arrow icon*](https://github.com/signadot/plugins/tree/main/amazon-sqs) Message Queues *Image: Temporal logo* Temporal Temporal *Image: arrow icon* Test Temporal services and workflows in isolation. This integration enables you to safely validate new worker code in a sandbox environment without needing to redeploy full environments. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/tutorials/testing-temporal-workers) Workflow Systems *Image: Windsurf logo* Windsurf Windsurf *Image: arrow icon* Connect Signadot's MCP server to Windsurf and manage sandboxes, run tests, and interact with ephemeral environments from within your AI coding assistant. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp/other-clients) AI Coding *Image: WunderGraph logo* WunderGraph WunderGraph *Image: arrow icon* Allows teams to safely test GraphQL schema changes in isolated environments. By combining WunderGraph's feature flags with Signadot's sandboxes, developers can validate schema updates and new subgraphs without disrupting the main API. [ Documentation *Image: arrow icon*](https://www.signadot.com/blog/using-sandboxes-with-wundergraph/) API Frameworks *Image: Zed logo* Zed Zed *Image: arrow icon* Use Signadot's MCP server with Zed to manage sandboxes, run tests, and interact with your ephemeral environments directly from your AI-powered editor. [ Documentation *Image: arrow icon*](https://www.signadot.com/docs/integrations/mcp/other-clients) AI Coding No integrations found. #### Begin your journey today [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) --- # Comparisons ## The Ultimate Guide to Telepresence Alternatives in 2026 Source: https://www.signadot.com/blog/the-ultimate-guide-to-telepresence-alternatives-in-2025/ Summary: The local-proxy alternatives (mirrord, Gefyra) compared with sandbox platforms, what changed after Telepresence's commercial shift, and which option fits by team size and workflow. ### The Ultimate Guide to Telepresence Alternatives in 2026 For teams evaluating Telepresence alternatives, the biggest challenge is balancing fast inner-loop debugging with reliable team-wide testing. This guide explores modern tools and sandbox platforms that streamline Kubernetes development, helping teams accelerate feedback cycles, cut costs, and ship higher-quality software with confidence. Reading time 10 min Author Arjun Iyer Published August 27, 2025 Updated August 31, 2026 Topics [Tutorials/Guides](https://www.signadot.com/blog/category/tutorials-guides/) The world of Kubernetes development is at an inflection point. For years, engineering teams have grappled with the challenges of building and testing complex microservices architectures. Tools like Telepresence emerged as essential aids, helping developers bridge the gap between their local machines and remote clusters. However, recent market shifts have prompted many teams to re-evaluate their workflows: Ambassador Labs folded its commercial Telepresence offering into its Blackbird product in 2025 and was later acquired by Gravitee, leaving the open source project to continue under the CNCF. If you’re searching for a “Telepresence alternative” in 2026, you’re likely looking for more than just a replacement tool. You’re seeking a better, more scalable way to develop, test, and ship cloud-native applications. This guide will navigate the evolving landscape of Kubernetes development tools, providing a clear framework to help you choose the right solution for your team’s needs, whether you’re looking for a direct alternative or a strategic upgrade to your entire development lifecycle. (For a broader side-by-side of the whole category, including Okteto and other environment platforms, see our [comparison of Kubernetes development tools in 2026](https://www.signadot.com/blog/telepresence-mirrord-okteto-alternatives/).) ##### **The Core Challenge: Why We Seek Tools Like Telepresence** Before diving into alternatives, it’s crucial to understand the fundamental problem they aim to solve: the painfully slow feedback loop in microservices development. The traditional workflow of writing code, building a container, pushing it to a registry, and deploying to a shared staging environment is fraught with friction: - **Slow Iteration Cycles:** The “inner loop” of coding and debugging becomes agonizingly slow when every change requires a full deployment cycle. - **The “Broken Staging” Nightmare:** Shared staging environments are notoriously unstable, often breaking due to conflicting changes from different developers, leading to lost productivity and endless debugging sessions. - **Lack of Fidelity:** Local development environments using tools like Docker Compose can’t fully replicate the complexity of a cloud environment, [leading to the dreaded “it works on my machine” problem](https://www.reddit.com/r/kubernetes/comments/tewhqf/how_are_your_developers_testing_their_code_locally/). Tools like Telepresence were created to address the first point directly, by connecting a local process to a remote cluster and dramatically speeding up the inner loop. But as teams scale, the other, more systemic problems of collaboration and testing remain. ##### **A Framework for Evaluation: Two Fundamental Approaches** The market for Kubernetes development tools has matured and can be broadly categorized into two distinct approaches, each targeting different phases of the development lifecycle. 1. **Local Development Proxies (Inner Loop Tools):** These tools are laser-focused on individual developer productivity. They create a network bridge between a developer’s local machine and a remote Kubernetes cluster, allowing them to run and debug a single service locally as if it were part of the remote environment. This category includes Telepresence and its direct competitors. 2. **Ephemeral Environment Platforms (Outer Loop Platforms):** This approach addresses the broader challenges of team-wide testing and collaboration. Instead of just connecting a local machine, these platforms create lightweight, isolated, on-demand testing environments _within_ the Kubernetes cluster itself. They are designed to integrate with the “outer loop”: the workflow that begins when a developer opens a pull request and needs to run comprehensive, automated tests. Understanding this distinction is key to moving beyond a simple feature comparison and making a strategic choice for your team. ##### **Deep Dive: The Local Development Proxies** If your primary goal is to find a direct, like-for-like replacement for Telepresence’s core functionality, this category is for you. ###### **Telepresence (The Incumbent)** As a CNCF Sandbox project, [Telepresence](https://www.signadot.com/comparison/telepresence/) is the most well-known tool in this space. - **How it Works:** Telepresence establishes a VPN-like tunnel between your workstation and the cluster. It deploys a central Traffic Manager in the cluster, which injects a Traffic Agent (a sidecar proxy) into the pod you want to intercept. This agent then reroutes traffic to and from your local machine. - **Common Community Feedback:** While powerful, users often report challenges. A recurring theme in community forums is the difficulty in getting it set up and working correctly. It can be “finicky” with different network configurations, especially corporate VPNs. Furthermore, the architectural shift to v2, which requires persistent daemons, has been a point of contention for some users who preferred the simpler model of v1. - **Where it Stands in 2026:** The open source project continues under the CNCF. On the commercial side, Ambassador Labs folded the paid edition into its Blackbird platform and was subsequently acquired by Gravitee. Teams that relied on the paid tier are the ones most actively evaluating the alternatives below. ###### **mirrord (The Modern Challenger)** [mirrord](https://www.signadot.com/comparison/mirrord/) is a newer tool that targets the same use case as Telepresence but with a fundamentally different architecture designed to address its common pain points. - **How it Works:** Instead of creating a system-wide VPN, mirrord operates at the _process level_. It injects itself into the local process you’re running (e.g., from your IDE) and intercepts low-level system calls for network and file I/O, proxying them to a temporary agent in the cluster. This clever approach avoids the need for root privileges or system-wide network changes. - **Common Community Feedback:** Users who have switched from Telepresence often praise mirrord for its stability and less intrusive nature. Its default mode of mirroring (duplicating) traffic rather than intercepting it is also seen as a safer way to debug against a shared environment without disrupting it. ###### **Gefyra (The Focused Open Source Player)** Born out of frustration with Telepresence’s reliability, Gefyra offers a simpler, more focused open-source alternative. - **How it Works:** Gefyra’s approach is to connect a locally running _Docker container_ to the remote cluster’s network. It aims for a more robust and simplified architecture by not directly modifying the running workload in the cluster. - **Limitations:** While its simplicity is an advantage, it’s also more limited. The strict requirement for local development to happen inside a Docker container makes it less flexible for developers who prefer to run processes natively on their host machine. Test your next change against real dependencies Signadot spins up isolated sandboxes on the Kubernetes cluster you already run, so every change is validated against real services before it merges. The free tier is open to every developer. [Start free](https://www.signadot.com/signup/) [Book a demo](https://www.signadot.com/schedule-a-call/) ##### **The Platform Upgrade: Graduating to Signadot** While the tools above are excellent for optimizing an individual’s inner loop, they don’t solve the “outer loop” problems of team collaboration and automated testing that plague scaling engineering organizations. This is where a platform approach becomes necessary. Signadot is a comprehensive microservices testing platform designed not just as an alternative, but as a strategic upgrade for teams that have outgrown the limitations of local proxying tools. - **How it Works:** The core of Signadot is a concept called “Sandboxes,” which are lightweight, isolated testing environments created _within_ your Kubernetes cluster. Instead of duplicating your entire infrastructure (which is slow and expensive), Signadot uses an intelligent request-level isolation model using a Service mesh like Istio (or devmesh sidecars). A Sandbox **unifies** workloads running in the remote cluster with services running on a developer’s local machine. It spins up only the service you’re changing and smartly routes test-specific requests to it, while all other requests for dependencies go to the stable baseline services in the shared cluster. This approach is incredibly resource-efficient, with customers reporting infrastructure cost savings of up to 90%. ###### **A Comprehensive Platform: From Inner Loop to Outer Loop** Signadot is uniquely positioned because it addresses the full development lifecycle, providing a unified workflow for developers, QA, and platform engineers. - **Unified Inner Loop Development:** Signadot fully supports and enhances the [local development](https://www.signadot.com/docs/guides/use-cases/set-up-local-testing) use case. A developer can connect their local IDE and debugger to a remote Sandbox, getting the same rapid feedback loop they’re used to. The key difference is that this local service becomes a seamless part of a high-fidelity, isolated environment in the cloud, interacting with real dependencies. - **Feature Testing across multiple PRs:** Modern features often span multiple microservices and multiple pull requests. Signadot addresses this with **RouteGroups**, a powerful feature for team collaboration. RouteGroups allow developers to combine multiple, independent Sandboxes into a single, unified testing environment. This enables true end-to-end testing of a complete feature before any code is merged, allowing multiple developers to collaborate and validate their integrated changes seamlessly. - **Built for Real-World Architectures:** Signadot is designed to handle the complexity of modern applications, which goes far beyond simple request/response services.**‍** - **Data Isolation for Stateful Services:** A major challenge for testing is managing state. Signadot provides [tunable data isolation](https://www.signadot.com/docs/guides/set-up-data-isolation) through resource plugins for databases like PostgreSQL and MySQL. These plugins can automatically create temporary, isolated schemas or databases for a Sandbox, ensuring that tests don’t corrupt shared data and can run reliably in parallel.**‍** - **Native Support for Asynchronous Workflows:** Many systems rely on message queues and event-driven patterns. This is an area where most local proxy tools fall short. Signadot offers native support for systems like Kafka, SQS, RabbitMQ, and others. It provides [message queue isolation](https://www.signadot.com/docs/guides/set-up-message-queue-isolation) by creating sandbox-specific topics and queues, ensuring that asynchronous test flows are properly isolated without disrupting the baseline environment.**‍** - **Preview Environments for Every PR:** Signadot integrates with your CI/CD pipeline to automatically spin up a Sandbox for every pull request. These preview environments are stable, isolated, and can be easily shared with teammates, product managers, and designers for review, [finally solving the broken staging environment problem](https://www.signadot.com/blog/the-staging-bottleneck-why-your-engineering-team-is-slow-and-how-to-fix-it/).**‍** - **Reliable Automated Testing:** Because every PR gets its own isolated Sandbox, you can run your entire suite of [integration and end-to-end tests](https://www.signadot.com/docs/guides/use-cases/run-automated-tests-ci) (using any framework like Cypress, Playwright, or Postman) in parallel without tests interfering with each other. This is a capability that is explicitly out of scope for tools like Telepresence or mirrord.**‍** - **AI-Powered SmartTests:** Signadot offers a unique [AI-powered capability for API contract testing](https://www.signadot.com/docs/guides/smart-tests/contract-tests). It automatically detects meaningful differences between your baseline and under-test API responses, providing zero-maintenance tests that catch regressions before they hit production. ##### **Strategic Comparison: When to Choose Which Approach?** The right choice depends entirely on the problems your team is facing today and where you plan to be tomorrow. **Choose a Local Development Proxy (like Telepresence or mirrord) when:** - You are an individual developer or a small team. - Your primary pain point is the slow “code-build-push-deploy” cycle. - You need a tactical tool to quickly debug a single service against remote dependencies. - You are not yet facing major bottlenecks with shared staging environments or automated testing. **Choose a Testing Platform (like Signadot) when:** - You want local development and team-wide testing on one platform. Signadot covers the same inner-loop workflow as the proxy tools, connecting a locally running service to the shared cluster’s real dependencies inside an isolated sandbox. - Your engineering team is growing, and the shared staging environment has become a constant source of friction and delays. - You need to run reliable, automated integration and end-to-end tests on every pull request to improve release quality. - You need to test complex features that span multiple services and PRs, requiring collaboration between developers. - Your architecture includes stateful services or asynchronous messaging systems that require sophisticated test isolation. - Reducing infrastructure costs while scaling your testing efforts is a priority. ##### **Conclusion: The Future of Kubernetes Development is a Platform** The search for a Telepresence alternative in 2026 is an opportunity to think bigger. While direct replacements exist to solve the immediate needs of local development, the broader trend is a move away from siloed, individual tools toward integrated platforms that address the entire software development lifecycle. By adopting a platform that unifies local development, PR previews, and automated testing for even the most complex architectures, teams can finally escape the systemic bottlenecks of microservices development. This shift empowers organizations to not only increase developer velocity but also to ship higher-quality software with confidence, turning a tactical tool replacement into a long-term strategic advantage. #### Frequently asked questions What is the best alternative to Telepresence? It depends on what you need beyond the core workflow of connecting local code to a cluster. mirrord and Gefyra are direct swaps for the local-proxy model: mirrord intercepts a local process's system calls, while Gefyra connects locally running Docker containers to the cluster network. Signadot covers that same local development workflow through sandboxes, running the service you are changing on your machine against the shared cluster's real dependencies, and extends it with PR preview environments, automated integration testing, and multi-service testing across teams. What are the best alternatives to mirrord? Telepresence and Gefyra are the closest like-for-like swaps: all three connect a locally running process to a remote Kubernetes cluster, differing mainly in mechanism (VPN-style tunnel, container networking, or system-call interception). Signadot is the alternative when you want that local workflow plus a broader testing platform: each developer works in an isolated sandbox on a shared cluster, and the same setup powers PR preview environments and automated integration testing. Is Telepresence still maintained? The open source project continues under the CNCF, where Telepresence is a sandbox project. On the commercial side, Ambassador Labs folded its paid Telepresence offering into its Blackbird platform in 2025 and was later acquired by Gravitee, which has prompted many teams to re-evaluate their tooling. What is the difference between Telepresence and mirrord? Telepresence creates a VPN-like tunnel between your machine and the cluster, with a Traffic Manager in the cluster and an agent injected into intercepted pods. mirrord instead injects itself into the local process and proxies its network and file I/O system calls to a temporary agent in the cluster, so it needs no root privileges or system-wide network changes, and it mirrors traffic by default instead of intercepting it. Does Signadot support local development like Telepresence does? Yes. Signadot's local workflow connects your workstation to a shared Kubernetes cluster: you run just the service you are changing on your machine, requests in the cluster that carry your sandbox's routing key are routed to your local process, and your local service reaches the cluster's real services, databases, and queues by their normal Kubernetes DNS names. Because each developer works inside an isolated sandbox, many developers share the same cluster without stepping on each other, and the same platform then covers PR previews and automated testing once the change moves beyond your machine. #### Related Posts *Image: Testing Kafka-Based Microservices in Kubernetes: The Complete Guide* tutorials-guides integration-e2e-testing ##### Testing Kafka-Based Microservices in Kubernetes: The Complete Guide November 6, 2024 *Image: Signadot vs. Telepresence: A Platform Upgrade for Enterprise Teams* tutorials-guides ##### Signadot vs. Telepresence: A Platform Upgrade for Enterprise Teams August 27, 2025 *Image: How to Run a Local Kubernetes Cluster with Minikube* tutorials-guides ##### How to Run a Local Kubernetes Cluster with Minikube April 23, 2023 Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## vs Mirrord Source: https://www.signadot.com/comparison/mirrord/ Summary: Signadot compared to Mirrord for Kubernetes development and testing. Signadot vs mirrord ### **The complete agentic development platform.** Signadot goes beyond local dev tools and preview environments. Give developers and coding agents the infrastructure and verification tools they need to go from prompt to production-ready code at scale. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) One platform · every layer Agent-native validation PlansMCP serverAgent skills Testing runtime Smart TestsJobs Isolated environments SandboxesRequest routingResource plugins Your Kubernetes cluster Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Signadot does more. mirrord gives you the ability to test against your cluster. Signadot gives enterprise teams everything they need to validate code at agent scale: isolated environments, a built-in testing runtime, and platform-governed verification workflows that prove every change before it merges. How they compare Signadot Kubernetes-Native Validation Platform *Image: Check mark* Comprehensive Environments, a testing runtime, and platform-governed agentic verification workflows in one product. Sandboxes, Smart Tests, Jobs, and Plans. *Image: Check mark* Unified Architecture Sandboxes, Smart Tests, Jobs, and Plans work the same in local dev, in PRs, and in agent loops. Same primitives everywhere. *Image: Check mark* Extensible Resource plugins extend isolation to any database, queue, or async system, including resources outside Kubernetes. *Image: Check mark* Built for Devs and Agents Chrome extension, SDKs, CLI, and MCP server. Platform teams integrate easily. Devs and agents use it natively. *Image: Check mark* Centralized, Governed Access A central control plane holds cluster access. Developers and agents connect through it with SSO and RBAC, so credentials stay centrally governed. mirrord Local Development Tool *Image: Check mark* Environments Only No built-in test runtime. CI support (Enterprise) reuses your suite in the runner. Nothing like Smart Tests or managed Jobs. *Image: Check mark* Local Debugging Origins Started as local debugging, since extended into agent and CI workflows, not architected as a unified platform from the ground up. *Image: Check mark* No Plugin Model Database and queue support is limited to a fixed set. No framework to extend isolation. *Image: Check mark* Retrofitted for Agents Agent skills connect coding agents to the cluster, but with no MCP server or test runtime there's no closed validation loop. *Image: Check mark* Credentials on Every Laptop Each developer authenticates directly to the cluster, so cluster credentials live on every machine, a blocker for many security-gated teams. Three Pillars #### Built for scale. Unified. Comprehensive. agent-01: feature-auth validated agent-02: bugfix-cart running agent-03: refactor-db validated agent-04: pr-1234 testing agent-05: fix-pagination validated agent-06: spike-redis running agent-07: hotfix-auth testing Built for Agents ##### One sandbox per agent. Thousands in parallel. Each agent gets its own lightweight environment, cheap and fast. They run more validations autonomously before human review. Local Dev inner loop PR Validation outer loop Same Sandbox one platform Unified Architecture ##### Inner loop and outer loop on one platform. The same sandbox abstraction covers [local development](https://www.signadot.com/guide-to-local-development-kubernetes/) and PR validation. One platform. One mental model. Testing & Validation Runtime Smart Tests Jobs Plans Environments \+ ∞ Comprehensive Coverage ##### Environments, the test runtime, and Plans, all built in. Signadot ships the runtime too: Smart Tests for new validations, Jobs for your existing suites, and Plans for platform-governed agentic verification. All run inside your cluster. [Learn more](https://www.signadot.com/docs) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot mirrord CI Integration *Image: Check mark* Provisions a Kubernetes sandbox in your cluster on every PR. Tests run inside the cluster *Image: Partial support* Runs your service-under-test as a process inside the CI runner. Both CI support and native K8s preview pods require Enterprise Lifecycle Coverage *Image: Check mark* Local dev, PR previews, tests, and agents *Image: Partial support* Local dev is free. CI and PR previews are Enterprise Cross-Service Features *Image: Check mark* Validate features that span multiple services. Fork them together or compose sandboxes via RouteGroups. *Image: Partial support* Multiple concurrent sessions via local config (mirrord up); no shared sandbox primitive to compose or reuse Test Automation *Image: Check mark* Smart Tests and Jobs run inside your cluster *Image: Partial support* No test runtime. Enterprise CI runs your existing suite in the runner Database Isolation *Image: Check mark* Plugin framework for any database. Pairs cleanly with branchable DBs like Neon and Xata *Image: Partial support* No extensible framework. Isolation must be built per database, so coverage is limited to whatever mirrord has shipped Message Queue Isolation *Image: Check mark* Header-based routing framework that works with any multi-consumer message queue *Image: Partial support* No extensible framework. Each queue or streaming system must be implemented individually, and apps must read queue names from env vars Async Workflow Systems *Image: Check mark* Routes context through Temporal and similar *Image: Not supported* Not addressed Request Routing *Image: Check mark* Standards-based: service mesh or Envoy sidecars, with OpenTelemetry headers (W3C, B3) for context propagation *Image: Partial support* Custom: libc syscall hooks intercept traffic in the local process Traffic Capture & Override *Image: Check mark* Record HTTP/gRPC with surgical per-API override *Image: Partial support* Mirrors or steals live traffic into the local process. No recording or per-API override Coding Agent Support *Image: Check mark* MCP server, agent skills, and governed Plans for autonomous provisioning, testing, and validation *Image: Partial support* Agent skills and prompt generation, but no MCP server or managed validation workflow Data Egress & Auditability *Image: Check mark* Changed workloads run in-cluster in a Sandbox, so sensitive data stays in the cluster, with auditable activity through the control plane *Image: Not supported* Live traffic, env vars and file contents are relayed to the developer's local machine by design. The file and env controls are documented as convenience, not security, and there is no egress audit by default Cluster access *Image: Check mark* Developers and agents connect through a central control plane, with no direct cluster credentials on their machines *Image: Partial support* Each developer's machine authenticates directly to the Kubernetes cluster Identity & access governance *Image: Check mark* SSO and RBAC, with SOC 2 Type II *Image: Partial support* Kubernetes RBAC tied to each developer's own cluster credentials (paid Operator) Fit for security-gated orgs *Image: Check mark* Built for teams where developers don't hold cluster credentials *Image: Partial support* Requires per-developer cluster access #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot is the validation layer that makes that conversion happen: sandboxes that span multiple services and dependencies, Smart Tests and Jobs running inside your cluster, and an MCP server with governed Plans that lets agents validate their own work. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Works with your coding agents *Image: Claude Code logo**Image: Cursor logo**Image: OpenAI logo* Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel What is the main difference between Signadot and mirrord? mirrord gives you the ability to test against your cluster. Signadot gives you everything you need to actually validate code at agent scale: every developer and coding agent gets its own isolated sandbox, a built-in testing runtime (Smart Tests and Jobs), and platform-governed Plans to validate changes against real services before a PR is ever opened. Signadot also keeps cluster access centralized behind a control plane with SSO and RBAC, rather than putting cluster credentials on every developer's machine. How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Okteto Source: https://www.signadot.com/comparison/okteto/ Summary: Signadot compared to Okteto for cloud development environments. ### **The enterprise alternative to Okteto** *Image: Check mark* Virtualized environments for developers and agents without duplicating infrastructure. *Image: Check mark* Enable automated testing and true team collaboration in shared sandboxes. *Image: Check mark* Cost-efficient at scale as agents multiply the number of concurrent environments needed. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Diagram of a Signadot sandbox testing a service against the baseline environment* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Signadot uses shared environments to save 10x more resources than Okteto's duplicated environments. Okteto is a tool for Kubernetes development environments that creates duplicate environments for every developer. Use cases and capabilities Signadot Kubernetes-Native Validation Platform *Image: Check mark* Virtualized Environments Lightweight sandboxes spin up in seconds inside your existing cluster, whether triggered by a developer or a coding agent. No infrastructure duplication. *Image: Check mark* Composable Validation A framework of reusable tools and actions that agents and developers invoke to validate changes against real dependencies, including async systems like Kafka and SQS. *Image: Check mark* Cost-Efficient at Scale Practical and affordable to run parallel validation across large fleets of agents and developers on every PR. Okteto Development Environment Focus *Image: question mark icon* Heavy & Costly Duplication Creates a full, heavyweight copy of all services for every environment. This model is slow to spin up, drives up infrastructure costs, and does not scale. This is especially true as coding agents multiply the number of concurrent environments needed. *Image: question mark icon* No Support for sharing Async systems Message queues need to be duplicated for every environment Impractical for Automated Testing Signadot combines virtualized environments with a composable validation framework on your existing Kubernetes cluster. Agents and developers get fast, isolated, full-fidelity feedback on every change without linear growth in infrastructure cost. *Image: preview environments icon* Previews for Every Pull Request From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* Launch Previews in Seconds Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Cut Infrastructure Cost by 90% Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/guides/set-up-pr-sandboxes/) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Okteto Local Development *Image: Check mark* Run services locally while routing traffic to/from cluster *Image: Check mark* Run services locally and code sync to cluster PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Check mark* Creates full duplicate environments for each PR, requiring significantly more resources Automated Testing *Image: Check mark* Built-in support for automated testing (including AI-powered SmartTests) *Image: Not supported* Out of scope Team Collaboration *Image: Check mark* Multiple team members can collaborate by combining Sandboxes *Image: Not supported* Primarily designed for individual usage Data Isolation *Image: Check mark* Supports tunable data isolation strategies *Image: Not supported* Data needs to be duplicated in each environment Infrastructure Cost *Image: Check mark* Minimal (no environment duplication) *Image: Check mark* High due to infrastructure duplication PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Check mark* Creates full duplicate environments for each PR, requiring significantly more resources Agentic Development *Image: Check mark* MCP server for autonomous agent workflows *Image: Check mark* AI Agent Fleets (beta) runs agents in full duplicate environments, adding infrastructure cost per session #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Telepresence Source: https://www.signadot.com/comparison/telepresence/ Summary: Signadot compared to Telepresence for local-to-cluster development. ### **The enterprise alternative to Telepresence** *Image: Check mark* Go beyond local testing: Virtualized environments for PR previews, automated tests, and agentic validation. *Image: Check mark* Natively test complex asynchronous microservices using Kafka, SQS and others. *Image: Check mark* Agents and developers validate against real dependencies in seconds via MCP. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Diagram of a Signadot sandbox testing a service against the baseline environment* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Telepresence is not built for PR reviews or automated testing. Signadot is. Telepresence is a tool for [local development](https://www.signadot.com/guide-to-local-development-kubernetes/) that connects your local workstation to a Kubernetes cluster. Use cases and capabilities Signadot Kubernetes-Native Validation Platform *Image: Check mark* Virtualized Environments Lightweight sandboxes spin up in seconds inside your existing cluster, no infrastructure duplication *Image: Check mark* Composable Validation A framework of reusable tools and actions that agents and developers invoke to validate changes against real dependencies *Image: Check mark* Agentic Development Coding agents provision sandboxes and validate changes autonomously via MCP Telepresence Local Development Focus *Image: Check mark* Local Development Run services locally while connecting to cluster resources Not designed for PR previews or automated testing Signadot combines virtualized environments with a composable validation framework on your existing Kubernetes cluster. Agents and developers get fast, isolated, full-fidelity feedback on every change without linear growth in infrastructure cost. *Image: preview environments icon* Previews for Every Pull Request From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* Launch Previews in Seconds Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Cut Infrastructure Cost by 90% Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/guides/set-up-pr-sandboxes/) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Telepresence Local Development *Image: Check mark* Run services locally while connecting to cluster *Image: Check mark* Run services locally while connecting to cluster PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Not supported* Not designed for this use case Automated Testing *Image: Check mark* Built-in support for automated testing (including AI-powered SmartTests) *Image: Not supported* Out of scope Team Collaboration *Image: Check mark* Multiple team members can collaborate by combining Sandboxes *Image: Not supported* Primarily designed for individual usage Data Isolation *Image: Check mark* Supports tunable data isolation strategies *Image: Not supported* Limited (uses clusting cluster data) VPN Compatibility *Image: Check mark* Works well with VPN tools *Image: Not supported* May have issues with some VPN setups Scalability *Image: Check mark* Scales to thousands of concurrent developer and agent environments *Image: Not supported* Can face reliability challenges at scale Support for Async systems *Image: Check mark* Native support for async systems like Kafka, SQS, RabbitMQ, Google Pub/Sub, NATS etc *Image: Not supported* Out of scope Multiple Service Testing *Image: Check mark* Test changes across multiple services with RouteGroups *Image: Not supported* Limited to single service focus Agentic Development *Image: Check mark* MCP server for autonomous agent workflows *Image: Not supported* Not designed for agent-driven development #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs vCluster Source: https://www.signadot.com/comparison/vcluster/ Summary: Signadot compared to vCluster for virtual Kubernetes clusters. ### **The enterprise alternative to vCluster** *Image: Check mark* Test microservices without duplicating infrastructure using lightweight request-level isolation. *Image: Check mark* Enable developers and agents to validate in parallel on shared environments without stepping on each other. *Image: Check mark* Hundreds of concurrent sandboxes on a single cluster with minimal resource overhead. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Diagram of a Signadot sandbox testing a service against the baseline environment* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### vCluster creates virtual clusters for isolation. Signadot provides testing sandboxes without the overhead. vCluster creates virtual Kubernetes clusters within a physical host cluster, providing full isolation with dedicated control planes. Use cases and capabilities Signadot Kubernetes-Native Validation Platform *Image: Check mark* Virtualized Environments Lightweight sandboxes isolate changes within your existing cluster. No duplication needed. *Image: Check mark* Composable Validation A framework of reusable tools and actions for validating changes against real dependencies at scale. *Image: Check mark* Agentic Development Agents and developers validate in parallel. Hundreds of concurrent sandboxes on a single cluster without conflicts. vCluster Virtual Cluster Focus *Image: Check mark* Virtual Cluster Isolation Full control plane isolation with separate API servers per virtual cluster. Not designed for application-level testing or PR preview workflows Signadot combines virtualized environments with a composable validation framework on your existing Kubernetes cluster. Agents and developers get fast, isolated, full-fidelity feedback on every change without linear growth in infrastructure cost. *Image: preview environments icon* Previews for Every Pull Request From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* Launch Previews in Seconds Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Cut Infrastructure Cost by 90% Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/guides/set-up-pr-sandboxes/) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot vCluster Primary Purpose *Image: Check mark* Microservices testing with request-level isolation *Image: Check mark* Fully isolated virtual Kubernetes clusters PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Not supported* Not designed for this use case Automated Testing *Image: Check mark* Built-in support for automated testing (including AI-powered SmartTests) *Image: Not supported* Out of scope Isolation Level *Image: Check mark* Application layer with intelligent request routing *Image: Check mark* K8s namespace level with separate control planes Resource Usage *Image: Check mark* Very lightweight, minimal overhead *Image: Not supported* Lighter than physical clusters but heavier than sharing Team Collaboration *Image: Check mark* Developers and agents can collaborate by combining Sandboxes *Image: Not supported* Primarily designed for cluster-level isolation Data Isolation *Image: Check mark* Supports tunable data isolation strategies *Image: Check mark* Full data isolation per virtual cluster Agentic Development *Image: Check mark* MCP server for autonomous agent workflows *Image: Not supported* Not designed for agent-driven development #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Qovery Source: https://www.signadot.com/comparison/qovery/ Summary: Signadot compared to Qovery for preview environments. ### The enterprise alternative to Qovery *Image: Check mark* Virtualized environments for developers and agents without duplicating infrastructure. *Image: Check mark* Enable automated testing and true team collaboration in shared sandboxes. *Image: Check mark* Cost-efficient at scale as agents multiply the number of concurrent environments needed. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Diagram of a Signadot sandbox testing a service against the baseline environment* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Qovery is built for managing duplicated environments, not efficient microservices testing. Signadot is. Qovery is a DevOps automation platform for provisioning and managing complete cloud infrastructure and environments Use cases and capabilities Signadot Kubernetes-Native Validation Platform *Image: Check mark* Virtualized Environments Lightweight sandboxes spin up in seconds inside your existing cluster, whether triggered by a developer or a coding agent. No infrastructure duplication. *Image: Check mark* Composable Validation A framework of reusable tools and actions that agents and developers invoke to validate changes against real dependencies, including async systems like Kafka and SQS. *Image: Check mark* Cost-Efficient at Scale Practical and affordable to run parallel validation across large fleets of agents and developers on every PR. Qovery Environment Management solution *Image: Check mark* Heavy & Costly Duplication Creates a full, heavyweight copy of all services for every environment. This model is slow to spin up, drives up infrastructure costs, and does not scale. This is especially true as coding agents multiply the number of concurrent environments needed. *Image: Check mark* No Support for sharing Async systems Message queues need to be duplicated for every environment Impractical for Automated Testing Signadot combines virtualized environments with a composable validation framework on your existing Kubernetes cluster. Agents and developers get fast, isolated, full-fidelity feedback on every change without linear growth in infrastructure cost. *Image: preview environments icon* Previews for Every Pull Request From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* Launch Previews in Seconds Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Cut Infrastructure Cost by 90% Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/guides/set-up-pr-sandboxes/) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Qovery Local Development *Image: Check mark* Run services locally and route traffic to/from a remote Kubernetes cluster *Image: Not supported* Not optimized for local dev PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Check mark* Creates complete duplicate environments for each PR, requiring significantly more resources Automated Testing *Image: Check mark* Built-in support for automated testing (including AI-powered SmartTests) *Image: Not supported* Out of scope Isolation Model *Image: Check mark* Request routing based isolation *Image: Not supported* Full infrastructure duplication Primary Focus *Image: Check mark* Microservices testing platform *Image: Check mark* DevOps automation platform Agentic Development *Image: Check mark* MCP server for autonomous agent workflows *Image: Check mark* MCP server and AI Copilot available; full environment duplication adds cost and latency per agent session #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Release Source: https://www.signadot.com/comparison/release/ Summary: Signadot compared to Release for ephemeral environments. ### **The enterprise alternative to Release** *Image: Check mark* Spin up validation environments in seconds, not minutes or hours. Fast enough for agents to validate in a closed loop. *Image: Check mark* Test at scale without duplicating infrastructure and related costs. *Image: Check mark* Composable validation framework lets agents and developers validate against real dependencies without infrastructure duplication. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Diagram of a Signadot sandbox testing a service against the baseline environment* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Release duplicates full environments for each test. Signadot uses intelligent sandboxes instead. Release creates complete environment replicas by provisioning new infrastructure for each environment. Use cases and capabilities Signadot Kubernetes-Native Validation Platform *Image: Check mark* Virtualized Environments Lightweight sandboxes spin up in seconds inside your existing cluster. No new infrastructure needed. *Image: Check mark* Composable Validation Define reusable validation workflows that agents and developers invoke to test against real dependencies. *Image: Check mark* Agentic Velocity Agents validate changes autonomously via MCP. Lightweight sandboxes mean no per-session infrastructure cost. Release Environment Replication Focus *Image: Check mark* Full Environment Replication Creates complete copies of your infrastructure stack for testing, demos, and staging. Not designed for lightweight validation or request-level isolation Signadot combines virtualized environments with a composable validation framework on your existing Kubernetes cluster. Agents and developers get fast, isolated, full-fidelity feedback on every change without linear growth in infrastructure cost. *Image: preview environments icon* Previews for Every Pull Request From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* Launch Previews in Seconds Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Cut Infrastructure Cost by 90% Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/guides/set-up-pr-sandboxes/) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Release Primary Focus *Image: Check mark* Developer testing for microservices *Image: Check mark* Various use cases (testing, demos, staging) Setup Time *Image: Check mark* Seconds with request-level isolation *Image: Not supported* Minutes to hours for full infrastructure Resource Usage *Image: Check mark* Low—shares your existing cluster *Image: Not supported* High—duplicates infrastructure Isolation Method *Image: Check mark* Request routing with context propagation *Image: Check mark* Complete infrastructure separation PR Previews *Image: Check mark* Automatically create previews for PR testing *Image: Not supported* Full environment provisioning per PR Data Handling *Image: Check mark* Tunable isolation with data partitioning options *Image: Check mark* Full data isolation with infrastructure Cloud Deployment *Image: Check mark* Runs in your existing K8s cluster *Image: Not supported* Provisions new infra in your cloud or theirs Agentic Development *Image: Check mark* MCP server for autonomous agent workflows *Image: Check mark* MCP server available; full environment replication adds latency and cost per agent session #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Pact Source: https://www.signadot.com/comparison/pact/ Summary: Signadot compared to Pact for contract testing. ### Choose SmartTests over Pact for zero-maintenance contract testing *Image: Check mark* No contract maintenance required *Image: Check mark* Test with real dependencies in Kubernetes *Image: Check mark* Agents ingest results and self-correct without human involvement [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) *Image: Signadot SmartTests results for a pull request sandbox* Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### **Pact requires constant maintenance as your APIs evolve. SmartTests eliminates this burden entirely.** Traditional contract testing tools like Pact were built for a different era. As your microservices grow and APIs evolve rapidly, the maintenance overhead becomes a bottleneck that slows down development rather than enabling it. Use cases and capabilities ##### SmartTests vs. Pact SmartTests **AI-Powered Validation for Developers and Agents** Reality-based testing with real dependencies *Image: Check mark* Contract Testing AI automatically detects breaking changes without explicit contracts. Agents can ingest results to self-correct without human involvement. *Image: Check mark* Zero Maintenance Tests adapt to API changes automatically *Image: Check mark* Kubernetes-Native Built specifically for cloud-native microservices Pact **Mock-Based Testing Focus** Consumer-driven contract definitions *Image: Check mark* Contract Testing Manual contract definitions between consumers and providers Contracts need constant updates as APIs evolve**.** Requires mock services for all dependencies**.** Not optimized for Kubernetes. SmartTests offers a fundamentally different approach to contract testing - using AI to detect breaking changes in real environments rather than maintaining complex mock-based contracts that quickly become outdated. *Image: preview environments icon* Test Real APIs, Not Mocks From web to mobile frontends, generate on-demand previews that let your team test earlier and deploy with confidence. *Image: launch speed icon* AI Finds What Matters Don't waste time waiting. Signadot delivers previews in seconds while competitors take minutes, keeping your engineering velocity high. *Image: cost savings icon* Zero Contract Maintenance Testing across pull requests without duplicating environments cuts down cloud costs dramatically. [Learn more](https://www.signadot.com/docs/concepts/smart-tests-and-jobs) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering #### See how we compare From API changes to breaking change detection in minutes. Our AI-powered workflow automatically identifies contract violations while you focus on development - no mock maintenance required. Feature SmartTests Pact Testing Approach *Image: Check mark* AI-powered API diffing with real services *Image: Check mark* Consumer-driven contracts with mocks Maintenance *Image: Check mark* Zero - tests auto-adapt *Image: Not supported* High - contracts need constant updates Test Environment *Image: Check mark* Real dependencies in Kubernetes sandboxes *Image: Not supported* Mock services and providers Setup Complexity *Image: Check mark* Minutes with simple HTTP requests *Image: Not supported* Days/weeks with detailed contract specs Team Coordination *Image: Check mark* Minimal - no contract exchange needed *Image: Not supported* Significant - consumer/provider coordination Breaking Change Detection *Image: Check mark* AI identifies meaningful changes automatically *Image: Not supported* Manual definition of what breaks Future Roadmap *Image: Check mark* Performance, security, log testing planned *Image: Not supported* Focused on contract testing only #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot provides the validation infrastructure to make that conversion happen: virtualized environments that spin up in seconds and a composable validation framework that makes feedback fast, isolated, and reproducible at enterprise scale. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Garden Source: https://www.signadot.com/comparison/garden/ Summary: Signadot compared to Garden for Kubernetes environments and testing. Signadot vs Garden ### **The Garden.io alternative that doesn't duplicate your stack.** Garden spins up a full copy of your stack for every environment. Signadot sandboxes deploy only what changed, ready in seconds on a shared cluster. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) One platform · every layer Agent-native validation PlansMCP serverAgent skills Testing runtime Smart TestsJobs Isolated environments SandboxesRequest routingResource plugins Your Kubernetes cluster Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Signadot shares what Garden duplicates. Garden is a Kubernetes automation tool that builds and deploys a duplicate environment for every developer, pull request, and test run. How they compare Signadot Kubernetes-Native Validation Platform *Image: Check mark* Comprehensive Environments, a testing runtime, and platform-governed agentic verification workflows in one product. Sandboxes, Smart Tests, Jobs, and Plans. *Image: Check mark* Unified Architecture Sandboxes, Smart Tests, Jobs, and Plans work the same in local dev, in PRs, and in agent loops. Same primitives everywhere. *Image: Check mark* Extensible Resource plugins extend isolation to any database, queue, or async system, including resources outside Kubernetes. *Image: Check mark* Built for Devs and Agents Chrome extension, SDKs, CLI, and MCP server. Platform teams integrate easily. Devs and agents use it natively. *Image: Check mark* Centralized, Governed Access A central control plane holds cluster access. Developers and agents connect through it with SSO and RBAC, so credentials stay centrally governed. Garden Full-Stack Environment Automation *Image: Check mark* Full-Stack Duplication Every Garden environment deploys every service in the Stack Graph, databases included. Twenty services means twenty deployed per environment. *Image: Check mark* Built Around the Build Stack Graph and caching accelerate builds and tests, but each environment still takes minutes to provision and adds cluster cost. *Image: Check mark* Config-Heavy garden.yml action definitions across every service and repo, with a documented learning curve. *Image: Check mark* Cost Scales With Every Environment Each concurrent developer or PR environment carries full-stack resource cost. *Image: Check mark* Not Built for Agent Scale Running a full stack per coding agent is cost-prohibitive. Agents need cheap per-task isolation. Three Pillars #### Built for scale. Unified. Comprehensive. agent-01: feature-auth validated agent-02: bugfix-cart running agent-03: refactor-db validated agent-04: pr-1234 testing agent-05: fix-pagination validated agent-06: spike-redis running agent-07: hotfix-auth testing Built for Agents ##### One sandbox per agent. Thousands in parallel. Each agent gets its own lightweight environment, cheap and fast. They run more validations autonomously before human review. Local Dev inner loop PR Validation outer loop Same Sandbox one platform Unified Architecture ##### Inner loop and outer loop on one platform. The same sandbox abstraction covers local development and PR validation. One platform. One mental model. Testing & Validation Runtime Smart Tests Jobs CI + Agents Environments \+ ∞ Comprehensive Coverage ##### Environments and a test runtime, built in. Signadot provides the environments and the test runtime on one platform, built for CI pipelines and coding agents. All of it runs inside your cluster. [Learn more](https://www.signadot.com/docs) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Garden Environment model *Image: Check mark* Sandboxes deploy only the services you changed and route requests to shared dependencies on a stable shared cluster *Image: Not supported* Every environment replicates the full stack Time to environment *Image: Check mark* Sandboxes are ready in seconds *Image: Partial support* Full-stack provisioning takes minutes, caching helps repeat runs Cost per environment *Image: Check mark* Marginal cost per sandbox, hundreds can run concurrently on one cluster *Image: Not supported* Full-stack resource cost for every concurrent environment Build and test caching *Image: Partial support* Signadot is not a build tool and works with your existing CI builds *Image: Check mark* Strong build and test caching is a core Garden strength Local development *Image: Check mark* Route your laptop into the cluster and iterate with your local tools against real dependencies *Image: Partial support* Sync mode reloads code into a full environment you first provision PR preview environments *Image: Check mark* A sandbox per pull request from CI, ready in seconds *Image: Partial support* A full-stack namespace per PR with the associated cost and wait Test automation *Image: Check mark* Cross-service test execution with request-scoped isolation built in *Image: Partial support* Test actions in the Stack Graph run inside duplicated environments Database and message queue isolation *Image: Check mark* Request-scoped isolation against shared stateful services *Image: Partial support* Isolation by duplicating the datastore in each environment Coding agent support *Image: Check mark* One sandbox per agent, thousands in parallel *Image: Not supported* No per-agent isolation model Configuration overhead *Image: Check mark* Works with your existing manifests, no per-service config rewrite *Image: Not supported* garden.yml actions written and maintained per service Production fidelity *Image: Check mark* Tests run against real shared dependencies in a stable shared cluster *Image: Partial support* Production-like only if you can afford to run the whole stack per environment Scales with team size *Image: Check mark* Shared cluster model scales to large teams *Image: Not supported* Cost and provisioning time grow with every concurrent environment #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot is the validation layer that makes that conversion happen: sandboxes that span multiple services and dependencies, Smart Tests and Jobs running inside your cluster, and an MCP server with governed Plans that lets agents validate their own work. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Works with your coding agents *Image: Claude Code logo**Image: Cursor logo**Image: OpenAI logo* Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel What is the main difference between Signadot and Garden? Garden is a build and environment automation platform that provisions a full copy of your stack for each environment. Signadot creates lightweight sandboxes on a shared Kubernetes cluster where only changed services are deployed and requests are routed to shared dependencies, so environments are ready in seconds at a fraction of the cost. How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. Can I use Garden and Signadot together? Yes. Garden or your existing CI can build images, and Signadot deploys just the changed services into sandboxes for testing against shared dependencies. Many teams keep their build tooling and replace environment duplication with sandboxes. Why do teams look for Garden.io alternatives? The most common reasons are the cost of duplicating the full stack for every environment, provisioning times measured in minutes rather than seconds, and the effort of writing and maintaining garden.yml configuration across services. Read our [guide to microservices testing environments on Kubernetes](https://www.signadot.com/a-comprehensive-guide-to-microservices-testing-environments-on-kubernetes/) to learn more. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Tilt Source: https://www.signadot.com/comparison/tilt/ Summary: Signadot compared to Tilt for Kubernetes microservices development. Signadot vs Tilt ### **The Tilt alternative that scales beyond your laptop.** Tilt rebuilds your services on a local Kubernetes cluster until your laptop runs out of headroom. Signadot sandboxes run on a shared cluster with no resource ceiling. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) One platform · every layer Agent-native validation PlansMCP serverAgent skills Testing runtime Smart TestsJobs Isolated environments SandboxesRequest routingResource plugins Your Kubernetes cluster Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Tilt isn't built for PR previews or automated testing. Signadot is. Tilt is a tool for [local development](https://www.signadot.com/guide-to-local-development-kubernetes/) that rebuilds and redeploys your microservices to a Kubernetes cluster on your laptop. How they compare Signadot Kubernetes-Native Validation Platform *Image: Check mark* Comprehensive Environments, a testing runtime, and platform-governed agentic verification workflows in one product. Sandboxes, Smart Tests, Jobs, and Plans. *Image: Check mark* Unified Architecture Sandboxes, Smart Tests, Jobs, and Plans work the same in local dev, in PRs, and in agent loops. Same primitives everywhere. *Image: Check mark* Extensible Resource plugins extend isolation to any database, queue, or async system, including resources outside Kubernetes. *Image: Check mark* Built for Devs and Agents Chrome extension, SDKs, CLI, and MCP server. Platform teams integrate easily. Devs and agents use it natively. *Image: Check mark* Centralized, Governed Access A central control plane holds cluster access. Developers and agents connect through it with SSO and RBAC, so credentials stay centrally governed. Tilt Local Development Tool *Image: Check mark* Laptop-Bound Tilt needs a local cluster such as kind, minikube, or Docker Desktop. Laptop RAM and CPU become the ceiling as the service count grows into the tens. *Image: Check mark* Inner Loop Only No PR previews, no CI testing, and no environment story beyond local development. *Image: Check mark* A Tiltfile to Maintain Starlark programs that grow with the stack and need dedicated upkeep. *Image: Check mark* Local Drift A scaled-down local cluster diverges from production topology and data. *Image: Check mark* One Cluster per Developer Every developer installs, configures, and maintains their own local Kubernetes cluster, then keeps it in sync with the rest of the team. Three Pillars #### Built for scale. Unified. Comprehensive. agent-01: feature-auth validated agent-02: bugfix-cart running agent-03: refactor-db validated agent-04: pr-1234 testing agent-05: fix-pagination validated agent-06: spike-redis running agent-07: hotfix-auth testing Built for Agents ##### One sandbox per agent. Thousands in parallel. Each agent gets its own lightweight environment, cheap and fast. They run more validations autonomously before human review. Local Dev inner loop PR Validation outer loop Same Sandbox one platform Unified Architecture ##### Inner loop and outer loop on one platform. The same sandbox abstraction covers local development and PR validation. One platform. One mental model. Testing & Validation Runtime Smart Tests Jobs CI + Agents Environments \+ ∞ Comprehensive Coverage ##### Environments and a test runtime, built in. Signadot provides the environments and the test runtime on one platform, built for CI pipelines and coding agents. All of it runs inside your cluster. [Learn more](https://www.signadot.com/docs) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Tilt Environment model *Image: Check mark* Lightweight sandboxes on a shared Kubernetes cluster, only changed services deployed *Image: Not supported* The full stack runs on each developer's laptop Scale with service count *Image: Check mark* Shared cluster resources handle stacks of tens to hundreds of services *Image: Not supported* Laptop resources cap out as services grow into the tens Local development *Image: Check mark* Route your laptop into the cluster and keep your local editor, debugger, and tools *Image: Check mark* Strong local loop, live\_update syncs code into containers in seconds Iteration speed *Image: Check mark* Run the changed service locally with native hot reload while testing against real dependencies *Image: Check mark* Fast rebuild and sync loop against the local cluster PR preview environments *Image: Check mark* A sandbox per pull request from CI, ready in seconds *Image: Not supported* Not covered, Tilt is local development only CI and test automation *Image: Check mark* Sandboxes and test execution integrate with your CI pipeline *Image: Not supported* No CI or automated testing story Production fidelity *Image: Check mark* Test against real shared dependencies in a stable shared cluster *Image: Partial support* Scaled-down local replicas drift from production Team onboarding *Image: Check mark* No local cluster to install, new developers connect to the shared cluster *Image: Partial support* Every developer sets up and maintains a local Kubernetes cluster Database and message queue isolation *Image: Check mark* Request-scoped isolation against shared stateful services *Image: Partial support* Local copies only, seeded and maintained per laptop Coding agent support *Image: Check mark* One sandbox per agent, thousands in parallel *Image: Not supported* Each agent would need its own local cluster Resource cost *Image: Check mark* Marginal cost per sandbox on shared infrastructure *Image: Partial support* No cloud bill but developer laptops and time absorb the load Commercial support *Image: Check mark* Commercial platform with enterprise support *Image: Not supported* Community support only, no commercial offering #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot is the validation layer that makes that conversion happen: sandboxes that span multiple services and dependencies, Smart Tests and Jobs running inside your cluster, and an MCP server with governed Plans that lets agents validate their own work. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Works with your coding agents *Image: Claude Code logo**Image: Cursor logo**Image: OpenAI logo* Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel What is the main difference between Signadot and Tilt? Tilt is a local development tool that rebuilds and redeploys your microservices to a Kubernetes cluster on your laptop. Signadot creates lightweight sandboxes on a shared Kubernetes cluster where only changed services run and requests route to shared dependencies, which removes the laptop resource ceiling and covers pull request and CI testing as well as local development. How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. Can I use Tilt and Signadot together? Yes. Some teams keep Tilt for single-service iteration against a small local cluster and use Signadot to test changes against real dependencies, provision PR environments, and run automated tests. Many find that routing their laptop into a Signadot sandbox replaces the local cluster entirely. Check out our [guide to local development on Kubernetes](https://www.signadot.com/guide-to-local-development-kubernetes/) for more details. Why do teams look for Tilt alternatives? The most common reasons are laptop resource limits as the number of microservices grows, the gap between a scaled-down local cluster and production, and ongoing Tiltfile maintenance. See our [article on local Kubernetes development environments](https://www.signadot.com/blog/local-kubernetes-dev-environments/) for more context. #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- ## vs Skaffold Source: https://www.signadot.com/comparison/skaffold/ Summary: Signadot compared to Skaffold for the Kubernetes development loop. Signadot vs Skaffold ### **The Skaffold alternative that skips the rebuild loop.** Skaffold rebuilds, pushes, and redeploys images on every code change. Signadot deploys only the service you changed and routes requests to shared dependencies. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) One platform · every layer Agent-native validation PlansMCP serverAgent skills Testing runtime Smart TestsJobs Isolated environments SandboxesRequest routingResource plugins Your Kubernetes cluster Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Skaffold automates the rebuild loop. Signadot removes it. Skaffold is a tool for [local development](https://www.signadot.com/guide-to-local-development-kubernetes/) that rebuilds and redeploys container images to your Kubernetes cluster on every code change. How they compare Signadot Kubernetes-Native Validation Platform *Image: Check mark* Comprehensive Environments, a testing runtime, and platform-governed agentic verification workflows in one product. Sandboxes, Smart Tests, Jobs, and Plans. *Image: Check mark* Unified Architecture Sandboxes, Smart Tests, Jobs, and Plans work the same in local dev, in PRs, and in agent loops. Same primitives everywhere. *Image: Check mark* Extensible Resource plugins extend isolation to any database, queue, or async system, including resources outside Kubernetes. *Image: Check mark* Built for Devs and Agents Chrome extension, SDKs, CLI, and MCP server. Platform teams integrate easily. Devs and agents use it natively. *Image: Check mark* Centralized, Governed Access A central control plane holds cluster access. Developers and agents connect through it with SSO and RBAC, so credentials stay centrally governed. Skaffold Build and Deploy Automation *Image: Check mark* The Loop Is the Product Every change triggers watch, build, push, and redeploy. Fast when file sync works, minutes when it falls back to image rebuilds. *Image: Check mark* A Full Environment per Developer Skaffold assumes each developer or PR gets its own cluster or namespace running everything. *Image: Check mark* Sync Fragility Documented file sync failures after pod restarts and slow file watching on macOS push developers back into full rebuilds. *Image: Check mark* The CI Rebuild Tax Ephemeral CI runners rebuild every image on every run because the local build cache does not persist. *Image: Check mark* No Testing Layer Build and deploy only. No test orchestration, no isolation model, no support for coding agents. Three Pillars #### Built for scale. Unified. Comprehensive. agent-01: feature-auth validated agent-02: bugfix-cart running agent-03: refactor-db validated agent-04: pr-1234 testing agent-05: fix-pagination validated agent-06: spike-redis running agent-07: hotfix-auth testing Built for Agents ##### One sandbox per agent. Thousands in parallel. Each agent gets its own lightweight environment, cheap and fast. They run more validations autonomously before human review. Local Dev inner loop PR Validation outer loop Same Sandbox one platform Unified Architecture ##### Inner loop and outer loop on one platform. The same sandbox abstraction covers local development and PR validation. One platform. One mental model. Testing & Validation Runtime Smart Tests Jobs CI + Agents Environments \+ ∞ Comprehensive Coverage ##### Environments and a test runtime, built in. Signadot provides the environments and the test runtime on one platform, built for CI pipelines and coding agents. All of it runs inside your cluster. [Learn more](https://www.signadot.com/docs) Testimonials #### Hear from our customers *Image: previous slide arrow**Image: next slide arrow* *Image: Brex logo* $2M saved annually On the margin, with the Signadot approach, **99.8%** of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not. *Image: Connor Braa, Software Engineering Manager at Brex* Connor Braa Software Engineering Manager *Image: Bitso logo* 83% lower change failure rate We basically stopped creating full preview environments and replaced our custom solution with Signadot. Instead of isolating the full environment, the strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast. *Image: Marcus Tavares, Staff Software Engineer at Bitso* Marcus Tavares Staff Software Engineer *Image: Wealthsimple logo* No more fighting over staging Creating a sandbox is extremely fast, it works every time, lets me test what I'm building quickly, and move on. This is awesome. *Image: Tyler Marien, Senior Software Developer at Wealthsimple* Tyler Marien Senior Software Developer *Image: Miro logo* 10x integration capacity Our engineers were spending more time waiting for an environment than shipping. Now they test against our real services in parallel, which made a whole tier of fixed test infrastructure unnecessary. Retiring environments we had carried for years is projected to save us **several million dollars annually**. *Image: Jony Jeyaratnam, Head of Engineering at Miro* Jony Jeyaratnam Head of Engineering [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### See how we compare From code changes to testing environments in minutes. Our automated workflow lets you focus on development while we handle the preview environment setup and teardown. Feature Signadot Skaffold Environment model *Image: Check mark* Lightweight sandboxes on a shared cluster. Only changed services deployed. Requests route to shared dependencies. *Image: Not supported* A full environment per developer or PR. Iteration speed *Image: Check mark* Run the changed service locally with native hot reload while testing against real dependencies. *Image: Partial support* File sync is fast when it works. Image rebuilds take minutes when it does not. Build automation *Image: Partial support* Signadot is not a build tool and works with your existing CI builds. *Image: Check mark* Mature build tooling with broad builder support including Docker, Jib, and Buildpacks. Multi-environment configuration *Image: Check mark* No per-environment configuration to maintain. *Image: Partial support* Profiles in skaffold.yaml cover dev, staging, and prod but grow verbose. PR preview environments *Image: Check mark* A sandbox per pull request from CI, ready in seconds. *Image: Not supported* Not provided. Teams build this separately. Test automation *Image: Check mark* Cross-service test execution with request-scoped isolation built in. *Image: Partial support* A basic test phase in the pipeline. No cross-service testing. Database and message queue isolation *Image: Check mark* Request-scoped isolation against shared stateful services. *Image: Not supported* No isolation model. Environments share or duplicate datastores manually. CI efficiency *Image: Check mark* Only changed services are built and deployed. Everything else is shared. *Image: Not supported* Documented rebuild tax in ephemeral CI environments where caches do not persist. Coding agent support *Image: Check mark* One sandbox per agent. Thousands in parallel. *Image: Not supported* No per-agent isolation model. Cost at team scale *Image: Check mark* Marginal cost per sandbox. Hundreds run concurrently on one cluster. *Image: Not supported* Environment duplication per developer and per PR drives cluster cost. Local development *Image: Check mark* Route your laptop into the shared cluster and keep your local tools. *Image: Partial support* skaffold dev works against a local or remote cluster that you provision and maintain. Project maintenance *Image: Check mark* Actively developed commercial platform. *Image: Check mark* Actively maintained open source project backed by Google. #### The bottleneck has shifted from writing code to proving it works. Agentic development only delivers value when code generation velocity converts into shipped product. Signadot is the validation layer that makes that conversion happen: sandboxes that span multiple services and dependencies, Smart Tests and Jobs running inside your cluster, and an MCP server with governed Plans that lets agents validate their own work. [ Try free *Image: arrow icon*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) #### Built for Developers and Agents [Get a demo](https://www.signadot.com/schedule-a-call/)[ Try free *Image: arrow icon*](https://www.signadot.com/signup/) Works with your coding agents *Image: Claude Code logo**Image: Cursor logo**Image: OpenAI logo* Integrate with CI tools you already use *Image: jenkins logo**Image: GitLab logo**Image: GitHub logo**Image: Bitbucket logo* Support all test frameworks *Image: Cypress logo**Image: Selenium logo**Image: Cucumber logo**Image: k6 logo**Image: Postman logo**Image: Playwright logo* Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test. *Image: Naomi Klein, Lead Infrastructure Engineer at Laurel* Naomi Klein Lead Infrastructure Engineer at Laurel What is the main difference between Signadot and Skaffold? Skaffold automates the build, push, and redeploy loop for Kubernetes development. Signadot removes most of that loop. Sandboxes deploy only the services you changed and route requests to shared dependencies on a stable shared cluster, so you test in seconds without rebuilding or redeploying the rest of the stack. How is Signadot different from other testing solutions? Unlike traditional approaches that create full duplicate environments, Signadot uses a unique request-routing approach that allows you to test changes in isolation while sharing existing infrastructure. This results in up to 90% cost savings while delivering significantly faster feedback cycles. How does Signadot integrate with my CI/CD pipeline? Signadot provides a CLI and API that integrates with all popular CI/CD systems including GitHub Actions, Jenkins, CircleCI, and GitLab. Our integration creates sandboxes for each pull request, runs tests, and reports results back to your pull request, providing complete visibility into test outcomes. What testing frameworks does Signadot support? Signadot works with any testing framework you currently use, including Cypress, Selenium, Playwright, Postman, RestAssured, JUnit, pytest, and more. There's no need to rewrite your tests - just point them at your sandbox environments using our routing mechanisms. Do I need to modify my applications to use Signadot? No code changes are required to your applications. Signadot works at the network layer by intercepting requests and routing them to the appropriate services. We provide tools like our Chrome extension, SDK, and CLI to make it easy to manage routing without modifying your application code. How long does it take to set up Signadot? Most teams are up and running with Signadot in less than a day. Installation involves deploying our Kubernetes operator to your cluster and configuring your CI/CD pipeline to create sandboxes. Our team provides hands-on support to ensure a smooth onboarding experience. Does Signadot support coding agents? Yes. Signadot's MCP server lets coding agents (including Cursor, Claude Code, and VSCode) provision sandboxes, run tests, and verify changes autonomously. This turns agents from code generators into autonomous engineers that can validate their own work in a closed feedback loop. Can Signadot work with our service mesh? Yes, Signadot integrates with popular service meshes like Istio, Linkerd, and Consul. We can leverage your existing service mesh for routing or use our built-in routing mechanisms if you don't have a service mesh. Our approach is designed to be flexible and work with your existing infrastructure. Can I use Skaffold and Signadot together? Yes. Skaffold can build and deploy the service you changed into a Signadot sandbox, while everything else resolves to shared dependencies. Teams keep their build tooling and stop duplicating environments. See our [guide to local development on Kubernetes](https://www.signadot.com/guide-to-local-development-kubernetes/) for more details. Why do teams look for Skaffold alternatives? The most common reasons are slow rebuild and redeploy loops as services grow, documented file sync reliability issues, full image rebuilds in CI because caches do not persist, and the cost of running a full environment per developer or pull request. Learn [how large engineering teams test on Kubernetes](https://www.signadot.com/blog/large-engineering-teams-testing-on-k8s/). #### Validate code as fast as agents write it. Cut environment costs by 90%. Explore how Signadot helps engineering teams validate code at the speed agents generate it, with cost-efficient parallel validation on your existing Kubernetes infrastructure. [Start for free](https://www.signadot.com/signup/)[ Book a demo *Image: arrow icon*](https://www.signadot.com/schedule-a-call/) --- # Blog & Articles ## Blog Source: https://www.signadot.com/blog/ Summary: Engineering blog covering microservices testing, Kubernetes development, agentic workflows, and DevOps best practices. ### Signadot Blog agents video ##### Watch Claude Code Validate a Microservices Change in a Closed Loop Anirudh Ramanathan June 4, 2026 Two Claude Code sessions, the same microservices task. One ships a change that looks correct. The other uses signadot-validate to catch a cross-service break... [Read more](https://www.signadot.com/blog/claude-code-signadot-validate-demo/) *Image: Watch Claude Code Validate a Microservices Change in a Closed Loop* *Image: LegalOn Technologies' Agent-Ready Golden Path on GKE* cases ephemeral-environments agents ##### LegalOn Technologies' Agent-Ready Golden Path on GKE September 2, 2026 *Image: OpenSpec + Signadot: Integration Tests Inside the Agent Loop* agents integration-e2e-testing ##### OpenSpec + Signadot: Integration Tests Inside the Agent Loop August 12, 2026 *Image: Kubernetes Staging Environments: How to Build, Run, and Share One* ephemeral-environments ##### Kubernetes Staging Environments: How to Build, Run, and Share One July 17, 2026 *Image: Catch Performance Regressions Before the Pull Request With k6 and Signadot Plans* tutorials-guides agents video ##### Catch Performance Regressions Before the Pull Request With k6 and Signadot Plans July 16, 2026 *Image: Comparing Kubernetes Development Tools in 2026: Telepresence, mirrord, Okteto, and Signadot* comparisons ##### Comparing Kubernetes Development Tools in 2026: Telepresence, mirrord, Okteto, and Signadot June 18, 2026 *Image: Watch Claude Code Validate a Microservices Change in a Closed Loop* agents video ##### Watch Claude Code Validate a Microservices Change in a Closed Loop June 4, 2026 *Image: Signadot Plans* product-announcements agents ##### Signadot Plans May 20, 2026 *Image: Introducing the signadot-validate Skill: Close the Loop for Coding Agents Building Microservices* product-announcements agents video ##### Introducing the signadot-validate Skill: Close the Loop for Coding Agents Building Microservices May 8, 2026 *Image: AI Code Testing for Cloud-Native Systems: Why Unit Tests Aren't Enough* opinion agents ##### AI Code Testing for Cloud-Native Systems: Why Unit Tests Aren't Enough May 8, 2026 *Image: Closing the Loop for Coding Agents in Cloud-Native Systems* video product-announcements agents ##### Closing the Loop for Coding Agents in Cloud-Native Systems May 6, 2026 *Image: AI Coding Agents Broke the PR Pipeline. Validation Is How You Fix It.* opinion agents ##### AI Coding Agents Broke the PR Pipeline. Validation Is How You Fix It. May 5, 2026 *Image: Why Claude Needs a Real Environment to Validate Cloud-Native Code* opinion agents ##### Why Claude Needs a Real Environment to Validate Cloud-Native Code May 5, 2026 [1](https://www.signadot.com/blog/) [2](https://www.signadot.com/blog/2/) [3](https://www.signadot.com/blog/3/) [4](https://www.signadot.com/blog/4/) [5](https://www.signadot.com/blog/5/) [6](https://www.signadot.com/blog/6/) [7](https://www.signadot.com/blog/7/) [8](https://www.signadot.com/blog/8/) [9](https://www.signadot.com/blog/9/) [10](https://www.signadot.com/blog/10/) [11](https://www.signadot.com/blog/11/) [12](https://www.signadot.com/blog/12/) [13](https://www.signadot.com/blog/13/) #### Take Signadot for a whirl Learn more about how to scale pre-merge testing with microservices [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) Stay in the loop Get the latest updates from Signadot Validate code as fast as agents write it. [ Sign up ](https://www.signadot.com/signup/)[ Book a demo ](https://www.signadot.com/schedule-a-call/) --- ## Articles Source: https://www.signadot.com/articles/ Summary: In-depth technical articles on testing strategies, platform engineering, and AI-assisted development. ### Signadot Articles [ *Image: Integration tests pass with mocks but staging still breaks: how to catch it earlier* ###### Integration tests pass with mocks but staging still breaks: how to catch it earlier Why integration tests that pass against mocks still produce staging failures, what to add to catch those failures before merge, and what each option costs.... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/) [ *Image: Signadot vs Garden.io: Which Kubernetes Environment Model Fits Your Team?* ###### Signadot vs Garden.io: Which Kubernetes Environment Model Fits Your Team? A technical comparison of Garden's full-stack environment automation and Signadot's shared-cluster Sandboxes: how each model works, where each breaks down, and... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/signadot-vs-garden-io/) [ *Image: Preview Environments for QA and Stakeholder Review* ###### Preview Environments for QA and Stakeholder Review Preview environments give QA, product, and design a live link to review every pull request before it merges, instead of after. This article covers the per-PR... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/preview-environments-for-qa-and-stakeholder-review/) [ *Image: ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains* ###### ArgoCD Preview Environments: How the ApplicationSet Pattern Works and Where It Strains Argo CD's ApplicationSet pull request generator is the standard way to build GitOps-native preview environments, stamping out a full Application and namespace... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/argocd-preview-environments/) [ *Image: Per-PR Preview URLs, Explained* ###### Per-PR Preview URLs, Explained Per-PR preview URLs are nearly free for frontend teams and genuinely hard for backend ones, because the URL only works if it leads to a full working system.... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/per-pr-preview-urls/) [ *Image: What Are Preview Environments? The Complete Kubernetes Guide* ###### What Are Preview Environments? The Complete Kubernetes Guide Traditional staging environments hinder modern software development, causing delays and conflicts in microservice architectures. This article examines preview... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/comprehensive-guide-to-preview-environments/) [ *Image: Best Microservices Testing Solutions for Kubernetes in 2026* ###### Best Microservices Testing Solutions for Kubernetes in 2026 Testing microservices in Kubernetes is no longer just about picking the right tools; it is about rethinking the entire environment strategy. This article... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/best-microservices-testing-solution-for-kubernetes-in-2025/) [ *Image: Reducing Costs and Boosting Productivity with Kubernetes Ephemeral Environments* ###### Reducing Costs and Boosting Productivity with Kubernetes Ephemeral Environments Cut Infrastructure Costs by 90% with Kubernetes Ephemeral Environments. Learn how ephemeral environments unlock faster dev cycles, reduce resource waste, and... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/reducing-costs-boosting-productivity-kubernetes-ephemeral-environments/) [ *Image: AI Powered Contract Testing for Microservices Excellence* ###### AI Powered Contract Testing for Microservices Excellence In modern software development, microservices architectures enable teams to build and deploy services independently, accelerating innovation. However, this... Nick Andrews Read more *Image: arrow icon* ](https://www.signadot.com/articles/ai-powered-contract-testing-for-microservices-excellence/) [ *Image: Isolation Models for Ephemeral Environments: Infra-Level vs. Request-Level* ###### Isolation Models for Ephemeral Environments: Infra-Level vs. Request-Level As ephemeral environments become more popular for testing and development, not all implementations are created equal. One of the most important design... Nick Andrews Read more *Image: arrow icon* ](https://www.signadot.com/articles/isolation-models-for-ephemeral-environments-infra-level-vs-request-level/) [ *Image: Stop Breaking Your Microservices with SmartTests: AI Powered Contract Testing* ###### Stop Breaking Your Microservices with SmartTests: AI Powered Contract Testing Microservices architectures promise agility and scalability, but they also introduce a new set of integration challenges. Integration failures are among the... Nick Andrews Read more *Image: arrow icon* ](https://www.signadot.com/articles/stop-breaking-your-microservices-with-smarttests-ai-powered-contract-testing/) [ *Image: Signadot SmartTests vs Pact Contract Testing* ###### Signadot SmartTests vs Pact Contract Testing Ensuring reliable API interactions between services is critical for maintaining system stability for microservices archictectures. Contract testing has emerged... Nick Andrews Read more *Image: arrow icon* ](https://www.signadot.com/articles/signadot-smarttests-vs-pact-contract-testing/) [ *Image: The Ultimate Guide to Lightweight Kubernetes Environments* ###### The Ultimate Guide to Lightweight Kubernetes Environments Lightweight Kubernetes environments like K3s, Minikube, Kind, and MicroK8s are transforming how developers build and test cloud-native applications. This guide... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/the-ultimate-guide-to-lightweight-kubernetes-environments/) [ *Image: Why Signadot Outperforms Other K8s Testing Solutions* ###### Why Signadot Outperforms Other K8s Testing Solutions Microservices have made application development more scalable—but testing them, especially on Kubernetes, remains a major challenge. Signadot solves this with... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/why-signadot-outperforms-other-k8s-testing-solutions/) [ *Image: Kubernetes Budget Rescue: Trim 90% of Testing Infrastructure Costs* ###### Kubernetes Budget Rescue: Trim 90% of Testing Infrastructure Costs Traditional Kubernetes testing approaches can quickly drain your budget through environment duplication. Learn how Signadot's Kubernetes-native Sandboxes help... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/kubernetes-budget-rescue-trim-90-of-testing-infrastructure-costs/) [ *Image: Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency* ###### Kubernetes Testing: 5 Powerful Strategies to Maximize Efficiency Discover 5 key strategies for optimizing Kubernetes testing in this insightful article. Learn how Signadot's innovative platform enhances testing workflows... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/kubernetes-testing-5-powerful-strategies-to-maximize-efficiency/) [ *Image: Cut Testing Costs 90% with Kubernetes Ephemeral Environments* ###### Cut Testing Costs 90% with Kubernetes Ephemeral Environments This blog post highlights the efficiency of Kubernetes ephemeral environments in software testing, particularly through Signadot's use of Kubernetes Sandboxes,... Arjun Iyer Read more *Image: arrow icon* ](https://www.signadot.com/articles/cut-testing-costs-90-with-kubernetes-ephemeral-environments/) #### Take Signadot for a whirl Learn more about how to scale pre-merge testing with microservices [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) --- ## Resources Source: https://www.signadot.com/resources/ Summary: Whitepapers, guides, and downloadable resources on microservices testing. Documents Videos Webinars [ *Image: Breaking the Staging Bottleneck: Scalable Microservices Testing for Fintech* Whitepaper ##### Breaking the Staging Bottleneck: Scalable Microservices Testing for Fintech This whitepaper reveals how traditional staging breaks under modern FinTech complexity and introduces a faster, safer alternative: sandbox testing. Learn how leaders like Brex and DoorDash are scaling developer velocity and slashing costs with Signadot. ](https://www.signadot.com/resources/breaking-the-staging-bottleneck-scalable-microservices-testing-for-fintech/) [*Image: Creating a Sandbox in your K8s Cluster with a Local Workload*](https://www.signadot.com/videos/creating-a-sandbox-in-your-k8s-cluster-with-a-local-workload/) [ 6 min | August 28, 2023 ###### Creating a Sandbox in your K8s Cluster with a Local Workload ](https://www.signadot.com/videos/creating-a-sandbox-in-your-k8s-cluster-with-a-local-workload/) [*Image: Does context propagation cover and work with protocols like HTTP and GRPC?*](https://www.signadot.com/videos/does-context-propagation-cover-and-work-with-protocols-like-http-and-grpc/) [ 1 min | August 28, 2023 ###### Does context propagation cover and work with protocols like HTTP and GRPC? ](https://www.signadot.com/videos/does-context-propagation-cover-and-work-with-protocols-like-http-and-grpc/) [*Image: Feature Previews using Sandboxes*](https://www.signadot.com/videos/feature-previews-using-sandboxes/) [ 10 min | August 28, 2023 ###### Feature Previews using Sandboxes ](https://www.signadot.com/videos/feature-previews-using-sandboxes/) [*Image: How do Sandboxes work*](https://www.signadot.com/videos/how-do-sandboxes-work/) [ 5 min | August 28, 2023 ###### How do Sandboxes work ](https://www.signadot.com/videos/how-do-sandboxes-work/) [*Image: How do you realize slice-based environments with asynchronous message queues?*](https://www.signadot.com/videos/how-do-you-realize-slice-based-environments-with-asynchronous-message-queues/) [ 4 min | August 28, 2023 ###### How do you realize slice-based environments with asynchronous message queues? ](https://www.signadot.com/videos/how-do-you-realize-slice-based-environments-with-asynchronous-message-queues/) [*Image: How to implement slice-based environments in Kubernetes*](https://www.signadot.com/videos/how-to-implement-slice-based-environments-in-kubernetes/) [ 16 min | August 28, 2023 ###### How to implement slice-based environments in Kubernetes ](https://www.signadot.com/videos/how-to-implement-slice-based-environments-in-kubernetes/) [ *Image: Rapid microservices development with Signadot* ##### Rapid microservices development with Signadot While developing microservices locally is possible, running and testing them in a production-like Kubernetes environment is complex. A typical development workflow while developing service in Kubernetes can significantly slow you down - from building a Docker image, pushing it, restarting the deployments, and testing the changes in a shared cluster. And all that, assuming you manage to keep the shared cluster up to date! In this article, I'll look at a tool called Signadot. Signadot introduces a concept of sandboxes that allow you to considerably shorten your developer workflow and go from minutes to mere seconds! The sandbox concept will enable you to build and run a service locally using the upstream and downstream dependencies inside a shared cluster. Peter Jausovec October 31, 2024 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/rapid-microservices-development-with-signadot/) [ *Image: Scaling developer testing for microservices in Kubernetes* ##### Scaling developer testing for microservices in Kubernetes Join Anirudh Ramanathan, CTO at Signadot, in our latest webinar for a groundbreaking approach to microservice testing. Learn how to scale tests in Kubernetes using a shared staging environment and gain practical insights for effective integration testing. Anirudh Ramanathan March 1, 2024 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/scaling-developer-testing-for-microservices-in-kubernetes/) [ *Image: Rapid microservices development with Kubernetes and Signadot* ##### Rapid microservices development with Kubernetes and Signadot Join Peter Jausovec as he delves into his journey with microservices development in Kubernetes, highlighting the pivotal role of Signadot. From the innovative 'sandboxes' concept to the seamless service mesh integration, this webinar offers a comprehensive look at the advantages of using Signadot Peter Jausovec October 23, 2023 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/rapid-microservices-development-with-kubernetes-and-signadot/) [ *Image: Leveraging a Service Mesh to Scale Developer Environments : Signadot and CNCF* ##### Leveraging a Service Mesh to Scale Developer Environments : Signadot and CNCF Unlock the Power of Service Mesh: Simplify Dev Environment Management with Istio's Request Isolation - Join Anirudh on a journey to streamline development environments, reduce costs, and accelerate testing in the age of microservices and cloud-native applications Anirudh Ramanathan September 21, 2023 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/leveraging-a-service-mesh-to-scale-developer-environments-signadot-and-cncf/) [ *Image: DevOps Toolkit Webinar: Mastering Local and Ephemeral Development with Kubernetes* ##### DevOps Toolkit Webinar: Mastering Local and Ephemeral Development with Kubernetes See Viktor taking Signadot for a spin for local development and PR previews of microservices! Viktor Farcic September 4, 2023 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/devops-toolkit-mastering-local-and-ephemeral-development-with-kubernetes/) [ *Image: With Codefresh: Is the developer experience around microservices lagging?* ##### With Codefresh: Is the developer experience around microservices lagging? Explore the challenges of using feature flagging for testing in shared staging environments and discover how tools like Signadot's ephemeral "Sandboxes" can offer rapid, isolated testing without these issues. Nica Mellifera August 3, 2023 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/with-codefresh-is-the-developer-experience-around-microservices-lagging/) [ *Image: How Sandboxes Within Your Kubernetes Clusters Can Help Improve Developer Testing* ##### How Sandboxes Within Your Kubernetes Clusters Can Help Improve Developer Testing In this episode, CEO and Co-founder at Signadot, Arjun Iyer joins DevOps Paradox hosts Darin Pope and Viktor Farcic to speak about how sandboxes within your Kubernetes clusters can help with your testing problem without breaking the bank. Arjun Iyer June 21, 2023 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/simplify-microservice-development-with-signadot-devops-paradox/) [ *Image: DevSec For Scale Podcast - Shift-Left Testing For Microservices* ##### DevSec For Scale Podcast - Shift-Left Testing For Microservices In this engaging episode of the DevSec for Scale Podcast, we discuss how testing needs to shift left, particularly as development environments evolve with the latest in infrastructure orchestration and application security Arjun Iyer September 28, 2022 Read more *Image: arrow icon* ](https://www.signadot.com/webinar-and-podcast/devsec-for-scale-podcast-shift-left-testing-for-microservices/) --- # Company ## About Us Source: https://www.signadot.com/about-us/ Summary: Signadot's mission, team, and company information. ### Empowering developers with the freedom to be creative when building software at scale Developing complex applications does not need to be complex. We believe that the process of developing software must become significantly simpler than it is today for scaling teams and the impact that they have. Our team has first-hand experience and empathy from having experienced the challenges of developing software at scale. We founded Signadot to equip developers with superpowers, strike down complexity, and enable creative and collaborative problem solving for building the cloud-native applications of the future. #### Our mission & values *Image: teamwork icon* Teamwork We genuinely care about and respect our team members. We realize we win as a team and have fun along the way! *Image: think big icon* Think Big We love to think big and outside the box. We foster an environment where ideas are freely shared and discussed. *Image: bias towards action icon* Bias towards action We are biased towards trying things and iterating fast. As a young startup we seek to accelerate learning. #### Globally connected, locally empowered We're proud of our fully distributed team that spans continents, time zones, and cultures. At Signadot, we don't just adapt to remote work—we thrive in it. We've deliberately built a borderless company that seeks out exceptional talent wherever they call home. Our collaborative culture bridges physical distances through open communication, psychological safety, and genuine human connection. We've found that great ideas don't require shared office space—just shared purpose and mutual respect. Every team member brings their unique perspective and local context, creating a richer problem-solving environment as we tackle complex challenges for developers worldwide. #### Our investors Supported by the best in the industry: *Image: Redpoint Ventures logo**Image: Y Combinator logo* *Image: Jason Warner* Jason Warner Former CTO GitHub *Image: Adam Gross* Adam Gross Former CEO Heroku *Image: Timothy Chen* Timothy Chen Managing Partner Essence VC *Image: Chris Golda* Chris Golda Founding Partner Rogue Capital *Image: Allison Pickens* Allison Pickens General Partner The New Normal Fund *Image: John Kodumal* John Kodumal CTO / Co-founder LaunchDarkly *Image: Joseph Abebe* Joseph Abebe Former Head of Finance Slack *Image: Martin Gontovnikas* Martin Gontovnikas Co-founder HyperGrowth Partners *Image: Sebastien Pahl* Sebastien Pahl Co-founder Docker #### Media and press [ *Image: DevOps.com* Signadot Unveils Kubernetes-Native Developer Platform to Scale Agentic Development February 19, 2026 ](https://devops.com/signadot-unveils-kubernetes-native-developer-platform-to-scale-agentic-development/)[ *Image: Techstrong TV* Why Code Validation Is the Next Frontier March 31, 2026 ](https://techstrong.tv/videos/interviews/why-code-validation-is-the-next-frontier)[ *Image: TechCrunch logo* Signadot promises developers faster feedback loops February 23, 2022 ](https://techcrunch.com/2022/02/23/signadot-promises-developers-faster-feedback-loops/)[ *Image: PR Newswire logo* Y Combinator Alum Signadot raises $4M led by Redpoint Ventures to Reimagine Microservices Testing on Kubernetes February 23, 2022 ](https://www.prnewswire.com/news-releases/y-combinator-alum-signadot-raises-4m-led-by-redpoint-ventures-to-reimagine-microservices-testing-on-kubernetes-301488164.html)[ *Image: Tomasz Tunguz logo* The Next Key Innovation in the Shift-Left Movement February 25, 2022 ](https://tomtunguz.com/investing-in-signadot/) #### Take Signadot for a whirl Learn more about how to scale pre-merge testing with microservices [ Get started free *Image: arrow right white color*](https://www.signadot.com/signup/)[ Get a demo *Image: arrow right white color*](https://www.signadot.com/schedule-a-call/) --- ## Schedule a Call Source: https://www.signadot.com/schedule-a-call/ Summary: Book a demo or consultation with the Signadot team. ### Turn AI-generated code into shipped software See how engineering teams keep up with agent-speed development, without the babysitting, the production incidents, or the runaway infrastructure cost. Reclaim developer time Agents validate their own changes and keep iterating on their own, so your engineers stop babysitting coding agents. Ship with fewer incidents Shift-left validation that scales for the agentic era catches breaking changes before they reach production. Cut infrastructure cost Isolate only what each change touches instead of duplicating full environments for every test. " Signadot for this (preview environments) use case fit what we were trying to do better than anything else. It was a more mature solution than the other stuff that we were looking at. And the return on the investment was obvious... just in infrastructure costs, it saves us about $2 million annually." *Image: Phil Burrows* Phil Burrows Head of Platform Engineering at Brex Not ready for a call? You can [start free in minutes](https://www.signadot.com/signup/) instead. Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Testimonials "On the margin, with the Signadot approach, 99.8% of the isolated environment's infrastructure costs look wasteful. That percentage looks like an exaggeration, but it's really not." *Image: Connor Braa* Connor Braa Software Engineering Manager at Brex " Staging used to break, and it used to affect everyone else on the, who were using the downstream service or upstream service, including the QA and front end backend people. Now (with Signadot) we just need to maintain single pull request. And for authors also, they just need to make one pull request and they can add future changes in the same thing." *Image: Mahesh Uligade* Mahesh Uligade Technical Lead at Sharechat "We are biased toward action. We move fast and ship new products quickly, but we also prioritize platform reliability. Automated testing and tooling are key to catching issues early." *Image: Tyler Marien* Tyler Marien Senior Software Developer at Wealthsimple #### Frequently asked questions How is Signadot different from other solutions? Unlike traditional ephemeral environments that duplicate entire infrastructure stacks, Signadot uses a unique approach called Sandboxes that provides isolation at the request/application layer. This means you can run multiple isolated test environments in a single Kubernetes cluster without duplicating resources. Environments spin up in seconds, is more cost-effective and scalable. What capabilities does Signadot offer? Signadot provides an environment layer and a validation layer on top of it: \- Sandboxes: lightweight, isolated environments that run only the service you changed against a shared baseline cluster \- Local Testing: develop and test microservices on your local machine while connecting to real dependencies in your Kubernetes cluster \- Preview Environments: preview every code change from web and mobile frontends \- Jobs: run your existing test suites against isolated Sandboxes for every PR \- SmartTests: AI-powered contract testing that detects API breaking changes automatically \- Plans: declarative validation workflows that agents and pipelines can run end to end What are Sandboxes? Sandboxes are lightweight, isolated testing environments that allow you to test changes without interfering with other developers or the base environment. Unlike traditional approaches that duplicate entire infrastructure, Sandboxes only create the specific components you're modifying and use request routing to provide isolation. Where do Sandboxes run? Sandboxes run inside your existing Kubernetes clusters. Signadot installs as an operator in your Kubernetes environment, so all workloads, data, and testing happen within your infrastructure. The Signadot control plane orchestrates the creation and management of these Sandboxes, but your code and data never leave your environment. How much effort is it to get started? Getting started with Signadot typically takes less than 15 mins. The minimal setup involves just two steps: 1\. Installing the Signadot operator in your Kubernetes cluster. 2\. Using our CLI to create Sandboxes and run tests. How does Signadot integrate with CI/CD systems? Signadot integrates seamlessly with all major CI/CD systems through our CLI, which can be used as a step in your pipeline. We have examples of integrations for GitHub Actions, GitLab CI, Jenkins, and BitBucket in our [documentation](https://www.signadot.com/docs/guides/integrate-ci). --- ## Sign Up Source: https://www.signadot.com/signup/ Summary: Create a free Signadot account. ### Validate code as fast as agents write it Sign up free and watch your first change run against real microservices in minutes. Free, no credit card No cluster of your own ~5 minutes Local dev with your coding agent Claude Code, Cursor, and Codex plug in through our MCP server and CLI. A sandbox for every pull request Ephemeral, production-like, spun up automatically per PR. First sandbox in ~5 minutes On our playground cluster. [See the quickstarts](https://www.signadot.com/docs/overview). “The strategy using routing keys is much lighter, and we are able to provide an isolated environment, even with isolated databases, per PR quite fast.” *Image: Marcus Tavares* Marcus Tavares Staff Software Engineer, Bitso 250+ engineers · **83%** lower change failure rate [Read the story →](https://www.signadot.com/case-studies/how-bitso-scaled-delivery-with-coding-agents/) Trusted by engineering teams worldwide *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* *Image: Brex logo* *Image: Miro logo* *Image: Wealthsimple logo* *Image: Bitso logo* *Image: Qlik logo* *Image: SoFi logo* *Image: Earnest logo* *Image: ShareChat logo* *Image: InfoTrack logo* *Image: Quizlet logo* *Image: OnBoard logo* *Image: Calendly logo* *Image: Lightspeed logo* *Image: Storyblocks logo* *Image: OutSystems logo* *Image: Luxury Presence logo* *Image: Posh AI logo* *Image: Juniper Square logo* *Image: Leadr logo* *Image: Nox Health logo* *Image: Favor Delivery logo* *Image: MPL logo* *Image: Codefresh logo* *Image: Laurel logo* #### Frequently asked questions Is Signadot free to start? Yes. The free tier is open to every developer, with no credit card required, so you can try sandboxes and the full validation workflow before you ever talk to us. Do I need my own Kubernetes cluster to try it? No. You can start on our hosted playground cluster in a few minutes. When you are ready, connect your own cluster by installing the Signadot operator. How do I connect my coding agent? Point Claude Code, Cursor, or Codex at our MCP server, or use the Signadot CLI. The agent can then spin up a sandbox, run its change against real dependencies, and read the results on its own. How quickly can I see it working? About five minutes. Follow either quickstart to spin up your first sandbox and watch a change route to your version against real microservices. Where does my code run, and is it secure? Sandboxes run inside your own Kubernetes cluster. The Signadot operator installs in your environment, so your code and data never leave your infrastructure. --- # Documentation and External Resources These pages are part of the Signadot index but are served by the docs site or GitHub; fetch them directly: - [MCP Server](https://www.signadot.com/docs/integrations/mcp): Signadot's Model Context Protocol server, bundled with the Signadot CLI. Exposes tools for creating sandboxes and route groups and running validations, so MCP-compatible agents can test code changes against real dependencies. - [MCP Setup: Claude Code](https://www.signadot.com/docs/integrations/mcp/claude-code): Configure the Signadot MCP server in Claude Code. - [MCP Setup: Cursor](https://www.signadot.com/docs/integrations/mcp/cursor): Configure the Signadot MCP server in Cursor. - [MCP Setup: VS Code](https://www.signadot.com/docs/integrations/mcp/vscode): Configure the Signadot MCP server in VS Code. - [MCP Setup: Other Clients](https://www.signadot.com/docs/integrations/mcp/other-clients): Configure the Signadot MCP server in any MCP-compatible client. - [Coding Agents Overview](https://www.signadot.com/docs/integrations/coding-agents): How coding agents use Signadot to provision environments and validate their own changes. - [Agent Skills](https://www.signadot.com/docs/integrations/coding-agents/agent-skills): Installable skills (signadot-validate, signadot-plan) that teach coding agents Signadot validation workflows. Install with `npx skills add signadot/agent-skills`. - [Tutorial: Closed-Loop Validation with Claude Code](https://www.signadot.com/docs/tutorials/closed-loop-microservices-validation-claude-code): End-to-end tutorial where Claude Code implements a change and validates it in a Signadot sandbox. - [Tutorial: Closed-Loop Verification with Cursor](https://www.signadot.com/docs/tutorials/closed-loop-verification-cursor): End-to-end tutorial where Cursor validates changes against real services in a sandbox. - [Tutorial: Autonomous Validation with Codex](https://www.signadot.com/docs/tutorials/autonomous-closed-loop-codex): Autonomous closed-loop validation of code changes with OpenAI Codex. - [GitHub: signadot](https://github.com/signadot): Signadot's open source repositories, including the CLI, agent skills, and validation actions. - [GitHub: agent-skills](https://github.com/signadot/agent-skills): Source repository for the Signadot agent skills. - [GitHub: actions](https://github.com/signadot/actions): Community-extensible catalog of validation actions used by Signadot Plans. - [Docs llms.txt](https://www.signadot.com/docs/llms.txt): Index of the full technical documentation in llms.txt format, with markdown exports of every docs page. - [Docs Overview](https://www.signadot.com/docs/overview): Getting started guide and platform overview. - [Installation](https://www.signadot.com/docs/getting-started/installation): Install the Signadot Operator in your cluster and the Signadot CLI on your machine. - [Quickstart: First Sandbox](https://www.signadot.com/docs/tutorials/quickstart/first-sandbox): Create your first sandbox and test a change against real dependencies. - [Quickstart: Plan-Based Validation](https://www.signadot.com/docs/tutorials/quickstart/plan-based-validation): Run your first plan-based validation workflow. - [Sandbox Concepts](https://www.signadot.com/docs/concepts/sandbox): How sandboxes work. Lightweight isolated environments that virtualize your Kubernetes cluster by routing traffic to only the changed services. - [Smart Tests and Jobs Concepts](https://www.signadot.com/docs/concepts/smart-tests-and-jobs): How Smart Tests and Jobs execute test workloads against sandboxes, including AI-assisted diff analysis. - [Set Up Local Testing](https://www.signadot.com/docs/guides/use-cases/set-up-local-testing): Guide for connecting local development environments to your Kubernetes cluster via sandboxes. - [Set Up PR Sandboxes](https://www.signadot.com/docs/guides/set-up-pr-sandboxes): Guide for automating preview environment creation on every pull request. - [Run Automated Tests](https://www.signadot.com/docs/guides/use-cases/run-automated-tests): Guide for executing test frameworks (Playwright, Cypress, K6) against isolated sandboxes. - [Tutorial: Test Temporal Workers in Kubernetes with Sandboxes](https://www.signadot.com/docs/tutorials/testing-temporal-workers): Route Temporal workflow tasks to a sandboxed worker on a shared task queue, with Python, TypeScript, Go, and Java workers. - [CI Integration](https://www.signadot.com/docs/guides/integrate-ci): Integration guides for GitHub Actions, GitLab CI, Jenkins, and BitBucket pipelines. - [CLI Reference](https://www.signadot.com/docs/reference/cli/overview): Command reference for the Signadot CLI. - [REST API Reference](https://www.signadot.com/docs/api): Full REST API specification for the Signadot control plane. - [Release Notes](https://www.signadot.com/docs/release-notes): Changelog of Signadot platform, operator, and CLI releases.