Linux infrastructure services
Everything we deploy runs on Linux — in containers, on virtual machines and on devices. Knowing it properly is what separates a fixed production incident from a restarted one.
Where we use Linux
Linux is part of the stack on this service. Each page covers how we work, what you get and what it costs to start.
Linux in practice
Everything we deploy runs on Linux, whether that fact is visible or not. Containers, managed services and serverless runtimes are all Linux underneath, so understanding process behaviour, memory, file descriptors and the network stack is what turns a production incident into a diagnosis rather than a restart.
That depth matters most exactly when abstractions leak. A container hitting a file descriptor limit, a service killed by the OOM killer, a disk filling with logs nobody rotated — none of those are visible from the platform dashboard, and all of them are obvious from the host.
What we build with Linux
Hardened hosts with unattended security updates, sensible limits and access controlled by key rather than password.
Diagnosing what actually caused the CPU, memory or I/O problem instead of scaling until it goes quiet.
Minimal Linux images on devices, with remote update and recovery paths designed in.
Is Linux right for you?
Ask usA good fit when
- Every server, container and cloud instance we deploy to
- Edge and IoT devices needing minimal, updatable images
- Performance and incident investigation
- Security hardening and compliance baselines
Probably not when
- Nothing — the question is only how much of it you manage yourself.
What we run alongside Linux
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- systemd
- Service management, restarts and journal logging.
- Unattended upgrades
- Security patches applied automatically, which is the baseline nobody should skip.
- ufw or nftables
- Firewall rules, default deny, opened deliberately.
- SSH key-only access
- Passwords disabled, keys managed, root login off.
- logrotate
- Because a full disk is one of the most common causes of an outage.
Why Linux
Let’s talkIt is what the cloud is
Containers, managed services and serverless runtimes are Linux underneath, so the knowledge always applies.
Observable to the bottom
The tooling exists to see exactly what a process is doing, which is not true on every platform.
No licence cost
Scaling out is a capacity decision rather than a procurement one.
What we get called in to fix
Get a second opinionDisks full of logs
Rotation never configured, so a service dies at 3am for a reason that had nothing to do with the code.
Unpatched systems
Servers months behind on security updates because updates were manual and therefore optional.
Resource limits hit
File descriptor and process limits at defaults that a busy service exceeds.
Nobody knows what runs where
Hosts configured by hand over years, with no inventory and no reproducible build.
Linux or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Containers for applications. Managed servers where something genuinely needs a persistent host.
Debian family for hosts and general use; Alpine for small container images where musl is not a problem.
systemd on the host. Inside containers, let the orchestrator do it.
Ansible
ArgoCD
AWS
Azure
CircleCI
Datadog
Docker
GitHub
GitLab
Go
Google CloudGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
Debian and Ubuntu most often, Alpine for containers. We follow whatever your team already supports.
Yes — patching, firewall rules, SSH hardening, fail2ban and a monitored audit trail.
Yes. That work usually starts with measurement rather than with a change.
Yes — SSH configuration, firewall, automatic security updates, fail2ban and an audit trail, as a baseline rather than an add-on.
Yes, and it starts with measurement. Changing things before measuring is how a slow system becomes a slow and unstable one.