Review a proposed app change before moving it into your main deployment. Impreza branch previews create a separate deployment with a temporary onion address, using your server’s resources and a configurable lifetime.
The generated preview address does not need a public DNS hostname or a public TLS certificate. This is useful when you want to share a review over Tor without adding a public preview hostname. Application authentication and careful handling of data remain part of the setup.
A review workflow with a defined lifetime
Enable previews on an eligible Git-connected parent, push another branch and collect its onion address. Reviewers open it with Tor Browser. Later pushes refresh the live preview and extend its expiry.
Choose a lifetime from 1 to 168 hours and a count limit from 1 to 20 previews per parent. Defaults are 24 hours and five previews. When a new preview reaches the configured limit, the oldest existing preview is selected for retirement. Expired previews are handled by cleanup, and branch-deletion pushes can request earlier retirement.
Use this for short-lived app reviews and tests whose dependencies can work in that environment. A permanent staging service or production Tor site needs its own deployment plan.
What runs on your server
Each preview consumes server capacity alongside the parent and any other apps. Account for build overhead, CPU, memory and storage when choosing the VPS. The count limit does not reserve capacity or automatically scale the server.
Supported declared volumes get separate preview storage. The feature does not copy a full production environment or automatically clone external databases. App variables can still carry over from the parent, including credentials and connection strings. Prepare a test parent and non-production services when the project needs that separation.
Confirm that your project fits
The documented workflow uses a custom app built from a Git repository that the child can clone without private-repository credentials, with a root-level Dockerfile and a working push webhook. Compose manifest deployments are excluded.
Private repository authentication and a custom Dockerfile location need compatibility confirmation before you rely on previews. Source-repository privacy and preview-address privacy are separate properties.
Your app should work with its onion origin and reviewers should be comfortable using Tor Browser. Public-only OAuth callbacks, external webhooks and third-party assets may need a separate testing approach. Keep production payments, customer notifications and production database access out of the review environment.
Privacy without an absolute promise
An onion review address avoids provisioning a public hostname for that preview. It does not automatically restrict visitors to your team, remove account records or make the application untraceable. Protect the app with appropriate login, review server exposure and share the address through the channels you intend to use.
The detailed guide explains inherited settings, branch handling and cleanup so you can assess the workflow before enabling it. No unlimited-preview allowance, dedicated capacity or zero-impact guarantee is implied.
Start with one test branch
Choose capacity for the parent and a small number of previews, deploy a test parent with suitable settings, then follow Preview Git Branches over Tor. Verify the resulting app and retirement behavior before using the workflow for client reviews.
If your goal is a persistent onion service, explore Tor Hosting. For app deployment through an assistant, start with Deploy with AI.