Infrastructure as code, GitOps and CI/CD so you can deploy without fear
Infrastructure that can be rebuilt from the repository, and deploying that is a merge, not a Friday ritual.
Usual tools
- Gitea
- Laravel
- SonarQube
- Terraform
- Ansible
- Argo CD
- Flux
- GitLab
In short
Infrastructure as code means describing servers, networks, permissions and services in versioned files instead of configuring them by hand. We move your infrastructure to Terraform and Ansible, deploy with GitOps from the repository using Argo CD or Flux, and build CI/CD pipelines that build, test and deploy. Every change is reviewed and can be undone.
- Languages
- Spanish, Catalan or English
- Response
- The next business day, during business hours
- Method
- In your account and your repository, in code and documented
What is included
- Inventory of the current infrastructure, including anything created by hand in the console.
- Modular Terraform, with protected and locked remote state.
- Ansible for configuring servers that are not ephemeral.
- GitOps with Argo CD or Flux: what runs in the cluster comes from the repository.
- CI/CD pipelines in GitLab CI or GitHub Actions with tests and automatic deployment.
- Secrets kept out of the code, with HashiCorp Vault or your provider's secrets manager.
- A tested rollback procedure.
- A README on how to deploy, change and rebuild each environment.
What problems does it solve?
Infrastructure built by hand works until you have to repeat it, audit it or fix it in a hurry. These are the symptoms we usually find when we arrive:
- Deployments happen over SSH, with commands only one person remembers.
- Production and staging look alike, but nobody knows how they differ.
- There are cloud resources nobody knows the purpose of, or whether they can be deleted.
- Passwords live in stray variables or in the repository itself.
- Rolling back to the previous version takes hours, or nobody even tries.
What changes, before and after?
The goal is not to have Terraform for the sake of it, but for every routine task to be faster, safer and recorded. This table sums up the change in the most frequent tasks:
| Task | Before | After |
|---|---|---|
| Deploy a release | Manual commands over SSH | Merge into the main branch and the pipeline deploys |
| Roll back | Try to remember what was changed | Revert the commit; GitOps restores the previous state |
| Create a new environment | Days copying configuration | A Terraform module with different variables |
| Know what is in the cloud | Go through the console service by service | Read the repository and the state |
| Rotate a credential | Hunt for where it is written down | Change it in Vault; the services pick it up |
| Audit a change | Ask whoever made it | Commit and review history |
How do we do it without stopping anything?
In layers and alongside what already works, so the team can keep deploying in the meantime:
Inventory
We list what is in the account, what is used and what is surplus, and share it before touching anything.
Import into Terraform
Network, permissions, managed databases and machines, module by module, until the plan proposes no changes.
Pipeline
Build, tests, image scanning and automatic deployment to a test environment.
GitOps
Argo CD or Flux take control of the cluster; manual changes are no longer possible.
Secrets and handover
Credentials moved to Vault, exposed ones rotated, and every workflow documented.
Which tools do we use?
Terraform for infrastructure on AWS, Google Cloud, Azure, Hetzner or DigitalOcean; Ansible for stateful servers; Helm for packaging services on Kubernetes; Argo CD or Flux for GitOps; GitLab CI or GitHub Actions for pipelines; and HashiCorp Vault for secrets. If you already use another tool that works, we adapt to it.
What experience do we have?
In DevOps at a B2B SaaS we have maintained the CI/CD pipelines and the multi-cloud environments described in code, and in SRE at a food factory we have worked with platforms where downtime shows up in production output. From CTO and head of engineering roles we have reviewed and tidied up infrastructure built by hand. If you would then like us to maintain it, it fits with SRE as a service.
Frequently asked questions
Do we have to stop the service to move to Terraform?
No. We import the existing resources into the Terraform state module by module and check that the plan proposes no changes before moving on. The service does not notice.
Argo CD or Flux?
Both work well. Argo CD has an interface that helps teams who are new to GitOps; Flux is lighter and fits if everything is managed from the repository. We decide based on who is going to use it.
Do you work with our GitHub or GitLab?
Yes. We work in your repository, with your review rules, and every change goes in a merge request or pull request. We do not use repositories of our own or shared accounts.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on