Services
I help small teams and individual site owners with Linux servers, Docker deployments and the infrastructure around them. I am an MSc IT graduate based in the UK, and I run my own production-style server, so the examples below come from systems I have built and maintain myself.
Some honest ground rules. I work best on well-defined, short pieces of work: a server that needs setting up, a deployment that is failing, a config that needs fixing, a backup that needs automating. I cannot promise a fix before I have seen your environment, and I will tell you early if something is outside what I can do well. The examples are my own personal and academic projects, not past client work.
1. Linux VPS setup and troubleshooting
Typical problems: a fresh VPS that needs setting up properly, a service that will not start or keeps crashing, a server that has become slow, a disk that keeps filling up, or a configuration nobody remembers changing.
How I approach it: I start by reading what the server is telling me (systemctl, journalctl, disk, memory and process state) before changing anything, then make small, reversible changes and note each one.
What you can expect: a working configuration, a short written summary of what was wrong and what I changed, and the commands I used so you can repeat or undo them.
Related work: I run and maintain several services on my own Ubuntu VPS. See Setting Up and Managing My Own Servers and the Linux commands I rely on.
2. Docker and Docker Compose configuration
Typical problems: containers that exit immediately, services that cannot reach each other, ports bound to the wrong interface, volumes and environment variables set up incorrectly, or a Compose file that works on one machine and not another.
How I approach it: I read the container logs and the Compose file first, check networks, ports and volumes, and fix the cause rather than restarting until it works. Anything involving volumes and data is handled carefully, and I will not delete a volume without your say-so.
What you can expect: a clean, commented docker-compose.yml, environment settings moved out of the file into .env, and notes on how to bring the stack up and down.
Related work: my monitoring stack is a multi-container Compose deployment configured entirely from files.
3. Nginx reverse proxy and HTTPS setup
Typical problems: an app that only works on its port number, a certificate that will not issue or renew, redirects that loop, 502 errors, or several sites that need to share one server.
How I approach it: I check the app is healthy on its local port first, then build the Nginx server block, test the configuration before reloading it, and set up Let’s Encrypt certificates with automatic renewal.
What you can expect: a working HTTPS site per domain or subdomain, a configuration you can read, and a note on how renewal works.
Related work: my web apps each sit behind Nginx on their own subdomain. See the full-stack hosting case study.
4. DNS and basic networking troubleshooting
Typical problems: a domain that does not point where you expect, a service reachable from one place but not another, intermittent connection drops, or a port that is meant to be closed and is not.
How I approach it: I check from the outside as well as the inside, using dig, ping, traceroute, tcpdump and nmap, because the answer often differs depending on where you test from.
What you can expect: a clear explanation of what is happening on the network path and the change that fixes it, or a precise description of where the problem sits if it is outside your server.
Related work: see Getting Hands-On with Networking Tools and the Linux and networking lab case study. My DNS and DHCP experience is from lab environments rather than production.
5. Linux server security and firewall configuration
Typical problems: a new server with default settings, SSH open to password logins, no firewall, services listening on every interface, or repeated failed login attempts in the logs.
How I approach it: I look at what is actually exposed, then apply a conservative baseline: key-based SSH, a default-deny firewall (UFW), fail2ban, services bound to the interfaces they need, and a check from outside to confirm the result. I take care not to lock you out, and I agree the changes with you first.
What you can expect: a hardened baseline and a short report of what was changed. I do not promise that a server is “secure”, because that depends on everything running on it. I can show you what is exposed and reduce it.
Related work: the secure VOIP infrastructure case study covers a VPN-only service with TLS, UFW and fail2ban.
6. Monitoring with Prometheus and Grafana
Typical problems: no visibility into CPU, memory, disk or network until something breaks, or dashboards that were set up by hand and cannot be recreated.
How I approach it: I deploy Node Exporter, Prometheus and Grafana with Docker Compose, provision the datasource and dashboards from files, and decide with you who can reach the dashboards before anything is exposed.
What you can expect: working dashboards for host metrics, a configuration you can rebuild from the repository, and guidance on what to watch. Alerting rules are possible but are scoped separately.
Related work: the monitoring stack case study and its public repository.
7. Backup scripting and automation
Typical problems: backups done by hand when someone remembers, backups that have never been test-restored, or repeated admin tasks that should be a script.
How I approach it: I write simple, readable Bash or Python scripts using tools such as rsync and cron, log what they do, and explain how to restore. I stress that a backup is only proven when a restore has been tested.
What you can expect: a scheduled backup routine, a short restore procedure, and the script with comments so you can maintain it.
Related work: my server runs scheduled rsync and cron jobs, shown in the Linux and networking lab case study.
8. Deployment troubleshooting and basic infrastructure maintenance
Typical problems: a web app that runs locally but fails on the server, a PHP, Node or Python app that needs a stable process manager, a database connection that fails after a move, or a migration to a new server.
How I approach it: I reproduce the problem, check the logs at each layer (proxy, app, database), and fix one thing at a time. For migrations I plan the cutover and keep a way back.
What you can expect: the app running reliably behind Nginx with a process manager, a note of what was wrong, and a short maintenance checklist.
Related work: I deploy and maintain a PHP and React system and a Node.js and PostgreSQL system on my own server. See the full-stack hosting case study.
How an engagement works
- You describe the problem and your setup in a short message: operating system, what runs on it, what you see, and what you have tried.
- I tell you honestly whether I can help, what information I need, and a rough idea of the time involved.
- I make changes carefully, with your approval for anything that could interrupt a live service, and I keep notes.
- You get a short written summary of what I found and what changed.
I do not need passwords in a message. We can agree on the safest access method together. Anything involving your production data is handled with your explicit permission.