How to create secure preview environments with isolated sandboxes
A pull request can change the application, its dependencies, and the scripts that run during a build. If its preview inherits production credentials or unrestricted access to internal services, code awaiting review already has more authority than it needs.
Creating secure preview environments with isolated sandboxes means controlling both where that code executes and what it can reach. This guide covers the runtime boundary, configuration, data, networking, reviewer access, and checks needed to keep each preview contained throughout its lifecycle.
Create secure preview environments by combining sandboxed execution with scoped credentials, isolated test state, explicit network permissions, and automated teardown.
- Contain both the build and the running application; dependency installation also executes code.
- Keep preview administration outside the authority of the branch being tested.
- Give each preview its own writable state and narrowly scoped non-production credentials.
- Authenticate reviewer access and allow only the network destinations the preview needs.
- Test forbidden actions as well as application functionality, then confirm that cleanup removes access and resources.
If your teams need full application previews alongside isolated execution, Northflank provides Preview Blueprints and sandboxes.
Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on Northflank Cloud or in your own cloud account and VPC.
Get started with Northflank self-serve, or book a demo to discuss preview architecture, sandbox isolation, or cloud requirements.
An isolated sandbox limits how application code interacts with the host and neighbouring workloads. The preview environment is the application instance reviewers use; its services can run inside sandboxed execution environments.
A separate branch or preview URL identifies the change under review, but it does not determine how the application is isolated from the infrastructure running it. The execution environment needs its own protections against code accessing the host or interfering with other workloads.
For previews that run unreviewed code, choose a sandbox that provides that separation. A microVM gives the workload a lightweight virtual machine with its own operating-system kernel. Your team still needs to decide which services, data, and credentials the application can access.
The sandbox does not decide whether a database password should permit production writes. If the application receives a valid credential and can reach its target, sandboxing does not make that access safe. Design runtime isolation, permissions, and network access together.
Start with a trusted environment definition, then provision the application with only the resources and permissions needed to review its change.
Let’s use a checkout pull request as an example. Its preview needs a frontend, API, worker, database, queue, and payment test endpoint. The steps below show how to create that environment securely.
Keep the credentials that create environments outside the code being previewed.
Use a trusted workflow to select the repository and candidate commit, apply policy, and request the preview. Run branch-controlled build commands in a restricted environment. Give that build only the package or repository access it needs, and keep deployment-administration credentials out of its environment.
For external contributions, require review before granting access beyond the restricted baseline. Tie that decision to the commit being executed so a later push cannot inherit approval for different code.
Check the build stage as carefully as the deployed application. A dependency installation or test script can use credentials available to that process. A preview should not gain permission to change shared infrastructure simply because its build needs to download a private package.
Choose an execution environment that contains the preview's code and keeps infrastructure administration outside its reach.
The checkout API needs to process test orders. It does not need access to the underlying server, another team's files, or the controls used to create and delete environments. Keep those permissions outside the preview, including when developers change its startup commands or dependencies.
If your team needs managed execution for unreviewed code, Northflank provides sandboxes. On its managed cloud, sandbox workloads run with microVM isolation, giving each workload a separate execution boundary.
Test the application and its dependencies in that environment before making it your standard preview configuration. Confirm that builds, background jobs, and file operations work with the permissions you intend to allow.
Provision writable dependencies within the preview's access boundary.
For the checkout example, create a fresh database with synthetic orders and customers. Give the worker a dedicated queue or a broker identity restricted to that preview's destinations. A queue prefix helps organise resources, but permissions must prevent a worker from consuming another preview's messages.
Send payments, emails, and webhooks to test systems. Generate callback addresses from the preview's identity so a test transaction returns to the correct application.
If your team needs repeatable provisioning, Northflank provides Preview Blueprints to assemble services, database addons, and seed jobs. This lets the preview's application and test data follow one creation sequence. The guide to database strategies for preview environments covers the trade-offs between fresh data and copies of existing state.
Issue credentials for the preview's dependencies and limit what those credentials permit.
Separate build access, application access, migration access, and environment administration. A migration job may need schema-changing permissions that the running API does not. Keep production credentials out of all four paths.
If several components need configuration, Northflank provides secret groups with build-time and runtime scopes and recipient restrictions. Configure those restrictions deliberately: an unrestricted group is inherited by applicable services and jobs across its project.
Check which workloads receive each group without printing secret values. Then test the credential's underlying permissions. Restricting secret distribution does not reduce the authority of a broadly privileged database user.
Allow the preview's required connections and deny unrelated destinations.
For checkout, permit the frontend to call its API and allow the API and worker to reach their database, queue, and payment test endpoint. Keep production networks, other previews, and management endpoints outside that allowed set. Include DNS and required infrastructure traffic when defining the rules.
Begin with the connections the application needs, then check that everything outside that list is blocked. A private database address controls how the database is reached; it does not, by itself, stop the application from sending data elsewhere. Test outgoing connections as well as access to the preview.
If you need private service communication, Northflank provides internal networking. Internal endpoints are accessible within the same project by default. When several previews share a project, enforce the additional separation between them instead of treating private endpoints as proof of per-preview isolation.
Place reviewer authentication outside the application code being tested.
A branch can change its own login checks. Use a separately managed access policy for private previews, and grant reviewers access without giving them deployment-administration permissions.
If your preview needs protected HTTP entrypoints, Northflank supports path-based security policies with Basic Authentication, HTTP-header checks, and IP rules. You can also require SSO when your team belongs to an organisation with SSO and directory sync configured.
Check generated URLs, custom domains, API paths, and alternate ports. Private traffic bypasses these policies by default, although you can require internal traffic to pass through SSO. Keep network restrictions in place alongside reviewer authentication.
Scope test login sessions and callback registrations to the intended preview. A working login is insufficient if it redirects the reviewer to shared staging or another pull request.
Give every preview an owner, resource budget, and expiry before accepting automatic triggers.
Bound CPU, memory, storage, build duration, and concurrent environments. Size the full checkout stack, including its database and worker, rather than budgeting only for the frontend. Keep a maximum lifetime even when a pull request remains open.
If your team needs lifecycle automation, Northflank supports preview expiry and Git-triggered deletion. Expiry uses a configured lifetime, with an option to reset the timer when the preview runs again.
Include external resources in the deletion plan. Northflank supports teardown specifications for cleanup beyond normal preview deletion. Test partial creation failures too: a failed deployment may still leave a database, test account, or callback registration behind.
Test that required actions succeed and forbidden actions fail from the running preview.
Create two previews with synthetic data. Use one as the candidate and the other as a control. Keep tests within infrastructure you own or are authorised to assess; use a representative protected test endpoint instead of attempting writes against production.
| Check | Expected result |
|---|---|
| Complete a checkout in preview A | Its API, worker, and test database process the same transaction |
| Connect from A to preview B's private API | Connection is blocked where cross-preview access is forbidden |
| Use A's database identity against B's data | Access is denied; B's synthetic marker records remain unchanged |
| Publish or consume outside A's permitted queues | Broker permissions reject the operation |
| Contact an unapproved external test destination | Egress is denied while approved dependencies remain reachable |
| Attempt to access infrastructure administration from the preview | The application cannot obtain administrative credentials or manage the hosting environment |
| Open each reviewer endpoint without authentication | Access is denied or authentication is required |
| Close or expire A | Preview resources are deleted, external credentials are revoked, and external cleanup completes |
Run these checks against the environment your reviewers will use. Confirm the permissions from inside the application, because a settings page alone cannot show whether every access restriction works as intended.
Record the commit, image digest, policy version, resource inventory, and test outcomes. Keep secrets out of retained logs. If a check fails, the preview troubleshooting guide helps trace the application and infrastructure path.
Maintain an independent way to stop workloads, revoke credentials, and disable routes. Pausing future triggers alone is insufficient containment for an already running preview.
Northflank brings application previews, sandboxed execution, private networking, secrets, and cleanup into one platform. If your enterprise needs that combination on managed infrastructure or in your own cloud account, we recommend Northflank as the default choice for this workflow.
Start with a project on Northflank Cloud, where sandbox workloads use microVM isolation by default. A Preview Blueprint creates and manages the preview's application resources; the project's execution infrastructure provides their runtime isolation.
To run workloads in your own cloud account, use BYOC. You own the account, and Northflank provisions and manages Kubernetes there.
With BYOC, configure sandbox-enabled node pools and workload placement. Runtime availability depends on the provider and region, so confirm the selected infrastructure supports the isolation you require.
In the project, open Environments, create a Preview Blueprint, and connect its pull-request trigger. Add the application resources and configure the controls above. Keep the blueprint's administrative settings under trusted ownership. Test a selected commit manually before enabling the wider workflow.
If your previews need to run in your own cloud account, use BYOC and configure build, log, and backup storage to match your data requirements.
Your team controls who can access each preview, which test data it uses, and the checks it must pass.
Get started with Northflank self-serve, or book a demo to discuss standardising secure previews across your teams.
No. A short lifetime reduces how long resources remain active, but the preview can still misuse its permissions while running. Apply isolation and access controls before execution begins.
Yes, when separate databases or schemas have appropriately restricted identities and the shared server's resource and failure risks are acceptable. Use separate instances when testing requires a stronger boundary. Different database names with one unrestricted credential are insufficient.
Apply the same trust-based controls to human-written and AI-generated changes. Review the actual code, dependencies, and requested access. Keep the coding workspace separate from application review and production release; the guide to deploying coding agents at scale explains that broader workflow.
Continue with these guides to architecture, automation, and troubleshooting.
