As engineers, we often fall into the perfectionism trap. I know this all too well - my history is littered with unfinished SaaS projects, each one stuck in an endless cycle of improvements and tweaks, never quite "ready" for launch.

But last week, something changed. At 3AM, while thinking about self-hosting, a simple question popped into my head: "What if there was a tool that could instantly tell you if your VPS is secure?"

Instead of my usual approach of extensive planning, feature-creep, and polishing, I decided to do something different. The next morning, I sat down and built a basic bash script prototype. Nothing fancy - just something that could check for common VPS security issues - and I shared it on my X profile.

The 7-Day Challenge

The unexpected enthusiasm from the community sparked something in me. Rather than falling back into my old perfectionist habits, I decided to turn this momentum into a challenge: Could I ship a complete, working product in just 7 days? No perfectionism allowed. No "just one more feature."

And I actually did it. In those 7 days, while posting my entire journey on X, I built:

• A bash script that runs security checks on a VPS

• A backend service that receives and processes the checks from the aforementioned script

• A web frontend that displays the checks in real-time

• Clear explanations and mitigation steps for each security check (actually this one didn't quite cut it for the MVP)

The Launch

After exactly 7 days of focused evening (and late night) work, I launched AuditVPS. No beta period. No endless polishing. Just a working tool that helps self-hosters secure their servers.

The response was immediate – 1K website visits within the first day (I’ve made the analytics public, if you’re interested). This wasn't just validation of the tool's usefulness; it proved that sometimes the best approach is to ship quickly and let real users guide your next steps. And apparently others thought so too – within 24 hours, I spotted my first copycat. I'd barely launched and someone was already cloning it. If that’s not validation, I don’t know what is!

Key Learnings

1. Perfect is the enemy of done. My previous pattern of infinite refinement had kept many potentially useful tools from ever seeing the light of day.

2. Users value solutions over perfection. A working tool that solves a specific problem today is better than a perfect tool that launches "someday."

3. Real feedback is invaluable. Launching quickly means you can start learning from actual users rather than assumptions.

4. Speed has its costs. While the 7-day sprint was exciting, the intense schedule alongside a full-time job meant sacrificing sleep, exercise, and social time. Next time, I'll aim for a more sustainable pace that lets me ship quickly without burning out.

5. Being part of a community is a game-changer. When I shared my progress, people jumped in to offer help, security suggestions, and encouragement. Accepting their support (thank you!) not only improved the product but helped maintain momentum through the intense week.

What's Next?

AuditVPS is and will remain free, with plans to introduce a sponsorship-based monetization model. I've also open-sourced the core audit script on GitHub because I believe security tools should be transparent and accessible to everyone.

While I have many ideas for future features, I'm breaking another old habit: instead of building what I think users want, I'm listening to the community first. What security checks would you find most valuable? How could this tool better serve your needs? Leave a comment below or reach out on X.

This is just the beginning of the AuditVPS journey. Sometimes, the best projects don't come from months of careful planning, but from a random 3AM thought and the courage to ship quickly.

Check it out at AuditVPS.com, and if you find the project useful, please consider starring it on GitHub. It would really help with exposure (and staying ahead of the copycats!).

Why use Grafana and Prometheus on your VPS

Ever wondered what's really going on inside your VPS? Grafana and Prometheus are your go-to tools for keeping tabs on your server's performance. They're a fantastic combo for indie hackers like us - they're free, open-source, and they get the job done without the overhead of enterprise solutions.

Here's what makes them a great option:

• See everything in real-time: Monitor your server metrics as they happen

• Pretty dashboards: Grafana turns numbers into useful charts

• Zero cost: It's open-source, so no surprise bills or vendor lock-in

• Large community: Tons of pre-made dashboards and help when you need it

The best part? You don't need to be a Linux wizard to set this up. If you can follow simple instructions and aren't afraid of the command line, you're good to go. Let's dive in and get your VPS properly monitored.

What you’ll need before we start

Before we dive in, let's make sure you've got the basics sorted. Nothing fancy - just Docker and a user account that can run sudo commands.

Here's your quick checklist:

• A user with sudo

• Docker installed and running

If you've got these three things, you're ready to go. Not sure if you have everything? Run these commands to check:

# Verify sudo access
$ sudo whoami

# Check Docker installation
$ docker --version

Setting up Prometheus & Grafana

Let's get these tools installed and running. We'll use Docker Compose to keep things clean and simple. I'll walk you through it step by step.

First, create a compose.yaml file:

services:
  prometheus:
    image: prom/prometheus
    ports:
      - '9090:9090'
    volumes:
      - ./prometheus:/etc/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    restart: always

  grafana:
    image: grafana/grafana
    ports:
      - '3000:3000'
    depends_on:
      - prometheus
    restart: always

  node_exporter:
    image: quay.io/prometheus/node-exporter:latest
    container_name: node_exporter
    command:
      - '--path.rootfs=/host'
    ports:
      - '9100:9100'
    restart: unless-stopped
    volumes:
      - '/:/host:ro,rslave'

This sets up three containers:

• Prometheus - collects and stores your metrics

• Grafana - visualises those metrics into dashboards

• Node Exporter - grabs system stats like CPU and memory usage

Next, create a configuration file for Prometheus. Make a new directory called prometheus and create a prometheus.yaml file inside it:

global:
  scrape_interval: 10s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['node_exporter:9100']

This tells Prometheus two things:

• Collect new metrics every 10 seconds

• Look for those metrics at node_exporter:9100 (that's the Node Exporter container we defined earlier)

That's all we need for now. Prometheus will store these metrics, and we'll use Grafana to visualise them in the next step.

Accessing your monitoring stack over SSH

Time to start your monitoring stack and connect to it securely. I'll show you how to do this without exposing any of the services to the public internet.

First, start up your containers:

$ docker compose up -d

Now, we could just open these ports on our VPS firewall, but that's not the most secure approach. We’d rather keep the ports locked down, and instead connect to them over SSH, using something called port forwarding.

If you haven’t already setup a firewall on your VPS, check out my article on how to secure your VPS. The only ports that should be exposed are 22 for SSH and 80/443 for HTTP/HTTPS if you’re running a web server.

Open two terminal windows on your local machine and run these commands (replace user@12.34.45.67 with your VPS details):

# Terminal 1 - Grafana tunnel
$ ssh -N -L 3000:127.0.0.1:3000 user@12.34.45.67

# Terminal 2 - Prometheus tunnel
$ ssh -N -L 9090:127.0.0.1:9090 user@12.34.45.67

This creates secure tunnels from your computer to your VPS. Now you can access everything through your browser on your local machine at:

• Grafana: http://localhost:3000

• Prometheus: http://localhost:9090

Let's make sure everything's working. Open Prometheus at http://localhost:9090 in your browser, click Status > Targets. You should see your node exporter listed as "UP" - that means Prometheus is successfully collecting your system metrics.

Looking good? Let's set up Grafana next.

Connecting Grafana to your data

Let's get Grafana talking to Prometheus. First thing's first - log into Grafana:

1. Open http://localhost:3000 in your browser

2. Use these default credentials:

   1. Username: admin

   2. Password: admin

3. Set a new, strong password when prompted - especially important if you ever plan to expose this to the internet

Now, let's point Grafana to your Prometheus data:

1. Click Connections > Data sources in the left sidebar

2. Hit Add data source

3. Choose Prometheus from the list

4. For the URL, enter http://prometheus:9090

5. Scroll down and click Save & test

You should see a green success message. If you do, congrats! Grafana can now see all your metrics. If not, double-check that URL - the most common gotcha is using localhost instead of prometheus as the hostname.

Creating your first dashboard

Rather than building a dashboard from scratch (which takes time), let's grab a pre-made one that works perfectly with our Node Exporter.

Here’s how:

1. Click Dashboards in the left sidebar

2. Hit New > Import in the top right

3. Enter 1860 - this is the ID for the dashboard template Node Exporter Full

4. Click Load

5. Give your dashboard a name if you want, or keep the default

6. Select your Prometheus data source from the dropdown at the bottom

7. Click Import

You should now see a complete dashboard showing all sorts of system metrics: CPU usage, memory, disk space, network traffic, basically everything you would ever need to monitor host-level resources.

Adding Docker metrics to your dashboard

Since we're running everything in Docker anyway, let's monitor our containers too. We'll tell Docker to expose its metrics and get Prometheus to collect them.

First, let's configure Docker to make its metrics available:

# Create or edit the Docker daemon config
$ sudo vim /etc/docker/daemon.json

# Add this configuration
{
  "metrics-addr": "0.0.0.0:9323"
}

# Restart Docker to apply changes
$ sudo systemctl daemon-reload

Quick test to make sure it's working:

$ curl localhost:9323/metrics

You should see a bunch of metrics like builder_builds_failed_total and others.

Here comes the tricky part - if you're using UFW with ufw-docker (as I recommend to do in my Docker article), we need to allow Prometheus talk to Docker. We'll do it safely such that inbound traffic to Docker is only allowed by internal IPs:

# Allow Docker's internal network to access the metrics
$ sudo ufw allow from 172.16.0.0/12 to any port 9323
$ sudo ufw reload

💡 Quick networking note: 172.16.0.0/12 is Docker's internal network range. We're only allowing connections from inside this network, so it cannot be accessed from the public internet.

Now let's tell Prometheus about these new metrics. Edit your Prometheus config:

$ vim prometheus/prometheus.yaml

Add this under scrape_configs:

  - job_name: docker
    static_configs:
      - targets: ['host.docker.internal:9323']

We also need to modify our compose.yaml file to tell Prometheus about this special Docker host:

$ vim compose.yaml

# add the following as a direct child under the prometheus service
    extra_hosts:
      - "host.docker.internal:host-gateway"

Restart Prometheus to pick up the changes:

$ docker compose restart prometheus

To verify everything's working, check http://localhost:9090/targets - you should see a Docker target marked as "UP".

Creating a custom dashboard

Let's make a simple dashboard to monitor your Docker containers. We'll build this one from scratch.

Here's how:

1. Go to Dashboards and click New > New dashboard

2. Click the big + Add visualization button

3. Pick Prometheus as your data source

4. Change the visualization type from Time series to Stat in the top right

5. In the query box at the bottom, paste this:

engine_daemon_container_states_containers

6. Under Options, find the Legend section and set it to Custom with value {{state}}

7. Hit Run queries

You should now see a clean visualisation showing how many containers you have running, paused, or stopped. Neat, right?

💡 Want to explore more Docker metrics? Head to Prometheus at http://localhost:9090/graph and try this query: {job="docker"}. This shows you every Docker metric available to interact with!

Give your dashboard a name, hit save, and you're done! Feel free to experiment - add more panels, try different visualisations, or even add exporters for metrics from other systems. That's the good part about Grafana and Prometheus - you can customise everything to show exactly what you want to see.

And that’s a wrap

You've just set up a proper monitoring system for your VPS - pat yourself on the back! Yes, it took a bit more work than clicking an install button, but now you've got something super flexible up and running.

Here's what you've accomplished:

• Got Prometheus, Grafana, and Node Exporter running using Docker Compose

• Set up Docker to expose its own metrics

• Configured your firewall safely to allow internal collection of Docker metrics

• Got Prometheus collecting metrics from both your system and Docker

• Set up two dashboards:

  • A pre-made one for host-level metrics

  • A custom one for Docker stats

💡 Pro tip: If you’re feeling adventurous, look into Prometheus alerting. You can set up alerts for things like high CPU usage, low disk space, when containers crash, and much more.

Your VPS is no longer a black box - you can now see exactly what's going on inside it. Happy self-hosting!

Introduction

This article builds on my previous guide about deploying a Docker web server on a VPS. While functional, the current setup exposes the server directly on port 80 without TLS encryption. We'll address these limitations by adding Nginx as a reverse proxy and securing traffic with TLS using LetsEncrypt certificates.

Prerequisites:

• A Docker web server running on port 80

• A domain or subdomain with DNS management access

Understanding Nginx and deployment options

Overview

Nginx is a mature web server that functions both as a reverse proxy and static file server, amongst other things. As a reverse proxy, it provides an additional security layer by concealing backend implementation details and offers features like rate limiting, TLS termination, request routing, and much more.

Deployment Approaches

When setting up Nginx as a reverse proxy, you'll need to choose between installing it directly on your host system or running it as a containerized service. Each approach has distinct implications for how Nginx interacts with your backend services, manages configurations, and handles TLS certificates. The choice largely depends on your existing infrastructure and personal preferences.

Host installation

Running Nginx directly on the host offers several advantages:

• Ability to proxy to any service, containerized or not

• Direct access to host filesystem for static content

• Simpler initial setup and configuration

Key limitations:

• Management and monitoring separate from Docker ecosystem (via systemd)

• Docker services must expose host ports for Nginx connectivity

• Scaling up a Docker service using replicas will lead to port conflicts, since two containers cannot listen on the same host port. To work around this each replica needs to listen on a different host port and Nginx needs to be configured to be aware of them, so that it can balance the load across them.

Docker installation

Deploying Nginx in a container provides:

• Native Docker network integration.

• Automatic DNS resolution between containers

• Can make use of Docker’s built-in load balancing for scaled services. Services are scaled up and down without having to modify the Nginx configuration. (That being said, Nginx load balancing is more feature-rich than Docker’s.)

However, this approach requires:

• Volume management for configuration and TLS certificates

• More complex initial configuration

• Additional networking setup to proxy traffic to non-containerized services running on the host

This article will focus on the first method, host installation, as it provides greater flexibility for proxying both containerized and traditional services, and is the simpler of the two.

Initial setup

Before installing Nginx, we need to prepare the host system. Since Nginx will handle incoming traffic on port 80, we'll need to stop any existing services using that port. In our case, that's the Docker container from the previous article:

$ docker stop app

Next, we'll configure the firewall to allow HTTP and HTTPS traffic. Ubuntu's UFW (Uncomplicated Firewall) provides a straightforward way to manage these rules:

$ sudo ufw status

Expected output:

Status: active

To                         Action      From
--                         ------      ----
Nginx Full                 ALLOW       Anywhere
Nginx Full (v6)            ALLOW       Anywhere (v6)

If you don't see these Nginx rules, add them:

$ sudo ufw allow 'Nginx HTTP'

This single rule enables both HTTP (port 80) and HTTPS (port 443) traffic. If your firewall isn't active yet:

$ sudo ufw enable

Installing Nginx

On Debian systems, install Nginx using apt:

$ sudo apt update
$ sudo apt install nginx

For other distributions, refer to the official installation instructions

After installation, Nginx starts automatically. Verify the service status:

$ systemctl status nginx

Expected output:

● nginx.service - A high performance web server and reverse proxy server
     ...
     Active: active (running) since Sun 2024-10-13 16:26:23 UTC; ...

To verify the installation, we'll access Nginx's default landing page. First, find your VPS's public IP address:

$ curl ip.now

Example output:

12.34.56.78

Visit this IP address in your browser. You should see the default Nginx welcome page, confirming that both the installation and port 80 access are working correctly.

Understanding Nginx configuration

Default configuration

Let's examine Nginx's default configuration at /etc/nginx/sites-available/default to understand how Nginx handles requests:

$ cat /etc/nginx/sites-available/default

The key components are:

listen 80 default_server;
listen [::]:80 default_server;

This configures Nginx to accept both IPv4 and IPv6 connections on port 80. The default_server directive makes this block handle any requests that don't match other server blocks.

root /var/www/html;

root defines the base directory for static file serving. We’ll explore this soon.

index index.html index.htm index.nginx-debian.html;

index the file lookup order within the root directory.

server_name _;

The underscore (_) is a catch-all character that makes this server block catch all unmatched domain requests. Currently, there are no other server blocks, so this will catch all requests.

location / {
    try_files $uri $uri/ =404;
}

This location block implements a simple request handling logic:

1. Attempt to serve the exact URI

2. Try serving it as a directory

3. Return 404 if nothing matches

To find the default landing page, take a look at the directory that root is pointing to:

$ ls /var/root/html
index.nginx-debian.html

While we'll be configuring Nginx as a reverse proxy rather than a static file server, understanding this default configuration provides context for our next steps.

Configuring Nginx as a reverse proxy

While we could modify the default configuration to set up our reverse proxy, it's better to create a separate configuration file for each domain. This approach makes it easier to manage multiple services and domains on a single VPS.

We'll create a new configuration file named after our domain. Using the domain name as the filename is a common convention that makes it clear which service the configuration belongs to:

$ sudo vim /etc/nginx/sites-available/api.kkyri.com

You should replace api.kkyri.com with your own domain

Add this configuration:

server {
    listen 80;
    listen [::]:80;

    server_name api.kkyri.com;

    location / {
        proxy_pass http://localhost:8080;
        include proxy_params;
    }
}

Let's break down what makes this configuration different from the default:

• server_name api.kkyri.com tells Nginx to apply this configuration only for requests to this specific domain (it looks at the request’s Host header to determine this)

• proxy_pass forwards requests to our application instead of serving static files

• include proxy_params adds standard proxy headers like X-Real-IP and X-Forwarded-For, which help our application understand the origin of the request

This domain-based configuration approach is particularly powerful - you can host multiple services on your VPS by creating additional server blocks with different domain names, each proxying to their respective services. For example, I could add another configuration for docs.kkyri.com, which points to a different underlying service.

Enable the configuration by creating a symbolic link in sites-enabled:

$ sudo ln -s /etc/nginx/sites-available/api.kkyri.com /etc/nginx/sites-enabled/

Validate the configuration:

$ sudo nginx -t

Before restarting Nginx, we'll need to ensure our application is running on port 8080. Let's handle that in the next section.

Setting up the backend service

Now we need to reconfigure our Docker service to run on port 8080 instead of 80, matching our Nginx configuration.

Update the port mapping in your compose.yaml:

services:
  app:
    image: app:latest
    container_name: app
    ports:
      - "8080:8080" # Changed from 80:8080
    ...

The port mapping format is HOST_PORT:CONTAINER_PORT. We're changing only the host port since that's what Nginx will connect to. The container's internal port remains the same.

Deploy the changes:

$ docker compose up -d

Finally, apply the new Nginx configuration:

$ sudo systemctl reload nginx

At this point, Nginx should be forwarding requests from port 80 to your application running on port 8080. The next step is configuring DNS to route traffic to your VPS.

Configuring DNS records

While Nginx is now set up to proxy requests, we need to configure DNS to route domain traffic to our VPS. Currently, accessing your VPS's IP address directly still shows the default Nginx page because the request isn’t originating from the domain name we configured.

At your domain registrar's DNS settings, you'll need to add one of the following:

• An A record if your VPS has a static IP:

Type: A
Name: api.kkyri.com
Value: 12.34.56.78

• A CNAME record if your VPS provider gives you a domain name:

Type: CNAME
Name: api.kkyri.com
Value: kkyri-api.provider.com

Most VPS providers assign static IPs, making the A record the more common choice. However, if you're using a platform that provides a domain name by default instead, use a CNAME record.

After configuring DNS, changes can take anywhere from a few seconds to several hours to propagate through the DNS network. Once propagation is complete, visiting your domain should show your application's response:

Hello, World!

Debugging connection issues

If your application isn't accessible through your domain, there are several layers to check. Let's go through them systematically.

DNS resolution

First, verify your DNS configuration using the dig command:

# For A records
$ dig api.kkyri.com A

;; ANSWER SECTION:
api.kkyri.com    60    IN    A    12.34.56.78

# For CNAME records
$ dig api.kkyri.com CNAME

;; ANSWER SECTION:
api.kkyri.com    60    IN    CNAME    kkyri-api.provider.com

Look for the ANSWER sections and verify they’re pointing to the expected IP address or domain.

Nginx logs

Nginx maintains two primary log files that are useful for debugging:

• Access logs show incoming requests. Each request should result in a log line:

$ sudo tail -f /var/log/nginx/access.log
192.168.1.1 - - [27/Oct/2024:21:15:23 +0000] "GET / HTTP/1.1" 200 ...

• Error logs show configuration issues or other errors:

$ sudo cat /var/log/nginx/error.log

Application logs

If DNS resolves correctly and Nginx logs show incoming requests, check your application:

1. Verify the container is running:

$ docker ps
CONTAINER ID   IMAGE  STATUS         PORTS                   NAMES
9e28276170ab   app    Up 30 minutes  0.0.0.0:8080->8080/tcp  app-1

2. Check container logs:

$ docker logs app-1
Server is listening on :8080...

If it’s not doing it already, consider modifying your application code to log incoming requests, to assist you with debugging. Remember to restart your container after any code changes.

This layered approach helps isolate whether the issue is with DNS resolution, Nginx configuration, or the application itself.

Enabling HTTPS with Certbot

Prerequisites

Before proceeding, ensure:

• Your domain is correctly pointing to your VPS (verify with dig and/or your browser)

• Nginx is properly configured and serving requests

• Port 80 and 443 is open in your firewall

Installing Certbot

To serve traffic over HTTPS, we need TLS certificates. Let's Encrypt provides these certificates for free, and we'll use Certbot to automate their management. We'll also use Certbot's Nginx plugin to automatically configure TLS in our Nginx server.

Install Certbot and the Nginx plugin:

$ sudo apt install certbot python3-certbot-nginx

Generate a certificate for your domain:

$ sudo certbot --nginx -d api.kkyri.com

The domain you pass to Certbot must be the same domain you configured in your Nginx server block.

This command does several things:

• Verifies your domain ownership

• Generates TLS certificates

• Updates your Nginx configuration to use these certificates

• Sets up automatic HTTP to HTTPS redirection

Certificates are valid for 90 days. Certbot sets up automatic renewal via a systemd timer:

$ sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Sat 2024-10-12 10:49:21 UTC; 2min 52s ago
    Trigger: Sat 2024-10-12 16:19:52 UTC; 5h 27min left
   Triggers: ● certbot.service

Oct 12 10:49:21 vps systemd[1]: Started Run certbot twice daily.

(Optional) To test the renewal process:

$ sudo certbot renew --dry-run

This will simulate a renewal for your domain.

To understand the changes that Certbot made to your Nginx configuration, open it:

$ cat /etc/nginx/sites-available/api.kkyri.com

Certbot has added:

• Certificate paths

• TLS configuration

• HTTP to HTTPS redirect

• Port 443 listener

Note that Nginx still communicates with your backend service over HTTP internally. This is secure as it happens within your local network, and it simplifies your application architecture by handling TLS termination at the Nginx level.

Your site should now be accessible via HTTPS, with browser security indicators confirming the valid certificate.

Summary

Well done! The setup is now complete. You have:

• A reverse proxy handling incoming traffic

• Automatic HTTPS encryption with Let's Encrypt certificates, and automatic renewal

• Your domain properly configured and routing to your VPS

• Routing completely decoupled from your service

The infrastructure you’ve configured thus far is secure and maintainable while remaining simple. From here, you could explore features like rate limiting, monitoring, or hosting additional services on the same VPS.

The best part? You did it all yourself. Until next time!

Introduction

You've got your VPS up and running, but now comes the real challenge: deploying your web app. With the amount of options out there, it's easy to get lost in the possibilities.

This guide will walk you through a battle-tested method using Docker. We'll cover the essentials:

1. Docker and container basics

2. Building your own Docker images

3. Deploying containers on your VPS

I've designed this tutorial to be hands-on, so feel free to follow along. Whether you're a seasoned developer or just getting started, I think you’ll find value in adopting this deployment strategy. Let's dive in.

Docker: Swiss Army Knife of self-hosting

What is Docker?

Docker is a containerization platform that facilitates application deployment. It packages an application with its code, dependencies, and settings into a container, ensuring consistent environments across various platforms - from your local machine to your VPS.

Why Docker?

As an indie hacker, you might think you need a complex stack of deployment tools, but Docker alone can take you surprisingly far. This battle-tested containerization platform offers everything most solo developers need:

1. Dead-simple deployment: One command to package and run your entire app

2. Zero cost: Completely free and open-source

3. Self-healing services: Automatic restarts when things crash

4. Built-in logging: All your logs in one place, no extra tools needed

5. Performance insights: Monitor memory and CPU usage out of the box

6. Resource control: Set limits to keep your services from misbehaving

Before reaching for Coolify or other “all-in-one” tools, remember that Docker by itself can handle most deployment scenarios you'll encounter as a solo developer. Keep it simple, ship faster.

Setting Up Docker

You'll need Docker on both your local machine and VPS. Let's get started.

Installation on your local machine:

1. Visit the official Docker website

2. Follow the installation guide for your OS

3. Verify the installation:

docker --version

Installation on your VPS (Ubuntu):

1. Follow Digital Ocean's guide (steps 1 & 2)

2. Verify the installation:

docker run hello-world

You should see a "Hello from Docker!" message, confirming a successful setup.

If your VPS is not running Ubuntu, check out the official installation guide for your operating system.

Building your Docker image

From code to image

Remember the hello-world container you ran earlier? That was a running instance of a Docker image. An image is the blueprint in Docker, containing your application code and everything it needs to run.

Let's create an image for a web app. We'll use a simple Go web server, but the same principles apply to any language. The beauty of Docker is that once you have an image, the deployment process is identical regardless of the underlying programming language used.

Feel free to follow along with Go - just make sure you have it installed first. Alternatively, use a language of your choice. If you choose to use a different language, some steps during image creation might differ slightly.

To setup your service, start by creating a directory on your local machine:

mkdir app
cd app

Initialize a Go module:

go mod init app

Create a main.go file with a basic HTTP server:

package main

import (
    "fmt"
    "net/http"
)

func helloHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello, World!")
}

func main() {
    http.HandleFunc("/", helloHandler)
    fmt.Println("Server is listening on :8080...")
    http.ListenAndServe(":8080", nil)
}

Test your server:

go run main.go

You should see "Server is listening on :8080...". Once confirmed, kill the server. Now we're ready to create an image out of this.

Creating an image

There are two primary methods to create a Docker image: manually defining a Dockerfile or using a higher-level tool like nixpacks. Let's explore both options.

Option 1: The Dockerfile approach

This method is more hands-on and language-specific, but it often results in faster builds and smaller image sizes.

On your local machine, create a Dockerfile in your app directory:

FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod ./
RUN go mod download
COPY *.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o app

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/app ./
EXPOSE 8080
CMD ["./app"]

This Dockerfile uses a multi-stage build to create a compact image. It exposes port 8080, matching our web server's configuration.

Now that you have a Dockerfile, build the image:

docker build --platform linux/amd64 -t app:latest .

We specify the linux/amd64 platform to ensure compatibility with our VPS.

Verify the image:

docker images

You should see output similar to:

REPOSITORY  TAG              IMAGE ID       CREATED         SIZE
app         latest           3875e8cecccf   5 seconds ago   8.2MB

(Optional) Test the image:

docker run -it app

You should see the "Server is listening..." output. Note that this may not work on your local machine if your architecture differs from linux/amd64.

If you're interested in an alternative approach, continue to the next section about nixpacks. Otherwise, feel free to skip ahead to learn how to run this on your VPS.

Option 2: Simplifying with nixpacks

If you’re looking for a more streamlined approach, nixpacks offers an abstraction layer that eliminates the need for a Dockerfile, simplifying the image-building process.

Install nixpacks (for macOS users):

brew install nixpacks

For other operating systems, consult the official nixpacks website.

Build your image:

CGO_ENABLED=0 nixpacks build . --platform linux/amd64 --name app

Note: the CGO_ENABLED=0 is only required if you’re building a Go app.

Verify the image:

docker images

You should see output similar to:

REPOSITORY  TAG              IMAGE ID       CREATED         SIZE
app         latest           7ca012c83587   9 seconds ago   33.7MB

Comparing approaches

If you've followed both options, you'll notice the nixpacks image size is significantly larger (about 300% in this case). This illustrates the trade-off: nixpacks offers simplicity and language agnosticism, while a custom Dockerfile allows for optimization at the cost of complexity.

(Optional) Test the image:

docker run -it app

You should see the "Server is listening..." output. Note that this may not work if your local machine architecture differs from linux/amd64.

Deployment: bring it all together

Docker Compose: your orchestration friend

Docker Compose extends Docker's functionality by managing single and multi-container applications. Using a single YAML file, it lets you define, connect, and run multiple services in one go. It also handles the entire container lifecycle - from startup and shutdown to networking and volume management. Since it comes bundled with Docker, we'll use it to streamline our application setup and deployment.

On your VPS, create a compose.yaml file:

services:
  app:
    image: app:latest
    container_name: app
    ports:
      - "8080:8080"
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256MB

This configuration maps port 8080 from the host to the container and sets CPU and memory resource limits. While these latter ones are optional, they prevent a single container from hogging your entire VPS resources.

With this file, all we need is the Docker image present on our VPS.

Transferring your image to the VPS

To get your locally-built image onto your VPS, copy the image over using SSH. On your local machine:

docker save app:latest | gzip | ssh user@12.34.56.78 docker load

Note: This may take some time depending on your image size and network speed.

Verify the transfer:

ssh user@12.34.56.78
docker images

You should see output similar to:

REPOSITORY  TAG                 IMAGE ID       CREATED         SIZE
app         latest              5dd6c8c8a032   7 minutes ago   15.8MB

Now that all the pieces are in place, let's get your application up and running.

Launching your Dockerized app

On your VPS, navigate to the directory containing your compose.yaml file and run:

docker compose up -d

The -d flag runs it in detached mode, allowing you to continue using the terminal.

Verify the running container:

docker ps

You should see output similar to:

CONTAINER ID   IMAGE       COMMAND   PORTS                   NAMES
17bec024dcce   app:latest  "./app"   0.0.0.0:8080->8080/tcp  app

Monitor your app by viewing logs:

docker logs app

Or by checking its resource usage:

docker stats app

Test the service is running:

curl localhost:8080

Expected output:

Hello, World!

Streamlining deployments

To simplify future updates, create a deployment script deploy.sh on your local machine:

#!/bin/bash
docker build --platform linux/amd64 -t app:latest .
docker save app:latest | gzip | ssh user@12.34.56.78 docker load
ssh user@12.34.56.78 docker compose up -d app

Note: You can substitute the Docker build command with nixpacks if preferred.

Make the script executable:

chmod +x deploy.sh

Whenever you’re ready to deploy, run the script:

deploy.sh

This script encapsulates the entire deployment process - building, transferring, and launching your updated application.

Congratulations! You've successfully set up a streamlined Docker deployment pipeline for your VPS. With this foundation, you can easily manage and update your application as it evolves.

An alternative way to manage deployments is through Docker contexts, which leverages the platform's layered architecture and results in smaller file transfers over the network. I'll explore this approach in depth in a future article.

The issue with ufw

If you've set up your VPS security following my previous article, you're probably using ufw (Uncomplicated Firewall). Here's a crucial security note: Docker bypasses ufw rules by default. This means ports you thought were protected might actually be exposed to the internet - for example, port 8080 could be accessible even if ufw blocks it.

But don't worry - there's a straightforward fix for this behaviour. Edit the ufw rules file:

sudo vim /etc/ufw/after.rules

Add the following rules at the end of the file:

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:ufw-docker-logging-deny - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN

-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

-A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] "
-A ufw-docker-logging-deny -j DROP

