A preview for every pull request.
A new service in one plan.
Label a pull request and Frazer deploys the apps it changes into their own namespace, with a copy of the staging database. The URL, status and running cost land on the pull request, and the preview is gone when it merges. Templates create a new service with its repository, folder and database in one plan.
From a label to a URL.
Gone when the pull request is.
One policy on staging.
Every preview on the record.
A preview policy says which pull requests get a preview, which apps deploy, where the data comes from and when it all goes away. Each preview is a GitOps Application in its own namespace, running the signed image its pull request built.
A new service in one plan.
Repository, folder, database, checks.
A template is the supported way to start something new. Running one is a single plan that lists every effect before anything happens; the workload part is written in Score, so a template asks for a database and Frazer resolves it to its own.
$ frazer templates run go-grpc-service --name rates-api --project pellwyn-staging --dry-run
+ repo pellwyn/rates-api (from template go-grpc-service@3)
+ git platform-envs: apps/core/rates-api/ (staging commit, production PR)
+ database rates-api-db (Postgres, 1 instance, 20 GiB)
+ hostname rates-api.pellwyn-staging.<apps-domain>, certificate
+ check HTTPS /healthz every 60 s from 3 locations; 4 default alert policies
# nothing happens until you apply the plan$ frazer preview-policies create --environment staging --trigger label:preview
# every pull request labeled preview gets one, on the staging environment
$ frazer previews list
# also: frazer previews open, extend and delete| Effect | Applied as |
|---|---|
| A source repository from a skeleton, with CI that builds, signs and writes the digest | The opt-in “Frazer” writer App |
| The app’s folder in the environment repository: staging by commit, production by pull request | Git |
| Database, hostname and certificate, uptime check, default alert policies | Frazer API resources |
| Catalog entry and owner group | Frazer API |
The starter set
- Go gRPC service
- TypeScript web app
- Worker
- Cron job
- Postgres-backed API
Frazer publishes these in a public project. Your teams add their own from a Git repository and share them with other projects. A service remembers its template’s version and answers.
Review the running change.
Not just the diff.
Only what changed
The pull request’s apps deploy; the rest are shared from staging.
Its own copy of the data
A clone of the last staging snapshot, migrated by the PR, deleted with it.
Private by default
pr-<n>.<app>.<project>hostnames behind Frazer sign-in.On the pull request
URL, status and running cost, posted as a check.
Triggers you choose
A preview label, every pull request, or agent pull requests only.
Serverless stacks too
A tagged revision, a Postgres branch and a fresh Valkey per pull request.
Sleep when idle
Scale to zero between visits.
Agents test against it
Coding agents and the Reviewer use the same preview.
Inside the environment’s fence.
With a quota and a TTL.
Who may do what
- Developer
- Sets a preview policy on an environment with the
previewprofile. - Frazer
- Owns the ApplicationSet that makes previews, inside the environment’s fence.
- Approver
- Required before a preview clones production data, with a masking job.
- Template author
- Publishes a template in a project and shares it with other projects.
What is logged
- Every preview, with its pull request, image digest and database clone
- Every template run, as one plan listing each effect before it applies
- Extending or deleting a preview
At the cap
- Previews count against the project quota and appear in billing as their own line
- CPU overcommits up to 4:1; memory never
- Deleted on merge or close, or at the TTL: 7 days by default
- Clones come from staging; production data needs an approval
No preview fee.
It pays for what it runs.
A preview uses the capacity of the environment it copies and counts against the project quota. On servers you bring it is part of the per-core server fee; on the Frazer fleet it pays the fleet’s vCPU and memory rates by the second.
See every priceTemplates and previews, answered.
Does a preview copy production data?
No. By default a preview clones the staging database from its last volume snapshot. Cloning production needs an approval and a masking job. Migrations in the pull request run against the copy, so they cannot touch shared staging data.
What if our storage cannot take snapshots?
Then Frazer restores the clone from the object-store backup instead, which is slower. The plan shows which path a preview will take before you turn the policy on.
How is a preview kept apart from staging?
Each preview gets its own namespace under the environment’s preview profile, made by an ApplicationSet that Frazer owns inside the environment’s fence.
What does a preview cost?
It runs on the staging cluster’s capacity and counts against the project quota. The running cost is posted on the pull request and shows in billing as its own line, and the preview is deleted at the TTL even if nobody closes the pull request.
What does a template create?
One plan lists every effect before anything happens: a repository from the skeleton with CI that builds, signs and writes the digest; the app’s folder in your environment repository; a database, hostname, certificate, uptime check and default alerts. A template is a project resource you can share with other projects.