How to control access to preview environments across enterprise teams
A preview may exist for only a few days, but the application behind its URL may expose an unreleased feature, customer-shaped test data, administrative screens, and access paths to internal services. As preview environments spread across enterprise teams, temporary infrastructure becomes a real identity, network, and data-access boundary.
Controlling that boundary means deciding who can create and change previews, who can open them, and what the running workloads can reach. A shared classification model keeps those decisions consistent without forcing every application through the same policy.
Control access to preview environments by governing three separate access planes: the platform control plane, the reviewer-facing application, and the dependencies available to the running workload.
- Classify each preview by contributor trust, application sensitivity, test-data class, and permitted external side effects.
- Use corporate identity, group-based roles, and scoped automation tokens to control who can create, change, inspect, and delete preview infrastructure.
- Avoid unauthenticated public exposure by default when previews contain internal applications or sensitive non-production data.
- Give preview workloads their own least-privilege secrets, service identities, network routes, and test-system accounts. Do not inject production credentials into pull-request code.
- Bind exceptional access and external resources to the pull-request lifecycle, then review platform audit events separately from application access logs.
If your platform team needs one access model across many applications, Northflank Preview Environments turn each pull request into a repeatable, isolated environment defined by a Preview Blueprint.
Northflank lets you scope platform actions with role-based access control, protect eligible service ports with organisation SSO, IP, or credential policies, restrict secrets to tagged preview resources, and trace platform changes through audit logs. The result is a common access policy that application teams can consume without owning separate authentication and environment automation.
Get started with Northflank self-serve, or book a demo to discuss preview architecture, identity, networking, compliance, or access requirements.
Preview environment access is difficult at enterprise scale because infrastructure permissions, reviewer access, and workload credentials cross teams but require different controls. Treating access as a single public-or-private URL setting secures only one part of the environment.
A developer may create a preview without changing its access policy, while a product manager may review it without seeing deployment configuration.
Internal engineers, contractors, and external pull requests have different trust levels. A public website and an administrative API also carry different risks.
The three access planes are the control plane for managing preview infrastructure, the reviewer plane for opening the application, and the dependency plane for governing what its workloads can reach.
| Access plane | Main question | Typical subjects | Primary controls |
|---|---|---|---|
| Control plane | Who can create, change, inspect, or delete the preview? | Developers, platform engineers, CI and security responders | SSO, RBAC, project scope, API tokens and trigger rules |
| Reviewer plane | Who can reach the deployed application? | Engineers, QA, product teams, customers and other reviewers | Private access, SSO groups, IP policies and basic authentication |
| Dependency plane | What can the running preview reach? | Services, jobs and migration processes | Workload identity, scoped secrets, network policy and data isolation |
Authorisation in one plane should not grant access in another. Platform membership does not permit someone to view every application's test data, and reviewers do not need infrastructure permissions.
Platform teams define infrastructure controls, security teams define identity and data policy, and application owners classify previews.
A preview's access policy should be determined by four factors: who supplied the change, what application it affects, which data it uses, and which external actions it can perform.
| Preview class | Example | Reviewer access | Workload access |
|---|---|---|---|
| Public | Static website change with synthetic content | Public URL may be acceptable | No private services or sensitive secrets |
| Internal | Employee application using fixtures | Corporate SSO group | Scoped non-production APIs and data |
| Restricted | Customer workflow using masked or customer-shaped data | Named directory groups | Isolated database and narrowly scoped service identities |
| High risk | Authentication, billing, infrastructure, or migration change | Named reviewers after required checks | Dedicated test systems, controlled egress, no production credentials |
This is a practical taxonomy, not an industry standard. Your enterprise can add residency, regulated data, internet egress, or changes to the preview definition.
Store the classification with the repository or preview definition so the environment controller selects the correct rules before a URL exists.
Platform administrators, preview-template maintainers, application contributors, read-only responders, and CI automation should each receive separate, least-privilege access to previews.
A workable role model distinguishes:
- Platform administrators who manage organisation identity and policy
- Preview-template maintainers who can change topology, networking, and lifecycle rules
- Application contributors who can create or inspect previews in their projects
- Reviewers and responders who need read-only visibility or logs
- Automation identities that can perform only the API actions required by CI
If your organisation needs these boundaries across several engineering groups, Northflank RBAC roles control UI and API operations and can be restricted to selected teams and projects. SSO and directory sync can provision organisation members from selected directory groups and automatically assign or remove roles based on group membership. These features require enablement for the organisation. Organisations can also require MFA, set a maximum login-session duration, and clear member sessions.
Treat automation as its own identity. Northflank API tokens inherit an RBAC role, can have an expiry, and can be revoked. Give a pull-request workflow only the API permissions and project scope needed to run or update previews, rather than an owner role covering unrelated projects.
Trigger policy is part of control-plane access. A trusted internal pull request may create a preview automatically, while an external or high-risk change waits for repository checks. Northflank Preview Blueprints support pull-request and path rules plus GitHub check-suite triggers, so creation can follow source-control policy.
Only the people and systems required to test the change should be able to open a preview URL. Public access should be an explicit choice for low-risk previews, not the default side effect of generating a URL.
Use private ports for service-to-service access and automated tests running inside the project. Engineers can reach private deployments and databases through authorised port forwarding or a connected private network. Use enterprise SSO when selected employee groups need browser access. IP allowlists can narrow access to known networks, while basic authentication provides a coarse temporary barrier.
Basic authentication lacks the lifecycle and individual attribution of corporate identity. A shared password can outlive a role change and represent several people. Use group-based SSO for internal applications and sensitive test data.
Northflank supports security policies on individual service ports, including organisation SSO groups, IP policies, and basic authentication. Path-based security policies can apply different access requirements to different paths on the same service port.
Northflank private networking and port forwarding let authorised users reach services and databases without public exposure. In a multi-service preview, expose the required frontend or gateway and keep databases, workers, and internal APIs private.
Preview workloads should access only the non-production data, services, and external systems required to test the change, using preview-scoped identities. Production access should be denied by default because protecting the URL does not contain code running inside the environment.
The dependency-plane policy should cover:
- Which secrets the preview receives at build time and runtime
- Which services, databases, queues, buckets, and cloud APIs it can reach
- Whether outbound internet access is required
- Which external test systems it may call
- How credentials and external resources are revoked or deleted
Pull-request code can read values injected into its process and send them elsewhere. Do not provide production credentials to an untrusted build and assume a hidden variable is safe. Use preview-specific accounts, narrow permissions, and controlled non-production data.
If application teams need reusable secret boundaries, Northflank secret groups can separate secret values from ordinary configuration, restrict which roles can see values, and limit inheritance to specific resources or tags. Preview environments receive a default preview tag, allowing preview-only configuration to be scoped to those resources. Private ports, multi-project ingress permissions, and network policies can limit which internal dependencies are reachable.
External systems need their own lifecycle. Tag test tenants, buckets, callbacks, and temporary identities with the preview ID, then delete or revoke them during teardown.
Grant preview access only after the change passes its required classification and checks, then revoke it when the pull request closes, merges, expires, or no longer has an owner.
At creation, evaluate the change origin and classification before injecting credentials. Mark the preview reviewable only after required checks pass. Give exceptions an owner and expiry. On merge, close, or inactivity, delete the preview and revoke external identities and resources.
For lifecycle enforcement, Northflank can update a preview when new commits arrive, set maximum concurrent preview limits, and be configured to delete previews when a pull request closes or merges, or after a defined period without commits. A Preview Blueprint teardown specification can invoke cleanup for resources created in external providers. Your team must still define which external objects were created and how their providers revoke them.
Your enterprise should audit membership and role changes, automation tokens, preview creation, exposure policies, secret access, exceptions, application requests, and resource deletion. Platform and application events must be reviewed at their respective layers because one log rarely proves both.
Review membership, role mappings, privileged changes, API tokens, public exposure, secret permissions, exceptions, stale previews, and orphaned resources. Repeat after identity or shared-template changes.
If you need administrative evidence across teams, Northflank audit logs record events from users, version control, the UI, API/CLI, preview environment template runs, and the Northflank system. Logs are available at organisation, team, and project scope, with resource-level audit logs for services, jobs, and addons.
Platform audit logs are not application request logs. If policy requires evidence of who opened a preview or accessed a particular record, the application, identity proxy, or edge layer must record that event with the permitted identity and retention policy.
Yes. Northflank can standardise preview access across teams by combining organisation-level identity controls with reusable Preview Blueprints, project-scoped resources, service access policies, secret restrictions, and lifecycle automation.
The organisation, team, and project hierarchy limits administrative scope. A Preview Blueprint defines what an eligible pull request creates, which components are public, which tagged secrets they inherit, and how the environment is removed. Port and path policies control reviewer entry, while audit logs show platform actions.
Your enterprise remains responsible for group membership, data classification, dependency permissions, repository trust policy, and exceptions. Northflank makes those decisions repeatable across the preview fleet.
Get started with Northflank self-serve, or book a demo to discuss preview architecture, identity, networking, compliance, or access requirements.
Not necessarily. A public static preview with synthetic content may not need identity-aware access. Internal applications, administrative interfaces, customer-shaped data, and sensitive workflows should normally use SSO for named groups or remain private. Derive the requirement from the preview's classification rather than applying one answer to every repository.
Only for a low-risk, short-lived preview that does not require individual accountability. Basic authentication provides a simple barrier, but a shared credential is difficult to tie to one person or revoke through normal joiner, mover, and leaver processes. Use corporate SSO when access must follow individual identity or directory-group membership.
Only when the environment can run the change without privileged secrets, sensitive data, or routes to protected systems. An external pull request can first run unprivileged checks, then create a constrained preview after the repository policy's required review or checks. Never expose a production credential merely because the deployment target is temporary.
No. Platform audit logs show administrative and automation events such as role changes or preview runs. Evidence that a person opened the deployed application normally comes from the SSO proxy, edge access log, or application itself. Retain each log according to the policy it supports.
- Preview environment troubleshooting: Common failures and how to fix them
- Preview environments for microservices: Architecture and common pitfalls
- How to auto-create preview environments on every PR
- Which database strategy should you use for preview environments?
- How do preview environments scale for AI-generated code?