COMMIT
# END UFW AND DOCKER

Save and close the file. Reload ufw:

sudo ufw reload

With this fix in place, your VPS should no longer be exposing port 8080. This means that your web server is no longer accessible.

To make it accessible, let's expose it on the standard HTTP port. Update your compose.yaml file to map the host port to 80:

services:
  app:
    image: app:latest
    container_name: app
    ports:
      - "80:8080" <-- this line changed
    ... (resource config omitted)

Restart your app:

docker compose up -d

Your app should now be accessible on port 80 using the VPS public ip address, assuming your firewall allows it.

Check your firewall's allowed ports with sudo ufw status. If port 80 isn't listed, enable it by running sudo ufw allow 'Nginx Full'.

Future improvements

While our web server is functional, it's exposed directly to the internet - not the best practice for production deployments. A better approach is placing it behind a battle-tested reverse proxy, which offers three major benefits:

1. Better security: Acts as a shield between your application and the internet

2. Simple HTTPS setup: Makes SSL/TLS implementation straightforward

3. Flexible routing: Route different paths to different web servers (like api.yourdomain.com to your API server and app.yourdomain.com to your frontend)

Next week, I'll guide you through setting this up with nginx. You'll learn how to configure it with your Docker containers and secure everything using HTTPS with LetsEncrypt certificates - all explained step by step.

