Guide

Preview Deploys & DevOps

Your team should review features in context, not guess how they'll behave in production. We build preview environments that actually mirror reality.

The problem with testing today

Code review happens in diffs. Designers review in Figma. PMs review in staging—if staging works, if it has recent data, if someone remembers to deploy the branch.

The result: features get approved based on screenshots and imagination. Bugs surface in production because "it looked fine in the PR." Staging becomes a shared environment where everyone's changes collide.

AI-generated code accelerates the problem. You can build features faster than ever, but the feedback loop—seeing the feature actually running—stays slow and unreliable.

Preview environments

A preview environment is a full copy of your application, spun up automatically when a PR is opened, torn down when it's merged or closed.

Provisioning

• Automatic on PR open — no manual steps, no "can someone deploy this branch?"
• Ready in minutes — fast enough that reviewers don't context-switch away
• Unique URL — each PR gets its own URL, shareable with stakeholders
• PR comments — deployment URL posted automatically to the PR

Production parity

• Same infrastructure — containers, networking, and configuration match production
• Same backing services — real database, real cache, real queues
• Same environment variables — with preview-specific overrides where needed
• HTTPS by default — secure connections, just like production

Lifecycle

• Updates on push — new commits to the branch redeploy the preview
• Automatic teardown — merged or closed PRs clean up after themselves
• Resource limits — previews constrained to prevent runaway costs
• TTL expiration — stale previews expire even if PR stays open

Database workflows

Preview environments need data to be useful. But production data in previews is a security and compliance nightmare. We solve this with structured seeding and migration testing.

Seed data

• Realistic but synthetic — data that exercises real scenarios without real PII
• Versioned with code — seed data evolves with your schema
• Fast to load — previews shouldn't wait 10 minutes for data
• Customizable per PR — specific scenarios seeded for specific features

Migration testing

• Migrations run on deploy — schema changes tested before production
• Backwards compatible — migrations designed to work with old and new code
• Rollback tested — down migrations verified to actually work

Environment isolation

Each preview environment is completely isolated. No shared state, no cross-contamination, no "my PR broke your PR."

Network isolation

• Separate networks — previews can't communicate with each other
• No shared databases — each preview gets its own database instance
• External services mocked or isolated — third-party APIs don't get hit by every PR

Credential isolation

• Unique credentials per preview — no shared API keys or secrets
• Scoped permissions — preview credentials can't access production resources
• Automatic rotation — credentials rotated or revoked on teardown

Cost controls

• Resource limits — CPU, memory, and storage capped per preview
• Concurrent limits — maximum number of active previews enforced
• Cost visibility — preview costs tracked and reported

Backup & recovery

Previews are ephemeral, but production isn't. We build backup and recovery into the infrastructure from day one—tested, monitored, and documented.

Backup strategy

• Automated daily backups — no manual process to forget
• Point-in-time recovery — restore to any moment, not just daily snapshots
• Off-site storage — backups stored in separate region or provider
• Encryption at rest — backups encrypted with managed keys

Recovery testing

• Restore procedures documented — step-by-step runbooks
• Regular restore tests — verified to actually work, not just theoretically
• RTO/RPO defined — recovery time and point objectives documented

Monitoring

• Backup success alerts — notified if backups fail
• Retention compliance — backups retained per your requirements
• Size tracking — backup storage costs visible

Access controls

Not everyone needs access to everything. We implement environment-specific access controls so the right people have the right access—and it's all audited.

Environment permissions

• Tiered access — different permissions for dev, staging, production
• Role-based — developers, ops, and stakeholders get appropriate access
• Just-in-time access — production access granted temporarily, not permanently

Audit logging

• SSH access logged — who connected, when, from where
• Console access logged — commands and queries recorded
• Deployment triggers logged — who initiated each deploy

Third-party access

• Vendor access documented — which vendors have access to what
• Scoped credentials — vendors get minimal necessary permissions
• Regular review — access reviewed and revoked when no longer needed

What you get

At the end of a preview environments engagement, your team will have:

• Automatic preview environments for every pull request
• Production-parity configuration with proper isolation
• Seed data system for realistic testing without production data
• Database migration testing in previews before production
• Automated backup and recovery with tested restore procedures
• Environment-specific access controls with audit logging
• Cost controls and visibility for preview infrastructure

You also get documentation: how the preview system works, how to customize seed data, and how to troubleshoot common issues. Your team reviews features in context from day one.

References: 12-Factor: Dev/Prod Parity, GDPR Data Protection Guidelines, AWS Well-Architected: Backup & Recovery, Google Cloud Disaster Recovery Guide