SaaS scale-up with server sprawl
A product team that had grown to a dozen manually-configured servers, none quite alike, codifies them into Terraform and Ansible so a new environment takes an afternoon instead of a week.
Infrastructure as Code & GitOps UK
DevOps services · United Kingdom
Infrastructure as code for UK teams tired of not knowing exactly what changed on a server, or by whom. We set up Terraform or OpenTofu and Ansible so your infrastructure is defined in git, reviewed through pull requests, and reproducible from scratch, with GitOps deploys through ArgoCD or Flux keeping the running state matching what's committed. DevOps hours cover the ongoing automation work, not just the first pass.
- Every infrastructure change reviewed in git first
- Environments reproducible from code, not memory
- Disaster recovery by rebuilding, not restoring guesswork
- VPS 1–8 h/month; dedicated 5–10 h/month depending on plan; GPU 10 h/monthIncluded hours
- Frankfurt, in the EUData centre
- ArgoCD or Flux, matched to your stackGitOps tooling
- EUR invoicing, 20% UK VAT itemisedBilling
01
What we put into code
We define your servers, networking and platform configuration in Terraform or OpenTofu, and your ongoing server configuration in Ansible, so both are versioned and reviewable rather than living in someone's memory or a one-off shell script. Deployments then follow GitOps: ArgoCD or Flux keeps the running cluster or environment matching what's committed to git, and drift between the two gets flagged automatically instead of discovered during an incident.
- Terraform or OpenTofu defining servers and networking as code
- Ansible handling ongoing configuration, versioned alongside it
- GitOps deploys through ArgoCD or Flux, matching git to reality
- Pull-request review required before any infrastructure change
02
Best practices we apply
Infrastructure as code only delivers its real value — reproducibility and audit trail — if the discipline holds every time, including the small manual fix under pressure that quietly breaks it. We apply the same checklist on every environment we set up, and we're honest that the hardest part is usually the team habit, not the tooling. We flag drift when we see it during included hours, rather than waiting for it to surface as an outage.
- Everything defined in git, with pull-request review required
- Infrastructure treated as immutable — rebuilt, not patched in place
- No manual changes made directly in production, ever
- Disaster recovery rehearsed by actually rebuilding from code
- Development, staging and production kept at genuine parity
03
Disaster recovery as a rehearsed rebuild
The real test of infrastructure as code isn't the pull-request workflow, it's whether you could lose a server entirely and rebuild it from git with confidence. We treat this as something to actually rehearse, not assume — running a real rebuild during onboarding so you know the recovery time before you ever need it during an actual incident, not while your service is down.
04
How the included hours work
DevOps hours come with the plan: 1–8 hours a month on VPS tiers, 5–10 hours a month on dedicated servers depending on the plan, 10 hours a month on GPU servers. Use them for the initial Terraform and Ansible set-up, migrating manually-configured servers into code, or extending GitOps to a new environment. Request the work from the client panel under DevOps Services. Hours don't roll over, so most teams codify existing infrastructure in one month and extend it incrementally afterwards.
How we work
Request the work from the panel
You describe your current infrastructure — manually configured or partially codified already — and propose a deadline under DevOps Services.
We scope the codification and GitOps set-up
We confirm what goes into Terraform versus Ansible, the review process, and which GitOps tool fits your existing stack.
We codify and rehearse a rebuild
We write the infrastructure code, migrate existing servers into it, and rebuild an environment from scratch to prove it works.
We hand over the repository and DR plan
You receive the infrastructure repository, the review workflow, and the disaster-recovery procedure we've already rehearsed.
Use cases
Agency managing infrastructure for several clients
A DevOps-focused agency needs every client's infrastructure defined in code with pull-request review, so a junior engineer's change can't silently break production without a second pair of eyes.
Fintech needing an auditable change history
A payments company needs a documented, reviewable history of every infrastructure change to satisfy a client's security due-diligence questionnaire, which manual server changes could never provide.
Technology stack
- Terraform
- OpenTofu
- Ansible
- ArgoCD
- Flux
- SOPS
- Vault
Every subscription includes monthly DevOps, CyberSecurity and Programming hours: 1 h from the cPanel Advanced plan up, 1–8 h on VPS, 5–10 h on dedicated servers depending on the plan, and 10 h on GPU servers. Hours are requested from your client panel, don't roll over to the next month, and anything above the quota is accepted and billed separately.
Frequently asked questions
What's the practical difference between Terraform and Ansible?
Terraform provisions infrastructure itself — servers, networking, DNS — and tracks its state. Ansible configures what runs on top of that infrastructure — packages, services, files. Most environments we set up use both together: Terraform for the servers, Ansible for what's installed on them.
What is GitOps, in plain terms?
GitOps means the state committed to git is the source of truth, and a tool like ArgoCD or Flux continuously reconciles your running environment to match it — so a deploy is a git commit, and drift between what's running and what's committed gets flagged automatically instead of discovered later.
Is infrastructure as code worth it for a small team?
Usually yes, even at small scale — the value isn't just reproducibility, it's the review trail and the ability to rebuild after a mistake or a server failure without guessing what the previous configuration actually was. We scope the initial set-up to match your actual server count, not a large-team assumption.
How do you handle secrets if everything's in git?
Secrets are never committed in plaintext. We use SOPS to encrypt secrets directly in the git repository, or a dedicated secrets manager like Vault, depending on your existing tooling — either way, the encrypted or referenced secret is versioned, but the plaintext value never is.
What does a disaster-recovery rehearsal actually involve?
We rebuild an environment from the infrastructure code alone, without touching the original servers, to confirm it works and to measure how long it actually takes. This happens during onboarding, so you know your real recovery time before an incident forces you to find out.
Can you migrate our existing manually-configured servers into code?
Yes — this is one of the most common requests. We audit the current configuration, write the equivalent Terraform and Ansible, and reconcile it against the live servers so the code genuinely matches reality before anyone relies on it for a rebuild.
Not sure your infrastructure could survive a server loss?
Tell us your current set-up and we'll codify it into Terraform and Ansible, then actually rehearse a rebuild, using the hours already in your plan.