Setting Up GitOps for Basic Infrastructure (Bootstrap)

GitOps bootstrap: where basic infrastructure breaks

The classic scenario: an environment is spun up manually for a specific task—this is the fastest way to get a working environment today.

Six months later, no one remembers why a parameter that is not in the description is set in production, and a backup restores data but not settings. This is how manual environment configuration becomes the only source of truth, and it lives in the head of one or two engineers.

Configuration drift accumulates slowly and almost imperceptibly. An edit “outside the process”—for an urgent release or to bypass a restriction—remains in the live environment; the next deployment overwrites it, and system behavior changes back without warning.

Or vice versa: the edit becomes fixed, the environment diverges from production, and checks stop proving anything.

Hence—non-reproducible environments. Tests pass where there are different limits and a different initialization order, while configuration that no one assembled end-to-end goes to production.

Downtime due to a configuration error is then measured not by deployment time, but by time to find the cause: until a discrepancy between fact and description is found, there is nowhere to roll back—the previous state was also assembled manually.

The GitOps approach removes the very possibility of such divergence: the environment description becomes the only source of truth, and any deviation from it is visible and fixable. We look at how this is covered at the level of basic infrastructure.

What changes after switching to a declarative scheme

Infrastructure stops being a set of manual actions and becomes a description in a repository.

The controller compares the actual state of the environment with the described one and brings it to the desired form—without ssh sessions, “memory-based tweaks,” and discrepancies between environments.

Environment reproducibility stops depending on who deployed the environment and on what day: the same branch gives the same result in test and production environments.

A change is checked before being applied. The edit goes in a separate branch, reviewers and automated checks examine it: manifest correctness, compliance with policies, the plan of upcoming changes.

Only after that does the controller synchronize the environment—and the same description is rolled back by reversing the edit, not by assembling “how it was” from memory.

We build such a scheme on Argo CD because it works the same for the first deployment and for subsequent edits.

Transparency of changes rests on the edit history. Each commit answers what changed, who the author is, and why—instead of searching through logs of someone else’s session.

Configuration drift is visible: if a resource was edited manually, the controller will return it to the described state, and the discrepancy will make it into the report.

Environment recovery time drops to applying the description to a clean environment. The standby environment is deployed from the same branch as the main one, so recovery does not turn into archaeology using old instructions.

GitOps bootstrap options: from manual assembly to automation

The bootstrap mode determines how much manual work will remain after the first run and what will happen when the environment is redeployed. There are three options: one-time manual assembly, parameterized environment templates, and full automation with entry checks.

The difference shows not at the start, but at the second or third iteration, when the environment needs to be spun up again or brought to the reference form.

How transitions between modes happen

The transition is rarely instant: first the basic state is described in the repository, then environment differences are moved into parameters, and only then are pre-application checks enabled.

A sign of maturity is that a repeated run changes nothing, and a discrepancy with the reference is visible before rollout, not after. At this step, admission policies and rollback to the previous state appear.

Implementation order: audit, scheme, setup, verification

GitOps bootstrap implementation is a sequence, not a single command: if you start with delivery setup, it is easy to get a scheme that reproduces on one environment and falls apart when a second one is added.

1. Infrastructure audit. We inventory clusters, registries, external dependencies, access permissions, and secrets. Separately, we record what was created manually outside the repository—this is the main source of discrepancies at the very first application.
2. Environment scheme. We define environments, their common layer, and differences: what is inherited and what is overridden. Here we also decide where state is stored and where there are only configuration descriptions.
3. Repository structure and application order. We split configuration into layers—basic resources, platform services, applications—and set the queue: what must exist before a dependency appears.
4. Delivery setup. Change approval, automatic application upon merge, permissions for the agent, secrets via an external store. Separately, we describe behavior during a discrepancy and who resolves it.
5. Verification in a staging environment. We deploy an environment from scratch and deliberately break scenarios: manual resource edit, merge conflict, rollback to a previous revision. We see whether the scheme recovers without manual intervention.
6. Handover to operation. We hand over the environment scheme, change policy, and the procedure for connecting a new environment—so that the on-call team can roll back delivery on its own.

Artifacts: repositories, access policies, regulations

Setting up GitOps for basic infrastructure ends not with a working environment, but with a set of artifacts that remain in the customer’s repository and then live without us.

A repository without an environment description and access rules turns in a month into a set of manifests where no one dares change anything: it is unclear which environments exist, how they differ, and who has the right to merge edits.

