Self-Hosted Web App on a Hardened VPS

The problem with apps nobody knows how to run

Many students and junior developers only deploy to platforms that hide the server. That works until a small business, a university society or a freelance client asks you to host something on a cheap VPS, or until a job puts you on call for machines you did not set up. Then the gaps show: password SSH open to the internet, the app running as root inside a tmux session, no backups, and a certificate that expired last week.

Small organisations feel this most. A local clinic, a school or an NGO often has one server that someone set up once, and nobody knows how to restore it. The skills that fix this (users and permissions, firewalls, services, logs, HTTPS, backups and incident handling) are exactly what DevOps and backend roles expect you to have practised.

What already exists and the gap

• Coolify is an open-source, self-hostable alternative to platforms like Vercel and Heroku that deploys apps onto your own servers.
• CloudPanel is a free control panel for hosting PHP, Node.js and Python apps on a server with a simple web interface.
• DigitalOcean's Initial Server Setup guides walk through the first hardening steps on Ubuntu.

Panels are useful, but they add another large piece of software to secure and they hide the same things platforms hide. Tutorials stop after the first steps and never cover restores, incidents or handing the server to someone else. The gap this project fills is a small, documented, reproducible setup that one person can understand end to end, with evidence that it survives failure.

What you build

Pick a real app with a real user: your own earlier project, a society website, or a small tool for a shop. Then:

1. Provision a small VPS and harden it before deploying anything: a named sudo user, key-only SSH, root login disabled, a default-deny firewall and Fail2ban.
2. Run the app as a systemd service under its own user, with secrets in an environment file readable only by that user.
3. Put Caddy or Nginx in front with HTTPS and automatic renewal.
4. Write a deploy script and a backup script, both passing ShellCheck, and schedule backups with systemd timers or cron.
5. Add unattended upgrades, log rotation, disk alerts and an external uptime check.
6. Write the runbook so someone else in your group can recover the server without you.

The technically interesting part

The hard part is not installing packages; it is proving the server recovers. Two things deserve your supervisor's attention.

First, restores, not backups. A backup you have never restored is a guess. Time a full restore onto a fresh server from nothing but the runbook and the backup location, and record every step that was missing from the document.

Second, deliberate incidents. Stop the service, fill the disk in a test folder, break the proxy config, let a certificate expire on a staging subdomain, and lock yourself out of SSH on a throwaway server. For each, show how the logs (journalctl, the proxy access log, the auth log) led you to the cause. This is the same blameless postmortem habit that engineering teams at companies like GitHub and Cloudflare publish about.

How to evaluate it

• Hardening score: run Lynis before and after hardening and explain the remaining warnings you chose to accept.
• Exposure: an external port scan showing only the intended ports open, and SSH rejecting passwords.
• Recovery time: time to restore onto a fresh server, measured twice; the second run should be faster because the runbook improved.
• Incidents: at least four deliberate failures, each with detection time, cause found in logs and fix, written as short postmortems.
• Handover test: a classmate who has not seen the server follows the runbook to deploy a change and restore a backup.

Suggested plan

1. Week 1: choose the app and its user, set a billing alert, provision and harden the server.
2. Weeks 2 to 3: systemd service, reverse proxy, HTTPS, deploy and rollback script.
3. Weeks 4 to 5: backups, restore drill, updates, monitoring and alerts.
4. Week 6: deliberate incidents and postmortems.
5. Weeks 7 to 8: runbook, handover test, Lynis report and demo.

Path to a product

The realistic product is a service, not software. Small businesses, schools and NGOs need someone to host and look after one or two apps. Your first customer is the society or shop whose app you hosted during the project. Offer setup as a one-time fee and care (updates, backups, monitoring, a monthly restore test) as a small monthly retainer. The provisioning script and runbook template become your repeatable kit, and a public write-up of the project is a strong portfolio piece for DevOps and backend roles.

Scope warning

Do not build a control panel or your own PaaS. Do not add Kubernetes, multiple regions or a load balancer for a single small app. Do not spend time on the application's features; the server around it is the project. Never keep secrets in the repository and never leave password login enabled on an internet-facing server.

Learn what you need on Sefism

• DevOps and cloud roadmap : where servers, networking and automation fit in the wider path.
• DevOps and cloud cheat sheet : quick reference for Linux, services and deployment commands.
• Initial Server Setup with Ubuntu (DigitalOcean) : the first hardening steps done properly.
• Linux Upskill Challenge : a month of daily server tasks that match this project closely.
• ShellCheck : catch the quoting and error-handling bugs in your deploy and backup scripts.

Get help with this idea

This project is small in code and large in discipline, so scope and evaluation matter more than stack. Tauseef can help you pick the right app and user, decide what to automate, and plan incident drills your examiners will take seriously. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session