Preview deployments
Try a change at its own address, with its own database, before it goes live.
Built on Git and PostgreSQL
Plans: Every plan, including the free app
| Preview copies per app | Free app | Starter | Team | Business | Client business |
|---|---|---|---|---|---|
| Included | 1 | 3 | 3 | 3 | 3 |
What you get
- A running copy of a branch at its own address
- Its own PostgreSQL database, starting empty
- Started on request, then updated on every push
- Sleeps when nobody is using it
- Removed a few days after its last push or visit
- Hidden from search engines
- Production data and scheduled jobs left alone
How it works
Pushing a branch stores it without starting anything. When someone needs to see a change, a developer or coding agent starts a preview with whisk envs start or from the app's environments page, or runs whisk deploy from the branch. From then on, every push to that branch updates the preview.
A preview has its own container and its own PostgreSQL database. Migrations in the branch run against that database, never against production. Scheduled jobs, workflows and events do not run in a preview, so testing a change never repeats a real nightly job.
Previews sleep when idle, like any app. Each one is removed after a set number of days with no push or visit. The plan sets how many previews each app can have at once.
Example
A freight forwarder wants to change how its booking app calculates container fees. Its coding agent pushes the change to a branch and starts a preview, and the operations manager tries some test bookings there. Once she approves, the branch is merged to main and the preview is deleted.
For your coding agent
git push whisk <branch> whisk envs start <branch> whisk envs delete preview:<branch>
previews.ttl_days in whisk.yaml sets how long an unused preview is kept. The commands are in the CLI reference, and branches are covered under Git hosting.