Cloud & server management
A server nobody maintains is an outage with a date on it.
Most small-business server problems are not exotic. They are a full disk, an expired certificate, a backup that has silently failed for months, or an unpatched service exposed to the internet. We set servers up so those things are visible before they become downtime — and we fix them when they already have.
You might need this if
- The site goes down and nobody knows until a customer says so.
- Backups are configured but no one has ever restored from them.
- The server was set up by someone who has moved on, and the SSH key went with them.
- Disk usage has been at 94% for a month.
- A database or admin panel is reachable from the public internet.
- The OS is past end of life and nobody wants to be the one to upgrade it.
What the work covers
Not every engagement includes all of this. The scope is agreed in writing before anything starts.
Initial server hardening
Key-only SSH, a firewall policy with default-deny inbound, automatic security updates, Fail2ban, and no service listening on a public interface that does not need to be.
Deployment and web stack
Nginx or Caddy in front of your application, TLS with automatic renewal, sane resource limits, and a process manager so the application comes back after a reboot.
Monitoring and alerting
Uptime, disk, memory, CPU, certificate expiry and backup success — delivered somewhere a human actually looks, not a dashboard nobody opens.
Backups with tested restores
Off-server, versioned backups of data and configuration, with a restore rehearsed at handover. An untested backup is not a backup.
Patching and maintenance
An agreed cadence for OS and package updates, with reboots scheduled rather than deferred indefinitely, and OS upgrades planned before end of life rather than after.
Incident troubleshooting
Diagnosing what is already broken: 502s, out-of-memory kills, full disks, runaway processes, failed services and slow databases.
How we approach it
- 01
Find out what is actually running
Services, open ports, cron jobs, certificates, disk layout and what depends on what. A surprising amount of this is undocumented on an inherited server.
- 02
Stabilise before improving
Anything actively failing or exposed is dealt with first. Tidying comes after the bleeding stops.
- 03
Make the state visible
Monitoring goes in early, because you cannot judge whether a change helped without a baseline.
- 04
Change with a way back
Snapshot before significant changes, one change at a time, and a written rollback step for each.
- 05
Hand over operable
Access, documentation and runbooks go to you. You should never be locked out of your own infrastructure by the person who set it up.
What you end up with
- A hardened server with a documented firewall and access policy
- Monitoring and alerting routed to a channel you check
- Off-server backups with a restore demonstrated in front of you
- An inventory of services, ports, certificates and scheduled jobs
- A patching schedule and an end-of-life plan for the OS
- Runbook covering deploys, restarts, restores and common failures
Technologies involved
Tools and standards this work is carried out with — listed because they are what the job uses, not as a claim of vendor partnership.
- Ubuntu / Debian
- Docker & Compose
- Nginx
- Caddy
- UFW / nftables
- Fail2ban
- systemd
- restic / borg
- Uptime Kuma
- Hetzner / DigitalOcean
What this will not do
We do not advertise 24/7 staffed support. Monitoring runs continuously and alerts are automated; response is within agreed business hours unless a specific out-of-hours arrangement is in place and written down.
On client examples: we do not publish case studies, logos or testimonials without written permission from the client, and we have none cleared for publication yet. If you need evidence of relevant work before engaging, ask — we will share what we can, appropriately redacted, and say plainly where something was a lab build rather than a client engagement.
Questions about this service
Do you provide a guaranteed uptime figure?
No. A single VPS has no redundancy, so its availability is bounded by the hosting provider’s own, and quoting a number we do not control would be meaningless. What we can commit to is monitoring, an agreed response window, and an architecture discussion if the business genuinely needs redundancy rather than a single server.
Can you take over a server somebody else built?
Yes, and most of this work is exactly that. The first step is an audit, because inherited servers are almost always undocumented. We produce an inventory of what is running and what is exposed before changing anything, so you can see what you have before deciding what to spend on it.
What does ongoing management actually include?
Patching on an agreed cadence, monitoring with alerts routed to a channel you check, backup verification, certificate renewal oversight, and incident response within agreed hours. Anything beyond that — new deployments, architecture changes — is scoped separately so the retainer stays predictable.
Will we be locked into using you?
No. Access, documentation and runbooks are yours throughout, and the configuration uses standard tooling rather than anything proprietary to us. If you move to another provider, they can read what we wrote and pick it up.
Inherited a server nobody understands?
Send us what you know — provider, OS version, what runs on it, what is currently broken. We will tell you what we would check first and what it would take to make it maintainable.