Congratulations

Pat yourself on the back for reaching this far! You've hit some major milestones:

• Set up Docker from scratch

• Containerized your application

• Learned Docker Compose

• Deployed to your VPS

You've built a solid foundation for production deployments. See you in the next guide, where we'll take it even further!

Introduction

So, your $5 VPS just arrived. All you've got is an IP address, a username, and a password. Now what?

In this guide, I'll walk you through fortifying your VPS from zero to hero—covering essential security measures and then going beyond the basics to create a secure environment. We'll tackle everything from user management and SSH configuration to setting up a firewall and implementing a couple handy automations to keep your server in top shape.

Note: This guide is tailored for Ubuntu servers and assumes you've gone with a budget VPS provider—the kind that typically leaves most of the setup to you. If you're running on a big-name cloud platform like AWS or Azure, you might find some parts of this guide redundant, as they often come with pre-configured settings.

Securing access

First things first: updating your server

Start by connecting to your VPS using the IP address and credentials from your hosting provider:

$ ssh root@12.34.56.78

Replace the user and IP address with the one from your provider.

Enter the password when prompted.

Once you're in, update your server to the latest software versions:

$ sudo apt update 
$ sudo apt upgrade 

This ensures you're working with the most recent, secure versions of all installed packages.

Setting up a non-root user

