--- title: "Templates and previews: a preview per pull request · Frazer" description: "A preview environment for every pull request, with only the apps it changes and a copy of the staging database, deleted when it merges. Templates create a new service, its repository and its database in one plan." url: https://frazer.ai/previews index: https://frazer.ai/llms.txt tokens: 2158 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Templates and previews: a preview per pull request · Frazer **Templates and previews** frazer.ai # 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. [Start building](https://frazer.ai/start?product=previews) [Read the docs](https://frazer.ai/docs) *The Preview environments page of the demo organization Acme: 5 live previews and 1 being deleted, one per pull request. 3 are ready at their own pr-number hostnames behind Frazer sign-in, each deploying only the app the pull request changes, the rest shared from staging, with a clone of the staging database from last night's snapshot. One is building, one failed on a migration, and one is being deleted with its database clone after its pull request merged.* Previews on staging, one per pull request product UI, demo organization 01 · How it works Fig. 1 ## From a label to a URL. Gone when the pull request is. **Fig. 1** A pull request becomes a preview namespace 02 · One policy per environment Fig. 2 ## 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. *Two panels of the Frazer console, demo organization Acme. The preview policy on the staging environment: triggered by the preview label and by every agent pull request, deploying only the apps a pull request changes, in a namespace per pull request, with a clone of the nightly orders-db snapshot, behind Frazer sign-in, deleted on merge or close or after 7 days. And preview 1931, ready: a GitOps Application generated by the pull-request generator, a signed image from the pull request's CI, its own namespace and database clone, and a smoke test posted on the pull request.* **Fig. 2** The preview policy, and one preview up close product UI, demo organization 03 · Templates ## 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., 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 ``` What running a template does, and how each effect is applied | 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. 04 · What you get ## 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-..` 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. 05 · Controls ## 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 `preview` profile. 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 06 · Pricing ## 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 price](https://frazer.ai/pricing#lines) Preview fee **$0**: a preview pays for the compute it uses Your servers **Included**: previews run on your staging cluster, part of the per-core server fee Frazer fleet $0.030 per vCPU-hour, $0.007 per GiB-hour, billed per second Each preview Its running cost on the pull request, and its own line in billing Templates What a template creates bills as itself; the plan shows the monthly cost first Questions ## Templates 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. ## More in Build and ship - [**Fir** Version control built for agents](https://frazer.ai/source) - [**Frazer CI** Native CI on Frazer Runners](https://frazer.ai/ci) - [**GitHub runners** GitHub Actions in a microVM](https://frazer.ai/runners/github) - [**Cache** One cache for CI and boxes](https://frazer.ai/runners/github#cache) - [**Registry** Images and models, signed](https://frazer.ai/registry) - [**Environments and GitOps** Connect a repo, roll out](https://frazer.ai/gitops) ## Open a pull request. Click the preview. [Start building](https://frazer.ai/start?product=previews) [Read the docs](https://frazer.ai/docs)