FAQ
How does Signadot differ from the traditional approach to ephemeral environments?
The traditional approach to ephemeral environments, also known as infrastructure-level isolation, involves creating a complete, isolated copy of the entire application stack for each new feature, pull request or developer. This includes all microservices, databases, and other dependencies.
Signadot, on the other hand, uses a more modern approach called request-level isolation. Instead of duplicating the entire infrastructure, Signadot creates lightweight, isolated "sandboxes" within a shared Kubernetes cluster that replicate only the services and resources that have changed. When a developer needs to test a change to a specific microservice, Signadot intelligently routes test-specific traffic to a forked version of that service.
What are the benefits of Signadot's approach?
A: Signadot's request-level isolation offers several key benefits over the traditional full-stack duplication model:
⚡️ Speed and Performance: Sandboxes are provisioned almost instantly because you only deploy the components that have changed. This eliminates the long wait times associated with spinning up a full-stack environment.
💰 Resource Efficiency and Cost: By sharing the bulk of the microservices and infrastructure, Signadot drastically reduces the compute resources and costs required for testing, as you're no longer duplicating the entire stack for every developer's test.
📈 Scalability: The traditional approach becomes complex and difficult to manage at scale. Signadot's lightweight model is designed for scalability, allowing hundreds of isolated sandboxes to coexist efficiently within a single cluster.
🧑💻 Improved Developer Experience: Developers get a faster, more streamlined workflow. They receive immediate feedback on their changes, which removes bottlenecks and allows them to iterate more quickly and merge code with greater confidence.
Where does Signadot fit into the development lifecycle?
Signadot enables shift-left testing by bringing production-like environments into earlier stages of development:
Local Development: Developers can test their service locally while connecting to real dependencies in the cluster using Sandboxes. No need to run the entire stack on your laptop or rely on mocks.
Pull Request Phase: Automatically create preview environments and run automated tests for every PR. This catches integration issues before code merges, when they're cheapest to fix.
Pre-merge Testing: Run API tests, end-to-end tests, and contract validation using SmartTests. Teams can verify changes work with real data and dependencies without disrupting shared staging environments.
Feature Collaboration: Multiple teams can preview and test features across different PRs using RouteGroups, enabling parallel development without environment conflicts.
Release Validation: Use the same Sandbox infrastructure for final acceptance testing and stakeholder sign-offs before production deployment.
Signadot moves comprehensive testing left in the development cycle - from post-merge to pre-merge. This reduces the feedback loop from hours or days to minutes, while maintaining the fidelity of testing against real services and data.
Does Signadot offer a fully hosted solution?
No, Signadot uses a hybrid architecture where the control plane is hosted by us, but sandboxes and tests run within your Kubernetes clusters.
Here's how it works:
Hosted Control Plane: The Signadot dashboard, API, and management layer run in our cloud infrastructure. This handles sandbox orchestration, test result aggregation, and user interfaces.
Your Infrastructure: The actual sandboxes, test execution, and workloads run inside your Kubernetes clusters using the Signadot operator. Your code and data never leave your environment.
The operator connects securely to our control plane for coordination, but all the heavy lifting happens in your environment. This gives you the convenience of a managed service while maintaining security and performance benefits of running tests where your services live.
How does Signadot implement data isolation in sandboxes?
One of the common questions we encounter with our sandbox testing solution is around data isolation, particularly the risk of data corruption when multiple teams use a shared database. Here’s how we address that with a flexible approach we call "tunable isolation."
Default Mode: Shared Database with Partitioned Data
By default, all sandbox environments connect to the same shared database. This works well for most scenarios, especially if tests are primarily read-only or if they use partitioned identifiers like an org ID or user ID. Isolating data at the domain level ensures that each test can create/delete its data within its partition, reducing cross-test interference. Ideally, tests should also clean up after themselves once completed.
Schema Change Scenarios
For scenarios that involve schema changes, we recommend two approaches:
- Local Database Setup: Developers can spin up a temporary database on their local workstations, allowing the sandbox service to connect locally. Signadot supports this model by routing cluster traffic to/from the local workstation, so it behaves like any other sandbox in the cluster.
- PR Workflow Integration: For a standardized setup, platform teams can create resource plugins to spin up a temporary, containerized database within the cluster or in the cloud. These plugins are scripts that run before and after the sandbox, managing temporary databases and ensuring clean resource tear-down after tests.
This tunable isolation model allows teams to balance convenience with isolation as needed, with the shared database as the default for ease, and temporary databases for cases requiring schema changes or higher isolation.
How do you handle message queue isolation in sandboxes?
Message queue isolation enables developers to independently test end-to-end application flows that involve shared message queues without impacting each other's tests. Signadot provides two primary approaches for implementing this isolation:
- Message-Level Routing: The most scalable and cost-effective approach is to enable message-level routing by propagating the routing key through message headers. Consumers can then selectively process messages based on these headers.
- Dynamic Queue Creation: Alternatively, you can create dedicated message queue topics or queues on demand using resource plugins. This approach connects sandboxed producers and consumers to newly created topics.
For detailed implementation examples and configuration guides, refer to our message queue isolation guide and tutorials for Kafka and Google Pub/Sub.
Is distributed tracing required to use Signadot?
No. You only need the ability to propagate request headers, typically implemented using OpenTelemetry libraries. This header propagation enables Signadot to route requests to the appropriate sandboxed services.
Does Signadot require header propagation?
It depends on your testing scenario:
Required for:
- Frontend previews where requests flow through multiple services before reaching your sandboxed service
- End-to-end tests that start from an entry point several services away from the sandboxed components
Not required for:
- SmartTests where you're testing sandboxed services directly via their APIs
- API tests that make requests directly to services in your sandbox
Most teams start by implementing header propagation in a few key services that are essential to their initial testing workflows. This lets you begin testing quickly while having the flexibility to expand header propagation to more services as your testing needs grow.
How can I test features that span multiple Pull Requests?
When testing changes across multiple PRs, you can combine routing to multiple sandboxes using RouteGroups. Each RouteGroup has its own routing key, allowing you to test request flows that interact with all sandboxes within the group. This enables testing of complex feature implementations that span multiple services and PRs.
What are the advantages of running automated tests as Signadot Jobs vs CI tools?
Running automated tests through Signadot Jobs offers several key benefits over traditional CI-based testing:
Security and Access: Jobs run within your Kubernetes cluster, with native access to internal services. This eliminates the need to expose internal endpoints for external testing.
Cost Optimization: Testing within your existing cloud environment can be more cost-effective than running tests in CI vendor environments, especially for high-volume testing.
Centralized Management: Signadot provides a unified platform for managing diverse test types - from API and integration tests to end-to-end, smoke, and performance tests.
Kubernetes-Native Scaling: Leverage Kubernetes' auto-scaling capabilities to run tests in parallel across your engineering organization, improving testing throughput and developer productivity.
How are Signadot SmartTests different from other contract testing solutions like Pact?
SmartTests eliminate the manual overhead of traditional contract testing by automatically detecting API changes without requiring explicit contract definitions.
While Pact requires writing and maintaining contract files plus specific assertions, SmartTests work by:
- Zero contract maintenance: You write simple HTTP calls in Starlark, and AI automatically detects meaningful API changes between baseline and sandbox versions
- Real environment testing: Tests run against actual services with real data, not mocks or stubs like Pact
- AI-powered relevance: Not all API changes matter - our models classify which differences are actually breaking changes vs. normal variance
The trade-off is that SmartTests are designed specifically for Kubernetes environments with Sandboxes, while Pact can run anywhere. SmartTests only support http protocol but support for gRPC and others are coming soon. For teams already on Kubernetes, SmartTests provide a much simpler path to catching integration issues without the maintenance burden of traditional contract testing.