If your hosting service provided you with a root user, it's crucial to create a separate user for connecting and running your services:

$ sudo adduser username

Replace 'username' with your preferred username

You'll be prompted to set and confirm a password for the new user. You'll also be asked for additional information - all of this is optional, so feel free to skip by pressing Enter.

Next, grant the new user sudo privileges:

$ sudo usermod -aG sudo username

Now, switch to the new user and verify sudo access:

$ su - username
$ sudo whoami

If the last command returns root, you've successfully set up sudo access for your new user.

Setting up SSH authentication

You initially connected to the server using password authentication. Now, we'll switch to key-based authentication for improved security.

On your local machine, generate an SSH key pair:

$ ssh-keygen -t ed25519 -C "email@example.com"

Replace ‘email@example.com’ with your own address

Press Enter to save the key in the default location. You can optionally enter a passphrase - if you do, you'll need to type it each time you SSH to the VPS. I personally leave it empty for convenience.

Next, from your local machine, copy your public key to your VPS:

$ ssh-copy-id -i ~/.ssh/ed25519.pub username@12.34.56.78

Replace 'username' with the user you created earlier.

Enter the user's password when prompted.

Verify that you can connect using the new key:

$ ssh -i ~/.ssh/ed25519 -o PasswordAuthentication=no username@12.34.56.78

