--- title: "Environments and GitOps: connect a repository, roll out · Frazer" description: "Connect a folder of a Git repository to a cluster. CI writes each image digest into it, the cluster's GitOps syncs, and admission checks the signature; staging moves on a commit, production on a pull request." url: https://frazer.ai/gitops index: https://frazer.ai/llms.txt tokens: 2254 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Environments and GitOps: connect a repository, roll out · Frazer **Environments and GitOps** frazer.ai # 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. [Connect a repository](https://frazer.ai/start?product=gitops) [Read the docs](https://frazer.ai/docs) ``` $ 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/// │ ├── values.yaml # written by people │ └── images.yaml # written by CI only ├── databases//database.yaml # Postgres, with backups └── manifests// # 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… ``` Connect an environment: the plan comes before any change demo organization 01 · How it works Fig. 1 ## From a push to a rollout. Nothing to click in the console. **Fig. 1** Two repositories, one digest, five stages 02 · What runs where Fig. 2 ## 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`. *The Rollouts page of the demo organization Acme: 6 services with their versions in staging and in production. 2 are in sync, 2 can be promoted to production with a pull request in Git, 1 is still rolling out in staging, and 1 failed in staging, so its promotion is blocked. A rollback is a revert pull request in the environment repository, recorded in the audit log.* **Fig. 2** What runs where, per service product UI, demo organization 03 · Fences and checks ## Each environment gets a fence. Changes are checked before they merge. Permission profiles: what an environment may create, and who may choose the profile | Profile | What the environment may create | Who chooses it | | --- | --- | --- | | `standard` Default | Namespaced kinds in its own namespaces. No cluster-scoped kinds, no Gateways, no network-plugin, gateway-controller or GitOps kinds. | Developer | | `platform` Elevated | Also an allowlist of cluster-scoped kinds: CRDs, ClusterRoles bound to its namespaces, its operators’ webhooks. | Org admin | | `preview` Short-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 `Secret` with 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. 04 · What you get ## 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 `ExternalSecret` objects 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. 05 · Controls ## Read-only by default. Writing is a choice you make. ### Who may do what Developer Connects an environment with the `standard` profile. Org admin Approves the `platform` profile; 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 06 · Pricing ## 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 price](https://frazer.ai/pricing#lines) Environments **$0** per environment, with every cluster Clusters $0 per cluster Your servers $1.50 per physical core / month · min $15, max $150 per server · first server ≤ 16 cores free Questions ## Environments 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///` 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. ## 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) - [**Templates and previews** A preview per pull request](https://frazer.ai/previews) ## Git says what runs. Every cluster follows. [Connect a repository](https://frazer.ai/start?product=gitops) [Read the docs](https://frazer.ai/docs)