Server administration and infrastructure, without hiring for it full time
Most businesses need a systems engineer a few days a month, not a full-time hire. Hiring one is expensive and leaves you with a single point of failure; having nobody means the servers drift until something breaks badly.
What we take on.
Your servers, your cloud account or a mix. We administer infrastructure we did not necessarily build.
Ongoing administration
Patching, user and access management, service configuration, certificate lifecycle, disk and log hygiene, resource planning before you run out rather than after. The routine work that quietly prevents most outages from ever happening.
Hardening and recovery
Firewall and SSH policy, fail2ban, the principle of least privilege, removal of the services nobody remembers enabling. Plus the part most often missing: a restore procedure that has been tested, not a backup job that has merely been running.
Migrations and consolidation
Moving between providers, from physical to virtual or off a machine whose warranty expired years ago. Planned, rehearsed, executed out of hours, with the previous environment kept available until the new one has proven itself.
Documented, not improvised.
The most common state on arrival is a server that works and that nobody has touched in three years. Nobody could rebuild it if it were lost, because the configuration exists only on the machine and in the memory of someone who has since left. The first job is always to write down what is actually there.
What we do first
- An audit: what is running, what it depends on, what is exposed to the internet and what is out of support
- Backup verification by restoring — the only way to know whether a backup exists in any meaningful sense
- Access review: removing former employees' accounts, replacing shared accounts with named ones, rotating anything that has been passed around
- Monitoring with alerts that reach a person, covering disk, memory, load, certificates and service health
- Written documentation of the setup, so the next engineer — ours or yours — is not starting from archaeology
Cloud, on-premises or both
We are not committed to a position on this. Cloud makes sense for variable load and for teams without hardware; owned servers are frequently cheaper for steady, predictable workloads, and sometimes a data-residency requirement settles it. We will do the arithmetic on your actual usage rather than recommend whatever is fashionable, and plenty of organisations sensibly run both.
Security as maintenance
Most breaches are not sophisticated. They are an unpatched service, a password reused from somewhere else or an administration panel left reachable from the open internet. Regular, boring maintenance closes off almost all of them, and it costs considerably less than incident response does.
Things clients ask before starting.
We already have an IT person. Does this replace them?
Do you work with AWS, Azure and Google Cloud?
What access do you need?
Can you help after an incident has already happened?
Often combined with these.
Tell us what you are running on.
Describe your servers, where they live and who looks after them today. We will start with an audit and a plain assessment.