DevOps & automation
Make production boring.
Most outages trace back to something done by hand, at speed, by someone who had done it before but not written it down. We turn that into version-controlled, reviewable, repeatable automation — and leave your team able to change it.
Capabilities
What we cover
- CI/CD pipelines GitLab CI and equivalents: build, test, artefact and deploy stages that fail loudly and early, with releases that can be rolled back as easily as they were shipped.
- Infrastructure as code Ansible and Terraform for servers, networks and cloud resources, so the estate is described in a repository rather than in somebody's memory.
- Containers and orchestration Sensible containerisation of existing applications, image hygiene and registry practice — without adopting a platform that is bigger than the problem.
- Linux systems engineering Provisioning, hardening, kernel and network tuning, systemd services and performance work on real workloads.
- Observability Prometheus, Grafana and alerting built around what actually indicates trouble, so on-call gets woken for things that matter and nothing else.
- Secrets and configuration Getting credentials out of scripts and shared documents and into managed storage, with rotation that someone can realistically perform.
- Backup and restore Backups are not the deliverable — restores are. We build them and then rehearse them, on a schedule, with the timings recorded.
- Runbook elimination Taking the recurring manual jobs your team dreads and turning each one into a pipeline, a playbook or a scheduled task with proper logging.
Engagements
How this usually starts
- Automate one painful thing. A fixed-scope first piece — usually the deployment or the job that always goes wrong — that proves the approach before anyone commits to a programme.
- Estate review. An assessment of what is manual, what is undocumented and what has no tested recovery path, with the risks ranked and costed.
- Build-out. Delivery of pipelines, infrastructure code and monitoring for a defined platform or product.
- Embedded support. Working alongside your engineers during a migration or a growth phase, with knowledge transfer as an explicit deliverable.
Technology
What we work with
We are vendor-neutral, but not vague about it — this is the estate we work in day to day, and where we can be useful from the first conversation rather than the third.
Source control & CI/CD
- GitHub
- GitHub Actions
- GitLab CI
- Jenkins
Containers & orchestration
- Docker
- Kubernetes
- Helm
- Container registries
Operating systems
- Debian
- Ubuntu
- Red Hat Enterprise Linux
- Rocky & AlmaLinux
Network
- Arista EOS
- Cisco IOS & NX-OS
- Network automation
- Packet capture
Infrastructure as code
- Terraform
- Ansible
- Packer
- Cloud-init
Observability
- Prometheus
- Grafana
- OpenTelemetry
- Alertmanager
Common questions
Questions we are usually asked first
Should we move from Jenkins to GitHub Actions?
Often, but not automatically. Jenkins earns its keep where you need long-running jobs, unusual hardware, or agents inside a restricted network. What usually justifies moving is the maintenance burden — a Jenkins controller nobody upgrades, with plugins nobody can account for, is a genuine operational risk.
We normally migrate incrementally: the new pipeline runs alongside the old one until it is trusted, rather than a cutover weekend that blocks every release if it goes wrong.
GitHub Actions or GitLab CI?
Both are capable. The decision usually follows where your code already lives, since splitting source control and CI across two vendors adds friction for little gain.
The differences that matter in practice are self-hosted runner management, how secrets are scoped between repositories and environments, and what your compliance obligations say about where builds may execute.
Do we actually need Kubernetes?
Frequently not. Kubernetes solves real problems — scheduling across many machines, self-healing, standardised deployment across many teams. If you run a handful of services on a couple of servers, it adds a large operational surface to learn and patch in exchange for very little.
Containers without Kubernetes is a perfectly respectable place to stop. We will tell you if that is where you should be, and we are equally happy running it properly if you genuinely need it.
Debian or Red Hat?
Both are sound. Red Hat Enterprise Linux tends to win where a vendor support contract is required, where software is certified only against RHEL, or where a compliance regime expects a commercially supported OS. Debian and Ubuntu tend to win on cost and on how quickly newer packages arrive.
The more important decision is standardising on one and patching it consistently. A fleet running four distributions at three release levels is the actual problem.
Can you automate our Arista and Cisco estate?
Yes. Configuration in version control, templated per role, deployed through review rather than typed into a terminal at 2am — with the current state validated against what the repository says it should be.
This is also where the network and delivery halves of our work meet: the same discipline applied to switches as to servers, and the same packet-level visibility we bring to our low-latency work.
How long does a CI/CD migration take?
A single well-understood service is usually days. A whole estate depends far more on how consistent your existing builds are than on the tooling — twenty services built twenty different ways is twenty small migrations, not one large one.
We normally start with one representative service, agree the pattern, then apply it. That gives you a real timeline based on measured effort instead of an estimate.
Will we be locked into your way of doing things?
No. Everything lands in your repositories, under your accounts, using tools you can hire for. If you bring the work in-house or hand it to someone else, nothing needs untangling first.
No lock-in, on purpose
Everything we build lands in your repositories, under your accounts, using tools you can hire for. If you decide to bring the work in-house or hand it to someone else, nothing has to be untangled first. That is the point.