You bought the VPS. You got the IP address in your email. Now you're staring at an SSH prompt wondering what to do next — and whether you're about to do it wrong.
This guide is the one I wish existed when I started. We'll go from zero to a production-ready server with proper security, a real CI/CD pipeline, monitoring, and a modern management interface — without it turning into a 3-day rabbit hole.
Step 1: First Login — Lock It Down Immediately
The moment your VPS is live, bots are already trying to log in. Seriously — check /var/log/auth.log after 10 minutes. You'll see hundreds of attempts.
ssh root@YOUR_IP
Do these five things before anything else:
# 1. Update everything
apt update && apt upgrade -y or dnf update
# 2. Create a non-root user
adduser deploy
usermod -aG sudo deploy
# 3. Copy your SSH key to the new user
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
# 4. Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd
# 5. Set up a basic firewall
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enable
Now install Fail2ban — it automatically bans IPs with repeated failed login attempts:
WARN : IPs will be ban (automatically) / can skip it
apt install fail2ban -y
systemctl enable --now fail2ban
That's your baseline. Your server is no longer an open door.
Step 2: Cockpit — A Browser-Based Control Room for Your Server
Most guides stop at the terminal and never look back. That's fine if you live in SSH, but for monitoring, managing services, updates, and getting a visual overview — Cockpit is genuinely excellent and wildly underrated.
apt install cockpit -y
systemctl enable --now cockpit.socket
ufw allow 9090
Now visit https://YOUR_IP:9090 — log in with your system user.
What Cockpit gives you:
- Real-time CPU, RAM, disk, and network graphs
- Start/stop/restart any systemd service with a click
- Manage users and SSH keys through a UI
- View and filter system logs (journald) visually
- Terminal access right inside the browser — no separate SSH needed
- Container management via the Cockpit Podman extension
- Storage and network interface management
Cockpit vs alternatives:
| Tool | Best For | UI Quality | Cost |
|---|---|---|---|
| Cockpit | Linux system management, services | Clean, minimal | Free |
| Webmin | Full server admin, legacy setups | Dated but powerful | Free |
| Netdata | Deep metrics & alerting | Beautiful | Free/Paid |
| Portainer | Docker/container management | Excellent | Free/Paid |
Cockpit isn't trying to be a hosting panel — it's a system manager. That's exactly why it belongs on every VPS you run.
Step 3: Coolify — Your Self-Hosted Heroku
This is where the fun starts. Coolify handles everything above the OS layer — deployments, databases, SSL, environment variables, reverse proxy, and more.
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
That single command installs Coolify along with Docker, Nginx/Caddy for the proxy, and everything it needs. Then visit http://YOUR_IP:8000 to set it up.
What Coolify manages for you:
- Apps — connect a GitHub/GitLab repo, pick a runtime (Node, PHP, Python, static, Docker), and it builds + deploys automatically on push
- Databases — spin up PostgreSQL, MySQL, MariaDB, Redis, MongoDB with one click. Automatic backups to S3 or local
- Services — one-click deploys for Plausible, Ghost, Uptime Kuma, Meilisearch, n8n, and 60+ more
- SSL — Let's Encrypt, automatic, zero config
- Preview deployments — auto-deploy every PR to its own URL
- Teams — multiple users, role-based access
Coolify vs alternatives:
| Tool | Model | Strengths | Weaknesses |
|---|---|---|---|
| Coolify | Self-hosted | Full-featured, free, open source | Self-managed infra |
| Render | Cloud SaaS | Zero ops, great DX | Gets expensive fast |
| Railway | Cloud SaaS | Easiest for small projects | Limited customization |
| Dokku | Self-hosted | Heroku-compatible, lightweight | CLI-only, steeper curve |
| Caprover | Self-hosted | App store, good UI | Less active development |
Coolify hits the sweet spot: full control, modern UI, no monthly SaaS bill.
Step 4: CI/CD — Push to Deploy Like a Professional
Coolify handles the deployment side. For CI/CD — running tests, linters, builds — you want a pipeline that triggers before Coolify deploys.
The simplest stack: GitHub Actions + Coolify webhook
Create .github/workflows/deploy.yml in your repo:
name: Test & Deploy
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: |
npm install
npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- name: Trigger Coolify Deploy
run: |
curl -X POST "${{ secrets.COOLIFY_WEBHOOK }}" \
-H "Authorization: Bearer ${{ secrets.COOLIFY_TOKEN }}"
Your COOLIFY_WEBHOOK and COOLIFY_TOKEN live in GitHub Secrets. That's it — push to main, tests run, if they pass, Coolify deploys. Full lifecycle, zero babysitting.
CI/CD tool options:
| Tool | Hosting | Best For |
|---|---|---|
| GitHub Actions | Cloud | Most teams — free tier is generous |
| Gitea + Woodpecker CI | Self-hosted | Full self-hosted Git + CI stack |
| GitLab CI | Cloud or Self-hosted | Monorepos, enterprise pipelines |
| Drone CI | Self-hosted | Docker-native, YAML pipelines |
If you want to go fully self-hosted, Gitea (lightweight GitHub alternative) + Woodpecker CI is a beautiful combo that runs comfortably on a small VPS.
Step 5: Monitoring — Know Before Users Tell You
Your pipeline is live. Now make sure you know when something breaks before your users do.
Uptime Kuma — Self-Hosted Status Page + Alerting
Deploy it via Coolify in two clicks (it's in the service catalog). Uptime Kuma monitors your URLs, TCP ports, databases, and Docker containers, and alerts you via Telegram, Slack, email, Discord, and more.
It also generates a public status page — the kind you'd pay $30/month for from a SaaS tool.
Netdata — Real-Time System Metrics
Where Cockpit gives you a system overview, Netdata goes deep. Per-process CPU and memory, disk I/O breakdowns, network packet analysis, and anomaly detection — all in real time, with a gorgeous UI.
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh
Runs on port 19999. Keep it behind a firewall or add basic auth — don't expose it publicly.
Loki + Grafana — Logs That Actually Make Sense
For production apps, structured log aggregation is worth it. Grafana Loki collects logs, Grafana visualizes them alongside metrics. Coolify can deploy the Grafana stack for you.
Monitoring quick-reference:
| Tool | What It Covers | Effort |
|---|---|---|
| Uptime Kuma | Uptime, SSL expiry, status page | ⭐ Very easy |
| Cockpit | System resources, services | ⭐ Very easy |
| Netdata | Deep system metrics, anomalies | ⭐⭐ Easy |
| Grafana + Loki | Logs, dashboards, alerting | ⭐⭐⭐ Moderate |
| Prometheus + Grafana | Full observability stack | ⭐⭐⭐⭐ Advanced |
Start with Uptime Kuma and Cockpit. Add Netdata when you want more visibility. Add Grafana when you're running real production load.
The Full Stack, Summarized
Here's what your VPS looks like after following this guide:
OS Layer → Ubuntu 24.04, hardened SSH, UFW, Fail2ban
System UI → Cockpit (browser-based management + monitoring)
App Platform → Coolify (deployments, databases, SSL, services)
CI/CD → GitHub Actions (tests + webhook trigger)
Uptime → Uptime Kuma (monitoring + status page)
Metrics → Netdata (deep real-time system metrics)
Logs → Grafana + Loki (when you're ready)
You went from a blank VPS to a modern, self-hosted platform that handles deployments, rollbacks, SSL, monitoring, and alerting — with a UI for everything that doesn't require you to live in the terminal.
That's not DevOps complexity. That's just good infrastructure.
What's your current VPS stack? Drop your setup in the comments — always curious what people are running in production.
Top comments (3)
Exactly.....
I would rather have a small fire in a fireproof room than a single spark in a forest.
Tools like Uptime Kuma and Netdata are essentially the smoke detectors for our sanity.
If you can’t see it failing, you can’t fix it fast.
Great insight on the 'blast radius'!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.