Who this is for
Founders and small teams whose product or store runs on servers nobody fully owns: the hosting was set up by a previous developer, backups exist but have never been restored, disk fills up on campaign days, and every deployment is done by hand with fingers crossed.
I operate the Linux servers under my own products and under the stores I look after: web panels on CentOS and Ubuntu, Nginx, PHP-FPM, MySQL and PostgreSQL, Redis, Docker with CapRover, VMware virtual machines and AWS where it fits. This is not a managed hosting product; it is the operating work a senior engineer does so the application work stays safe.
Typical situations
- The server ran out of disk, memory or PHP workers during a campaign and nobody saw it coming.
- Backups run nightly to the same disk, and nobody has ever tried a restore.
- Error logs grow by gigabytes a day because of one plugin, and the disk alarm is the first sign.
- A site was compromised and the cleanup was a plugin scan; the entry point is still open.
- Deployments are FTP uploads to production; there is no staging and no way back.
- Several sites share one server and one of them takes the others down.
What I deliver
- Server setup and hardening on Linux: Nginx or Apache, PHP-FPM pools, MySQL or PostgreSQL, Redis, firewall, SSH access, updates, with the configuration in version control.
- Backups with restore drills: what is backed up, where, how often, how long it takes to restore, tested on a schedule and written down.
- Monitoring and alerts that reach a person: disk, memory, PHP workers, queue depth, certificate expiry, error rate, uptime.
- Deployment paths with staging and rollback: CI/CD pipelines, Docker with CapRover for products, zero-downtime releases for stores, a tested way back.
- Virtualisation and moves: VMware virtual machines, moves between hosts or to the cloud, capacity planning from real load.
- Incident response and cleanup: finding the cause, removing what an attacker left, log hygiene, and a written post-mortem so it does not repeat.
How it goes
Inventory and risk. What runs where, who has access, what is backed up, what alerts exist and what would happen if the disk died tonight. The first output is a written list of risks, ordered by damage and likelihood.
Fix the risks in order. Backups and a tested restore come first, then monitoring, then the deployment path. Each change is made in a maintenance window with a way back.
Hand over or keep operating. Everything ends in a document the next person can use: access, configuration, runbooks for the common failures. On a retainer I keep operating and send a short monthly note.