To avoid specifying the path of the key each time, add it to your local SSH agent:

$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/ed25519

Now you can SSH to your VPS simply with:

$ ssh username@12.34.56.78

(Optional) For even more convenience, add an alias to your ~/.bashrc or ~/.zshrc:

alias ssh-vps='ssh username@12.34.56.78'

Save and close the file. Then, source the configuration into your current session:

$ source ~/.zhsrc

Now you can connect to your VPS by simply typing ssh-vps in your terminal.

Disabling password authentication

Now that you've enabled SSH key access, it's time to disable password authentication and root login. First, connect to your VPS using the new user:

$ ssh username@12.34.56.78

Open the SSH daemon configuration file:

$ sudo vim /etc/ssh/sshd_config

Make the following changes:

1. Find PermitRootLogin yes and change it to PermitRootLogin no.

2. Find ChallengeResponseAuthentication and set it to no.

3. Locate PasswordAuthentication and set it to no.

4. Find UsePAM and set it to no.

Your sshd_config file should now include these lines:

PermitRootLogin no
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Save and close the file.

⚠️ Caution: Before proceeding, ensure you've created a non-root user and set up SSH key authentication as detailed in the previous section, or you risk permanently locking yourself out of your VPS.

Apply the new configuration by restarting the SSH daemon:

