Preview Environments for Every Branch, on Your Own Box

Why preview environments earn their keep

Reviewing a pull request by reading the diff only gets you so far. For anything with a UI or an API, you want to click around the actual change before it merges. Preview environments give every branch its own running copy of the app at a predictable URL, so a reviewer, a designer, or a client can see the change live instead of imagining it.

Managed platforms have offered this for years, and it is genuinely useful. The catch is the same as the rest of managed hosting: previews run on someone else's infrastructure, they count against your usage, and a busy repo can spin up more of them than you expected. On your own servers, a preview costs you a container and a subdomain.

How self-hosted previews work

A preview is a normal deploy with a short life. InfraPilot builds a branch, gives it a subdomain derived from the branch name, and tears it down on a timer:

infrapilot preview create my-app https://github.com/me/my-app feature-checkout

That branch becomes reachable at feature-checkout.preview.example.com with its own SSL certificate. When the time-to-live expires, or when you remove it with infrapilot preview rm, the container and its subdomain go away and stop using resources.

Wildcard DNS and SSL

The one piece of setup is a wildcard. Point *.preview.example.com at your server with a DNS record, and provision a wildcard certificate through a DNS challenge. After that, every preview subdomain resolves and serves HTTPS with no per-branch configuration. New branches do not need new DNS records or new certificates; they inherit the wildcard.

Fitting it into review

The natural place to create a preview is when a pull request opens, and to destroy it when the PR merges or closes. You can wire that up from your CI with two calls to the InfraPilot API, or create previews on demand from the CLI when a particular branch is worth a closer look. Either way the URL is deterministic, so a bot can post it as a PR comment and reviewers always know where to click.

Keeping previews cheap

Two habits keep preview environments from quietly eating a server:

• Set a sensible TTL so forgotten branches clean themselves up. A day or two is usually plenty for review.
• Give previews smaller resource limits than production. A reviewer clicking through a feature does not need production-sized memory.

With those in place, previews become something you reach for on any non-trivial change rather than a feature you ration.