Environment Provisioning and Preview Deployments
Environment provisioning turns a declared configuration into a running place to test a change. Preview deployments make that place available for review. Design the environment’s identity, data, dependencies, access, cost limits, and cleanup as part of the feature.
A separate URL does not establish isolation. A preview can still use production credentials, write to shared queues, send real email, or leave resources behind after a failed build. Define which boundaries the preview separates and which remain shared.
TL;DR
- Use stable environment and resource identities tied to a project and change.
- Separate untrusted build work from privileged provisioning and secrets.
- Use synthetic or approved test data and controlled external side effects.
- Set resource limits, expiry, ownership, and independent cleanup reconciliation.
- Verify creation, updates, failures, stale resources, and teardown before relying on the workflow.
Quick Example
This complete Python dry-run model selects fictional cleanup candidates. It does not discover, provision, or delete resources. The timestamp is a fixed teaching input, not the current time. Ownership, resource kind, expiry, and active lease are checked independently.
A real cleanup controller needs trusted inventory, authorization, current lease/state evidence, a final pre-action check, dependency-aware ordering, and result verification. Tags and a stale timestamp alone must not authorize deletion. The example only demonstrates a bounded selection rule.
Core Concepts
Provisioning boundary
List application compute, storage, database state, queues, caches, credentials, network policy, DNS, telemetry, and third-party integrations. Decide which are dedicated, partitioned, or shared. Explain the residual interference and data risks of each shared component.
Preview and production configuration
Platform environment names have concrete behavior. Vercel distinguishes Local, Preview, and Production, with documented deployment triggers and first-deployment behavior. Verify the actual target and effective variables rather than assuming a nonproduction-looking branch or URL guarantees nonproduction resources. Vercel environments
Trust boundary
Pull-request code, build scripts, dependency hooks, and uploaded artifacts can be untrusted. GitHub warns that privileged workflows combined with untrusted checkout can expose secrets and repository permissions. Keep the provisioning authority separate and validate the artifact/metadata crossing into it. GitHub workflow security
Design the environment lifecycle
Use a small state model: requested, provisioning, ready, updating, failed, expiring, deleting, and deleted. Record the change revision, owner, resource identifiers, expiry, and last observed state. A retry should reconcile the same intended environment rather than create a second invisible copy.
Define what “ready” means through a representative journey. A process listening on a port does not prove the database is seeded, migrations completed, or a callback uses the preview URL. Keep readiness separate from the build’s success status.
Handle updates explicitly. Decide whether a new revision reuses state, replaces the environment, or migrates test data. Reusing a database can make review convenient while hiding a missing migration or introducing state from the previous revision. Use a clean-start check where the change needs it.
Protect data, access, and external effects
Prefer synthetic fixtures that reproduce relevant shapes without containing production records. If approved transformed data is required, validate the transformation and its allowed use; do not assume deleting a name field removes every sensitive attribute or identifier.
Give preview identities only the intended test destinations. Route email, payment, webhook, and message effects to authorized sandboxes or local substitutes, and verify the routing. A test banner in the UI cannot prevent a backend from using a production credential.
Apply access protection appropriate to the content. Vercel documents deployment protection methods and their configuration; inspect effective protection on the actual target and test the intended review path. Do not rely on an obscure URL as the only access control. Deployment protection
Keep configuration and credentials scoped by environment, with a defined rotation and revocation path. Review logs, build output, exported artifacts, screenshots, and shared links for unintended disclosure. The people reviewing a feature may not be the people authorized to see every underlying dataset.
Bound spend and reconcile cleanup
Estimate the resources needed for the review purpose and define a per-environment limit, maximum concurrent count, expiry, and exception owner. Use current provider terms and observed usage for an actual cost decision; this article supplies no price or savings claim.
Track orphaned databases, storage, snapshots, network resources, logs, and third-party allocations as well as the application deployment. A closed pull request is one cleanup signal, not proof that every resource was removed. Partial provisioning failures and missed events need an independent inventory reconciliation path.
Use a dry-run candidate list and a final target check before destructive cleanup. If ownership, lease, or resource kind is unknown, route it for investigation under the operating policy rather than guessing. After deletion, verify absence and identify resources that intentionally outlive the environment, such as restricted audit records.
Rehearse failed creation, interrupted update, expired review, active lease extension, missed close event, and failed deletion in an authorized disposable scope. Preserve exact resource identities and outcomes so a cleanup incident can be understood without searching by a vague name prefix.
Best Practices
Provision from a declared contract
Keep environment inputs versioned and validate them before granting privileged execution. Separate requester-provided values from trusted project identity and resource policy.
Verify isolation through behavior
Test data access, queues, callbacks, and external destinations, not just naming conventions. Document shared dependencies that can still affect another review.
Give cleanup its own owner
Monitor stale and failed resources independently of the happy-path workflow. A missing event should not create a permanent environment or authorize deletion of an unrelated one.
Common Mistakes
Bad: Treating a preview URL as proof of isolated data.
Correct: Inspect effective credentials and test every relevant read/write and external-effect destination.
Bad: Running untrusted pull-request code with provisioning secrets.
Correct: Separate the trust stages and validate the artifact and metadata before privileged work.
Bad: Deleting resources by name prefix alone.
Correct: Require trusted ownership, scope, lifecycle/lease evidence, final checks, and verified outcomes.
FAQ
Does every preview need its own full stack?
No. Choose isolation according to the risk and review purpose, and document the behavior and interference of shared components.
Is pull-request closure sufficient cleanup?
It is a useful trigger. Reconcile actual resource inventory independently to catch partial failures and missed events.
Did the example delete anything?
No. It selects candidates from invented records and rejects active, foreign-project, production, and future-expiry cases.
Related Topics
- DevOps & Delivery — Connect provisioning with delivery operations.
- Docusaurus & Docs Sites — Support documentation review workflows.
- Cloud Shared Responsibility — Assign configuration and data duties.