PR Environments
Kubernetes preview environments for every pull request.
Give every pull request its own PR environment on the Kubernetes cluster you already run, with your real databases, message queues and services behind it. Signadot duplicates only what each change needs, so thousands of pull request environments run side by side for your developers and coding agents.
- Real data and dependencies in every PR environment
- Thousands of previews on one cluster, each in seconds
Trusted by engineering teams worldwide
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. The complete guide to preview environments compares every approach.
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.
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.
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 duplicates only what a change needs, usually just the services it touches, and routes requests and messages for everything else to the shared, real dependencies around them. Each PR runs against a complete, production-like system, without copying your stack.
-
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.
-
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.
-
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.
-
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.
Real data and dependencies
Every PR environment runs against your real stack.
A preview is only as useful as what sits behind it. Signadot PR environments use the databases, queues and workflow engines already running on your cluster, and isolate only what a change writes or consumes.
-
Databases
Share the real database with isolated writes, or give a PR its own database or a Neon branch through a resource plugin.
Read the docs -
Message queues
Kafka, RabbitMQ, SQS, Pub/Sub and NATS work through message routing, so only the PR's consumers process its messages.
Read the docs -
Temporal workflows
Stable and PR workers share one task queue, and exactly one worker version processes each task.
Read the docs -
Cloud resources
Resource plugins create managed databases, queues and buckets for a PR with Terraform, Helm or a script, and delete them with it.
Read the docs
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.
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
Thousands of previews.
On the cluster you already run.
Signadot virtualizes preview environments onto your existing Kubernetes cluster. Each one duplicates only what a PR needs, usually just the services it 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 what the change needs deploys. 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.
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.
Marcus TavaresStaff Software Engineer 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.
Testimonials
Hear from our customers
$2M saved annually
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 BurrowsHead of Platform Engineering 
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.
Jony JeyaratnamHead of Engineering 
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.
Tyler MarienSenior Software Developer 
82% lower change failure rate
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 KleinLead Infrastructure Engineer 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, and the hosted control plane receives only resource metadata, never your code or data. Reach a preview by preview URL, 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.
Guides for the major CI systems and Argo CD, and the Signadot CLI for any other pipeline. Add a few lines to your pipeline and your team has a pull request environment for every PR. Running GitOps? ArgoCD preview environments compares the ApplicationSet pattern with routed previews. Routing works through the built-in DevMesh or your existing service mesh.
-
GitHub Actions
A preview per PR from your workflow. The Signadot GitHub App posts it on the PR and deletes it when the PR closes.
-
GitLab CI
A preview per merge request from your pipeline, cleaned up by a time-to-live.
-
Jenkins
CLI calls in your existing jobs create and delete a preview for each PR.
-
Bitbucket Pipelines
A preview per pull request from your pipeline, cleaned up by a time-to-live.
-
Argo CD
An ApplicationSet creates a preview for each PR through hook Jobs, runs your tests in it and deletes it when the PR closes.
-
Istio and Linkerd
Routing works through the built-in DevMesh sidecars or the service mesh you already run.
Preview Environments FAQ
What is a PR environment on Kubernetes?
A PR environment, or pull request environment, is a preview environment created automatically for one pull request so the change can be reviewed and tested before it merges. With Signadot, each one is an ephemeral environment that duplicates only what the PR needs on the Kubernetes cluster you already run. People and coding agents preview the change through your web and mobile apps, and the same environment runs your automated tests. It spins up in seconds and is deleted when the PR closes.
How does Signadot create a preview environment for each pull request?
When a PR opens, your CI creates an ephemeral environment from a template stored in the repo. Signadot duplicates only the changed workload on your existing Kubernetes cluster and gives it a routing key. Requests and messages carrying that key reach the changed service, and everything else uses the shared environment with its 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 when a PR opens. On GitHub, the Signadot GitHub App posts the preview details on the PR and deletes the environment when the PR merges or closes. Guides cover GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines and Argo CD, where an ApplicationSet creates a sandbox for each PR through hook Jobs. Any other CI can call the Signadot CLI, and a time-to-live on every sandbox makes sure 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.
Do PR environments work with databases, message queues and Temporal?
Yes. A PR environment shares your real databases by default, and a resource plugin can give a PR its own database or a branch of one, such as a Neon branch. Kafka, RabbitMQ, SQS, Pub/Sub and NATS work through message routing, so only the PR's consumers process its messages. Temporal workers share a task queue, and exactly one worker version processes each task. Resource plugins also create cloud resources a PR needs and delete them with it.
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.