$ sudo service sshd reload

Verify that root login is now disabled. From your local machine, attempt to log in as root:

$ ssh root@12.34.56.78

This should fail with a Permission denied error message.

Fortifying your VPS

Configuring a firewall

A firewall is crucial for preventing unauthorized access to your VPS ports. We'll follow the principle of least privilege, opening only the ports we need.

Install UFW (Uncomplicated Firewall):

$ sudo apt install ufw

Check the firewall status:

$ sudo ufw status verbose

It should be inactive. If not, disable it temporarily:

$ sudo ufw disable

List known UFW app policies:

$ sudo ufw app list

Allow OpenSSH (this is critical to maintain access):

$ sudo ufw allow 'OpenSSH'

⚠️ Double-check that OpenSSH is allowed (this prevents lockouts):

$ sudo ufw show added

You should see the following:

ufw allow OpenSSH

Do not proceed unless you see this.

Set default rules:

$ sudo ufw default deny incoming 
$ sudo ufw default allow outgoing

This allows all outgoing traffic but denies all incoming traffic (except SSH).

(Optional) If you’re planning to run a web server, allow ports 80 and 443:

$ sudo ufw allow 'Nginx Full'

Finally, enable the firewall:

$ sudo ufw enable

⚠️ Caution: The system may warn about disrupting SSH connections. If you've confirmed OpenSSH is allowed (as we did earlier), it's safe to proceed—enter 'y' when prompted.