• Environment description — which environments exist (development, pre-production, production), how they differ in service composition, what is moved into variables, and what is set by overlaying on a common base.
• Access policies — roles and permissions within the cluster, separate accounts for automation, binding “who merges changes into which branch,” explicit prohibition of edits that bypass the repository.
• Change release procedure — the path of an edit from branch to application: mandatory checks, approval, the order of promotion between environments, the point of no return.
• Rollback procedure — how to return the previous state, in what time, which changes are rolled back only manually and why.
• Secrets management — where they are stored, who and how gets access, how rotation works, and what to do in case of a leak.
• Infrastructure documentation — the environment diagram, the dependency map between services, the list of external entry points, and the procedure for connecting a new component.
• Responsibility matrix — who approves changes, who is on call, to whom a discrepancy between actual and described state is escalated.

Each item is not a formality, but a condition under which the customer’s team can add a service or roll back a release on its own, without re-understanding the repository logic.

Case: infrastructure under repository management

Situation before

The customer is a product department with three environments: development, preprod, production. The base environment—cluster, network, access permissions, secrets—was spun up manually using a checklist from the wiki.

A new environment took three to four days to assemble, and discrepancies between production and preprod surfaced already during an incident.

What was changed

The description of basic infrastructure was moved into a repository: deployment in Kubernetes, network policies, namespaces, access permissions, secret storage.

The bootstrap itself was also described—the minimum set of resources from which everything else is deployed, including the synchronization component.

Any change goes through plan verification in a pull request, and the environment resolves discrepancies with the real state on its own.

What became

Spinning up an environment from scratch takes 25 minutes instead of three days; the second site is deployed with the same description. Failures of the “forgot a parameter during manual setup” class disappeared: not a single case in six months.

Downtime during recovery decreased from four hours to twenty minutes—state is returned from the repository, not assembled anew. Plus, the entire change history of the environment can be read by commits: you can see who changed it and why.

How does declarative delivery differ from a classic pipeline?

A classic pipeline answers the question “what to do”: build an artifact, run checks, distribute across servers, and execute commands in the required order.

Declarative delivery answers a different question—“what should the state be”—and bringing the system to that state is handled by a reconciliation agent inside the cluster. The boundary lies where a one-time action ends and continuous state retention begins.

In an ordinary pipeline, the result depends on what is already on the server: a repeated run may fail or create duplicates. A declarative description is idempotent—apply it once or a hundred times, the result is the same.

If someone edited a resource manually, reconciliation will notice: either return the description or show the discrepancy as a separate event. The change history is in the repository, and rollback is returning the previous revision, not searching for “what did we click there.”

In practice, the approaches do not compete: build, tests, and publication are left to the pipeline, while delivery and state retention are described declaratively.

Then basic infrastructure is deployed from one repository reproducibly—on a new site or after a failure—instead of repeating a dozen manual instructions.

Technical doubts: access permissions, rollbacks, manual edits

GitOps does not require infrastructure to be perfect from day one.

A discrepancy between the live environment and the repository is described as drift and is closed in a controlled way: first the current state is captured into declarations and accepted as a baseline, and only then is automatic reconciliation enabled. Before this step, no resource is deleted or recreated.

We separate access permissions by roles: a change is proposed via pull request, the on-call engineer confirms, automation applies.

A direct edit in the environment is either blocked by policy or recorded and turned into a task—the discrepancy does not accumulate silently, but enters the queue.

How is an unsuccessful change rolled back?

By a reverse commit to the previous state: automation brings the environment to it and waits for convergence. The history remains—you can see who changed what.

Who is responsible for urgent edits?

The on-call engineer can edit manually according to the “break-glass” rule: access is granted temporarily and logged. The edit must return to the repository the same day, otherwise reconciliation will return the previous state.

What happens if the repository or agent is unavailable?

The environment continues to work on the already applied state: changes accumulate, but nothing is deleted. After communication is restored, reconciliation proceeds as usual.

Where we start: scheme, access permissions, and work order

The first conversation is needed not for a presentation, but for reconciling input data: without an inventory of environments and a clear access model, any estimate turns into a guess. Below is what is worth preparing for discussing the task.

If some items are missing, this is not a blocker: we record gaps separately and close them during the discovery stage, before the first changes in the working environment.

• list of environments and clusters: how many there are, which are shared, which are isolated, where the boundary between test and working environment lies;
• current method of infrastructure management—manual commands, scripts, provider templates, or partially configured GitOps;
• composition of services that must come up first: network, secret storage, image build system;
• access model: who can change what in the repository and in the cluster, whether separate roles are needed for on-call engineers;
• requirements for storing secrets and keys—where they are currently located, who has access to them, how they get into the environment;
• rollback rules: how we determine that a rollout broke the environment, and in what time we need to return to the previous state;
• change windows and restrictions—when the working environment must not be touched.

The work order after contact looks like this: analysis of input data, scheme of repositories and branches, description of the base layer, connection of environments, verification of recovery from scratch, handover with instructions for the on-call shift.

As the first step, we come back with an estimate and a plan that shows what we do and what remains on your side.