What I build

The path from a merged pull request to running code, made boring. Containerised builds, CI/CD pipelines, provisioned Linux servers, TLS, backups, monitoring, and the runbooks that let somebody other than me handle an incident.

At IT-Plus, moving releases onto GitHub Actions made deployments 30% faster and removed the manual steps that made them risky. At Softa I operated between 6 and 15 production servers, which is where you learn what actually breaks at three in the morning.

How I work

Automate the release before optimising anything else. A deployment that is one reviewed merge is a deployment people are willing to do often, and shipping often is what makes every other engineering practice cheaper.

Infrastructure choices stay proportional. Most products do not need Kubernetes; they need Docker, a tested pipeline, two well-configured servers, and a restore procedure somebody has actually rehearsed.

What you get

• Dockerised builds that behave the same on a laptop, in CI and in production.
• GitHub Actions pipelines covering tests, linting, database migrations and zero-downtime deploys.
• Hardened Linux hosts behind Nginx or Apache, with TLS, firewall rules and least-privilege access.
• Backups that are scheduled, off-site and restore-tested — an untested backup is not a backup.
• Written runbooks and a proper handover, so your team can deploy, roll back and diagnose without calling me.

The stack

Docker and GitHub Actions on Linux, with Nginx or Apache in front. Hosting on AWS, DigitalOcean, Hetzner, Contabo or cPanel, chosen for your budget and your compliance constraints rather than out of habit.

A good fit if

Deployments are a manual ceremony only one person can perform, releases keep slipping because nobody trusts the process, or you are moving off shared hosting onto infrastructure you control.