Verify the firewall is running:

$ sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)

Your VPS is now protected by a firewall.

Setting up Fail2Ban

Fail2Ban monitors your authentication logs and bans IP addresses that make too many failed login attempts. We'll configure it to monitor SSH connection attempts.

Install Fail2ban:

$ sudo apt install fail2ban

Check its status (it should be disabled by default):

$ sudo systemctl status fail2ban.service

○ fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:fail2ban(1)

Before enabling it, you’ll configure Fail2Ban to monitor SSH access logs.

Navigate to the Fail2Ban config directory:

$ cd /etc/fail2ban

Create a local configuration file:

$ sudo cp jail.conf jail.local

Edit the local configuration:

$ sudo vim jail.local

In the [sshd] section, add or modify these lines:

[sshd]
enabled = true
mode = aggressive
...

This enables SSH monitoring and sets the mode to aggressive, which applies stricter rules to cover a broader range of potential threats.

Feel free to explore and adjust other settings as needed. The defaults are generally suitable for most cases. When you’re done, save and close the file.

Enable Fail2Ban to run on system startup:

$ sudo systemctl enable fail2ban

Start Fail2Ban manually:

$ sudo systemctl start fail2ban

Verify it’s running:

$ sudo systemctl status fail2ban

(Optional) To verify Fail2Ban is working, you can attempt to connect repeatedly with an invalid SSH key. The error should change from Permission denied to Connection refused when banned. Warning: Perform this test from a different machine than your local one to avoid locking yourself out. If you do get locked out, the default ban time is 10 minutes.

