Connect a repository.
Every push rolls out by itself.
An environment is a folder in a Git repository, connected to a cluster. Your CI writes each new image digest into it, the cluster’s GitOps syncs it, and admission checks the signature. Staging moves on a commit, production on a pull request you approve.
$ frazer releases environments connect data \
--project acme-production --cluster main \
--repo acme/data-platform-envs \
--path envs/production \
--namespaces data-airflow,data-clickhouse \
--profile platform --dry-run
Plan: connect environment "data" to cluster main
+ Namespaces env-data, data-airflow, data-clickhouse
+ AppProject env-data · profile platform (elevated)
+ Applications 4 from commit 3f9c2e1
~ Git token main also reads acme/data-platform-envs
✓ Namespaces no conflict with environment platform
✓ Policy Policy dry run: 0 violations
Cost +6 vCPU, +24 GiB on main; no fee (own servers)
Approval org admin (profile platform)envs/production/ # the connected path
├── environment.yaml # labels, namespace defaults
├── _shared-values.yaml # environment-wide Helm values
├── apps/<family>/<app>/
│ ├── values.yaml # written by people
│ └── images.yaml # written by CI only
├── databases/<name>/database.yaml # Postgres, with backups
└── manifests/<name>/ # raw YAML: operators, tools# envs/staging/apps/microservice-grpc/billing/images.yaml
# written by CI only; production gets the same digest by pull request
app:
image:
repository: registry.frazer.ai/acme-staging/build-images/billing
tag: v0.1.46
digest: sha256:c3c9…From a push to a rollout.
Nothing to click in the console.
Staging and production, side by side.
Promotion is a pull request.
The console follows each image by its digest: built, written to Git, synced, rolled out, verified. When staging is ahead, Promote opens the pull request that copies the same digest into envs/production.
Each environment gets a fence.
Changes are checked before they merge.
| Profile | What the environment may create | Who chooses it |
|---|---|---|
standardDefault | Namespaced kinds in its own namespaces. No cluster-scoped kinds, no Gateways, no network-plugin, gateway-controller or GitOps kinds. | Developer |
platformElevated | Also an allowlist of cluster-scoped kinds: CRDs, ClusterRoles bound to its namespaces, its operators’ webhooks. | Org admin |
previewShort-lived | One namespace per pull request, deleted on merge, close or TTL. | Developer |
A namespace belongs to exactly one environment. Each environment gets its own GitOps project that sees only its repository and Frazer Registry.
The pull request check
On every pull request that touches a connected path, one check per environment, such as Frazer / acme-production / data. It shows:
- Objects added, changed and deleted, per Application, rendered by the target cluster’s own GitOps
- Anything the environment may not do: a Gateway, another environment’s namespace, a cluster-scoped kind
- A
Secretwith data in it - Policy dry-run results
- Whether each new image digest is signed
- The change in requests and cost
Make it required in your own branch rules.
GitOps without the glue.
Wired to the cluster for you.
Any number of environments
A cluster connects environments from any number of repositories.
One owner per namespace
The plan fails if two environments claim the same namespace.
Folders, not branches
Promotion is a pull request that copies a digest from staging to production.
Managed or your own
Frazer reads your folders, or applies your own ApplicationSets inside the environment’s fence.
Secrets stay out of Git
ExternalSecretobjects only; values live in Frazer Secrets.Careful sync defaults
Prune and self-heal; namespaces, volumes, CRDs and databases are never deleted without a confirm.
Sync windows
Production can refuse syncs outside its maintenance window; a manual sync still works.
GitLab and other Git hosts
Through deploy tokens.
Read-only by default.
Writing is a choice you make.
Who may do what
- Developer
- Connects an environment with the
standardprofile. - Org admin
- Approves the
platformprofile; the plan marks it elevated. - CI
- Writes image digests into
images.yaml, nothing else. - Frazer
- Reads selected repositories through the read-only “Frazer Reader” App. Writing pull requests takes a separate App you choose to install.
What is logged
- Connecting, changing and disconnecting an environment, each as a plan
- Every rollout, with the digest, the commit and who wrote it
- A rollback: a revert pull request in the environment repository
- Git itself: every change to what runs is a commit
At the cap
- Each cluster reads Git with a 60-minute token, refreshed every 20 minutes, limited to the repositories connected to it
- Deleting a namespace, volume claim, CRD or database waits for a confirm
- Production can add a sync window that refuses syncs outside maintenance
- The plan shows the vCPU and memory an environment adds before you apply
No fee for GitOps.
GitOps comes with every cluster.
Every cluster comes with Frazer GitOps, gateways, DNS and certificates, and there is no per-cluster fee. On servers you bring, what your environments run is part of the per-core server fee.
See every priceEnvironments and GitOps, answered.
Do we have to restructure our GitOps repository?
No. Connect the path you have. In managed mode Frazer reads the folder convention: an app per apps/<family>/<app>/ folder, databases and raw manifests beside them. In repo-defined mode your own ApplicationSets are applied inside the environment’s fence, and an Application that names another project is refused.
Why folders and not branches?
Branches drift: merge order, cherry-picks and fixes that land in one branch only. A pull request that copies a digest from envs/staging to envs/production shows exactly what changes in production. You can still pin a tag or a commit as the revision.
What access does Frazer need to our repositories?
Read access through the “Frazer Reader” GitHub App, installed on the repositories you pick. Each cluster gets a 60-minute read token limited to the repositories connected to it. Writing is a separate App you install only if you want Frazer to open promote and restore pull requests.
Where do secrets go?
Not into Git. Git holds ExternalSecret objects; the values live in Frazer Secrets and are delivered to the cluster with its own identity. An admission policy rejects a Secret with data in it.
How do we roll back?
Revert the commit or the pull request. Git moves forward, GitOps follows, and the rollback is recorded in the audit log like any other change.