Infrastructure as Code
We describe environments as code, for example in Terraform or OpenTofu, versioned in Git, and build delivery pipelines that build, test and roll out, so pipelines handle the routine work.
When we help
Every change to the environment goes through a repository, where it is reviewed, kept in the history and can be rolled back.
- Environments built by handIt is unclear exactly how production is set up, and a new environment never comes out quite the same.
- Manual steps to productionA release takes hands-on work and someone who knows the steps.
- Code that no longer matchesThe code exists, but changes were made on the side, directly in the environment.
- A new platformAccounts, networking or clusters are about to be built, and you want it done as code from the start.
From commit to production
Every change takes the same path, and the reviewer sees what will happen before it happens.
- ChangeA branch and a pull request Formatting, validation and static checks Security and policy checks Result A change that can be reviewed
- PlanA plan against every affected environment The plan is shown in the review Approval by another person Result You see what changes before it happens
- RolloutThe pipeline applies the change, not someone's computer Test first, then production The same code for every environment Result The same change in every environment, in order
- Follow-upComparison between the code and what runs Alerts when something changes on the side History of every change Result The environment matches the code
More than infrastructure
Anything with an API can be described as code, from cloud accounts and DNS to the pipelines and platforms on top, in the same repositories and with the same review.
- InfrastructureAccounts, networking, clusters, DNS and access, in AWS, Azure, Google Cloud or your own data center.
- Delivery pipelinesBuild, test and rollout for both applications and infrastructure, in the CI system you already use, such as GitLab CI/CD.
- Clusters and networkingKubernetes and Proxmox VE clusters and the network's configuration, described the same way as everything else.
Environments you can rebuild
An environment described as code can be built again: after a failure, for a new team or for a test.
- The same code for every environmentThe difference between test and production lives in variables, not in changes made by hand.
- State in a safe placeIn shared storage with locking and versions, not on someone's computer.
- Secrets outside the codePasswords and keys are fetched from a secrets manager and never checked in.
- A tested rebuildWe build an environment from the code to show it works, and write down how.
- Same modulesWritten once.
- One variable file per environmentOnly what differs.
- TestTorn down when not needed.
- ProductionThe same build, at larger scale.
The code is yours
The code, pipelines and documentation sit in your repositories, so your team can change and rebuild the environments without us.
- Take a change from pull request to production
- Read a plan and decide whether to approve it
- Rebuild a test environment from the code
- RepositoriesInfrastructure and pipelines as code, with a history of every change.
- Modules and documentationHow the code is organized and how a new environment is added.
- RunbooksRollout, rollback to an earlier version and handling state.
- Access and ownersAccounts, keys and pipelines stay with you, with a named owner for each part.