Your VPS now has an additional layer of protection against brute-force attacks.

Automating the boring stuff

Staying secure: automated security updates

Ubuntu provides unattended-upgrades, a tool that automatically retrieves and installs security patches and essential upgrades for your server.

Install it (if not pre-installed):

$ sudo apt install unattended-upgrades

Verify it’s running:

$ sudo systemctl status unattended-upgrades.service

(Optional) Configure automatic reboots. Some upgrades require a reboot to take effect. By default, automatic reboots are disabled. To change this, open its configuration file:

$ sudo vim /etc/apt/apt.conf.d/50unattended-upgrades

Find the line Unattended-Upgrade::Automatic-Reboot and set it to true.

⚠️ Caution: Enabling automatic reboots will make your VPS and its services temporarily unavailable during reboots. Personally, I keep this disabled and reboot manually when needed. When you SSH into the VPS, you'll see a message if a reboot is required for updates.

If you made changes, reload the service:

$ sudo systemctl reload unattended-upgrades.service

Your VPS will now automatically stay up-to-date with the latest security patches and essential upgrades.

Conclusion: a bulletproof VPS

Congratulations on making it this far! Your VPS is now in significantly better shape than when you started. Let's recap what you've accomplished:

1. Updated your server's software to the latest version

2. Disabled password authentication and set up a more secure key-based authentication mechanism

3. Added a firewall to control access to your server's ports

4. Installed Fail2Ban to automatically block IP addresses making unauthorised connection attempts

5. Configured automatic security upgrades and patches

You've transformed your bare-bones VPS into a robust, secure environment. Now you're ready to start deploying your SaaS with confidence.

Until next time, happy and secure hosting!