• Baseline server setup: non-root user, SSH keys, firewall, automatic updates.
• Serving a small web app with Nginx + PHP-FPM or Node reverse proxy.
• Background jobs with Supervisor and cron for Laravel.
• Backups for database and files, including offsite storage and restore testing.

At this point, the app is running, jobs are processing, and backups are in place. The last piece is knowing when something goes wrong.

This is how I do minimal monitoring on small Ubuntu VPS instances: checking logs, watching disk usage, and setting up basic uptime monitoring. It's not a full observability stack. It's just enough so I'm not completely blind when issues happen.

What this covers (and what it doesn't)

This post focuses on:

• Checking application and system logs.
• Monitoring disk usage and basic resources.
• Simple uptime monitoring with external services.

This is not:

• A Prometheus + Grafana setup.
• A distributed tracing or metrics platform.
• A complete monitoring solution for large teams.

If your app is small enough that a single VPS makes sense, this pattern is usually enough to notice problems before users complain.

Logs that matter

For a typical small web app, I care about:

Nginx logs

Usually in:

/var/log/nginx/myapp-access.log
/var/log/nginx/myapp-error.log

I use these to:

• See incoming requests and response codes.
• Debug 5xx errors and upstream issues.

Quick checks:

sudo tail -f /var/log/nginx/myapp-error.log
sudo tail -n 100 /var/log/nginx/myapp-access.log | grep " 5[0-9][0-9] "

Application logs

For Laravel, typically:

/var/www/myapp/storage/logs/laravel.log

For Node apps, wherever you configure your logger to write.

I look for:

• Exceptions and stack traces.
• Repeated errors around the same time as user reports.
• Patterns that suggest a specific endpoint or job is failing.

System logs

On Ubuntu:

/var/log/syslog

or via journalctl:

sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -u supervisor --since "1 hour ago"

These help when:

• A service fails to start.
• There are OOM kills or disk issues.
• SSH or system-level problems occur.

Making logs easier to read

A few habits that help me:

• Use less for large logs

  sudo less /var/log/nginx/myapp-error.log
  

  Then search with / inside less.

• Filter by time or pattern

  sudo grep "2025-09-05" /var/www/myapp/storage/logs/laravel.log | less
  sudo grep -i "timeout" /var/log/nginx/myapp-error.log
  

• Follow logs in real time when debugging

  sudo tail -f /var/log/nginx/myapp-error.log /var/www/myapp/storage/logs/laravel.log
  

I don't set up centralized logging for small VPS instances. Instead, I make sure I can quickly SSH in and read logs when needed.

Monitoring disk usage

Running out of disk is a common way for small VPS instances to die quietly.

Basic checks:

df -h

Look at:

• Overall usage on /.
• Any partitions or mount points that are close to 100%.

Find large directories:

sudo du -sh /var/www/* | sort -h
sudo du -sh /var/log/* | sort -h

For logs, I rely on:

• Logrotate (usually already configured on Ubuntu).
• Occasional manual cleanup if a specific log grows too large.

Example logrotate config for a custom app log:

sudo nano /etc/logrotate.d/myapp

/var/www/myapp/storage/logs/laravel.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0644 deploy deploy
}

This keeps 7 days of logs, compressed after the first day.

Basic resource checks

For CPU and RAM, I usually stick to simple tools:

htop
top
free -h

I don't install heavy monitoring agents on small VPS instances unless there's a clear need. Instead:

• Check htop when debugging slowness.
• Look for processes using unexpected CPU or memory.
• Correlate with logs to see if a specific job or endpoint is the culprit.

If you want something slightly more structured without going full metrics stack, tools like glances or ncdu can be helpful, but they're optional.

Uptime monitoring from the outside

Internal checks are useful, but if the server is completely down, you can't SSH in to run them. That's why I use external uptime monitoring.

Options I've used:

• Uptime Kuma (self-hosted).
• StatusCake, Pingdom, UptimeRobot, or similar services.
• Simple cron-based scripts that hit an endpoint and send email on failure.

Typical setup:

• Create an HTTP check for https://example.com.
• Set check interval (e.g., every 1–5 minutes).
• Configure email or webhook notifications.

This gives you:

• Alert when the site is down.
• Basic uptime history.
• A way to notice outages you might otherwise miss.

For small projects, this is often more valuable than a complex internal metrics system.

A simple routine

Instead of trying to watch everything all the time, I use a light routine:

Daily (optional, mostly automated)

• Uptime monitoring runs automatically.
• Backups run via cron (from part 4).
• Logs rotate automatically.

Weekly or biweekly (manual, 5–10 minutes)

When I remember or have time:

df -h
sudo du -sh /var/www/* | sort -h
sudo tail -n 50 /var/log/nginx/myapp-error.log
sudo tail -n 50 /var/www/myapp/storage/logs/laravel.log

I look for:

• Disk creeping towards full.
• Repeated errors in logs.
• Any unusual patterns.

After incidents

When something goes wrong:

• Check logs around the incident time.
• Note what happened and what fixed it.
• Adjust backups, logs, or monitoring if needed.

Over time, this builds a lightweight but practical understanding of how the server behaves.

Common mistakes I keep making

These are the issues I run into most often:

• Ignoring disk until it's full
  Not checking df -h until the site starts failing with "no space left on device."

• Not reading error logs
  Relying only on "the site works" without ever checking Nginx or app error logs.

• No external uptime check
  Only discovering the server is down when a user reports it.

• Logs growing forever
  Forgetting to configure logrotate for custom logs, leading to huge files.

• Over-engineering monitoring
  Installing heavy tooling on a 1 GB VPS, then spending more time maintaining monitoring than the app itself.

For small VPS instances, I prefer boring, simple tools that I actually use over fancy setups I'll ignore.

What this is not

This approach is not:

• A replacement for proper alerting in critical production systems.
• A design for high-traffic or distributed architectures.
• A complete security monitoring solution.

It's just enough monitoring so I'm not completely blind when something breaks on a small VPS.

Wrapping up the series

With this post, the baseline series covers:

1. Baseline server setup (users, SSH, firewall, updates).
2. Serving apps with Nginx + PHP/Node.
3. Background jobs with Supervisor and cron.
4. Backups for database and files, including offsite storage and restore testing.
5. Minimal monitoring: logs, disk, and uptime.

This is not a complete production checklist for every scenario, but it's the baseline I want in place before considering a small app "properly deployed" on a VPS.

Before you consider this done

Before I stop thinking about monitoring on a small VPS, I make sure:

• I know where the main logs live and how to read them.
• Disk usage is checked occasionally, and logrotate is configured.
• There's at least one external uptime check with notifications.
• I have a simple routine (even if irregular) to glance at logs and resources.

If you've followed this series, you now have a repeatable baseline for deploying small web apps to Ubuntu VPS instances. From here, you can iterate based on your actual needs instead of starting from vague best-practice checklists.

• Baseline server setup: non-root user, SSH keys, firewall, automatic updates.
• Serving a small web app with Nginx + PHP-FPM or Node reverse proxy.
• Background jobs with Supervisor and cron for Laravel.

Now that the app is running and processing jobs, the next question is: what happens if this VPS disappears tomorrow?

This is how I handle backups for small web apps on Ubuntu VPS: database dumps, important files, offsite storage, and actually testing restores. It's not a disaster recovery plan for a large company. It's just the minimal setup I want before considering an app "deployed."

What this covers (and what it doesn't)

This post focuses on:

• Backing up MySQL/MariaDB or PostgreSQL databases.
• Backing up important application files (uploads, .env, etc.).
• Storing backups outside the VPS.
• Testing restores so you know the backups are not useless.

This is not:

• A complete backup strategy for large teams or compliance-heavy environments.
• A guide to encrypted backup pipelines with key management.
• A replacement for proper monitoring and alerting.

If your app is small enough that a single VPS makes sense, this pattern is usually enough to sleep better at night.

What to back up

For a typical small Laravel or web app, I back up:

Database

• The main application database.
• Any additional databases used by the app (if applicable).

Files

At minimum:

• .env (or equivalent config with secrets).
• storage/ directory (uploads, logs that matter).
• Any other directory where user-generated content lives.

Code itself is often in Git, so I don't always back it up separately, but for very small projects I sometimes include the entire /var/www/myapp directory for simplicity.

A simple backup script

I usually create a small shell script that:

• Dumps the database.
• Archives important files.
• Names backups with timestamps.
• Stores them in a dedicated directory (e.g., /root/backups).

Example:

sudo mkdir -p /root/backups
sudo nano /root/backups/myapp-backup.sh

A minimal script might look like this:

#!/usr/bin/env bash
set -euo pipefail

APP_NAME="myapp"
BACKUP_DIR="/root/backups"
DATE=$(date +%Y-%m-%d-%H%M%S)

DB_USER="myapp_user"
DB_NAME="myapp_db"
DB_HOST="localhost"

# Database backup
mysqldump -u"$DB_USER" -p"${DB_PASSWORD:-}" -h"$DB_HOST" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/${APP_NAME}-db-${DATE}.sql.gz"

# Files backup
tar -czf "$BACKUP_DIR/${APP_NAME}-files-${DATE}.tar.gz" \
  -C /var/www myapp \
  --exclude=myapp/vendor \
  --exclude=myapp/node_modules

# Rotate old backups (keep last 7 days)
find "$BACKUP_DIR" -name "${APP_NAME}-*.sql.gz" -mtime +7 -delete
find "$BACKUP_DIR" -name "${APP_NAME}-*.tar.gz" -mtime +7 -delete

Adjust:

• Database credentials and command (mysqldump vs pg_dump).
• Paths and exclusions for your app.
• Retention period (here: 7 days).

Make it executable:

sudo chmod +x /root/backups/myapp-backup.sh

Test it manually once:

sudo /root/backups/myapp-backup.sh
ls -lh /root/backups

Check that:

• Files are created.
• Sizes look reasonable.
• No obvious errors in the output.

Storing backups offsite

Keeping backups only on the same VPS is better than nothing, but not by much. If the VPS is lost or compromised, you lose both app and backups.

Common options for offsite storage:

• Object storage: S3, Backblaze B2, Cloudflare R2, etc.
• Another server you control via SCP/rsync.
• A backup service that pulls from your server.

For object storage, tools like rclone or provider-specific CLI tools work well. A very simple pattern:

• Run the backup script locally.
• Sync the /root/backups directory to remote storage.

Example with rclone (conceptual):

rclone sync /root/backups remote-bucket:myapp-backups

I won't go into full rclone setup here; the key point is:

• Backups should live outside the VPS.
• The process should be automated, not something you remember to do manually.

Automating backups with cron

Once the script works manually, add a cron job.

Edit root's crontab:

sudo crontab -e

Add something like:

0 2 * * * /root/backups/myapp-backup.sh >> /var/log/myapp-backup.log 2>&1

This runs the backup daily at 02:00.

Check logs occasionally:

tail /var/log/myapp-backup.log

Look for:

• Successful completion messages.
• Any errors from mysqldump, tar, or the upload step.

Testing restores (the part everyone skips)

A backup you haven't tested is not a backup; it's hope.

At least once, ideally on a schedule, test restoring from your backups.

Restore database

On a test server or the same server (if you're comfortable):

# Decompress
gunzip < /root/backups/myapp-db-2025-09-05-020000.sql.gz > restore.sql

# Import
mysql -u"$DB_USER" -p"${DB_PASSWORD:-}" -h"$DB_HOST" "$DB_NAME" < restore.sql

Then:

• Check that tables exist.
• Run a few queries to confirm data looks right.
• If possible, run the app against this restored database in a staging environment.

Restore files

cd /var/www
tar -xzf /root/backups/myapp-files-2025-09-05-020000.tar.gz

Check:

• Permissions on storage/ and other directories.
• That recent uploads are present.
• That .env matches the environment (or adjust as needed).

Document the restore steps

I keep a short note somewhere (could be a private README) with:

• Where backups are stored.
• How to restore database and files.
• Any gotchas specific to the app.

This makes future restores (by you or someone else) much less stressful.

Common mistakes I keep making

These are the issues I run into most often:

• No offsite copy
  Backups exist, but only on the same VPS. If the VPS dies, backups die with it.

• Never testing restores
  Backups run daily, but no one has ever tried to restore from them.

• Wrong permissions after restore
  Files are restored, but storage/ is not writable by the web user, causing silent failures.

• Ignoring logs
  Backup cron runs, but errors are never checked; backups have been failing for weeks.

• Backing up too much or too little
  Either huge backups that are slow and expensive, or missing critical directories like storage/app.

When in doubt, I re-check:

ls -lh /root/backups
tail /var/log/myapp-backup.log

and occasionally run a restore on a test server.

What this is not

This setup is not:

• A replacement for proper monitoring and alerting on backup jobs.
• A design for multi-region, compliance-heavy environments.
• A guarantee that you'll never lose data.

It's just a minimal baseline so that if the VPS disappears, you can rebuild without starting from zero.

What comes next

With backups in place, the last core piece in this series is minimal monitoring:

• Checking logs.
• Watching disk usage.
• Basic uptime monitoring.

That's the topic for the next post in this series.

Before you move on

Before considering this step "done", I make sure:

• A backup script exists and runs automatically.
• Backups are stored outside the VPS.
• I have successfully restored both database and files at least once.
• I know where to find backup logs and how to troubleshoot failures.

This isn't a complete disaster recovery plan, but it's the baseline I want before moving on to monitoring.

• Baseline server setup: non-root user, SSH keys, firewall, automatic updates.
• Serving a small web app with Nginx + PHP-FPM or Node reverse proxy.

Now that the app is reachable over HTTP, the next boring-but-important piece is background jobs and scheduled tasks.

This is how I run Laravel queue workers and scheduled commands on a small Ubuntu VPS using Supervisor and cron. It's not a distributed queue architecture or a monitoring deep dive. It's just the setup I actually use for small to medium projects.

What this covers (and what it doesn't)

This post focuses on:

• Running Laravel queue workers with Supervisor.
• Running Laravel's scheduler with a simple cron entry.
• Basic checks to see if things are actually working.

This is not:

• A guide to Redis clusters or horizontal scaling.
• A complete monitoring and alerting setup.
• A comparison of all possible queue drivers and tools.

If your app is small enough that a single VPS makes sense, this pattern is usually more than enough.

Why Supervisor and cron

For small Laravel apps, I typically use:

• Supervisor to keep queue workers running.
• Cron to trigger Laravel's scheduler every minute.

Reasons:

• Supervisor is simple, stable, and widely available on Ubuntu.
• Cron is already there; no need to introduce systemd timers or external schedulers for basic use cases.
• This combination is easy to debug and document.

I don't use this setup for massive scale, but for most side projects and small production apps, it works reliably.

Installing Supervisor

On a fresh Ubuntu server:

sudo apt update
sudo apt install supervisor

Check that it's running:

systemctl status supervisor

If the service is active, you can move on to configuring a worker for your app.

Directory and user assumptions

This guide assumes:

• App code lives in /var/www/myapp.
• The app is owned by the deploy user (the same non-root user from part 1).
• PHP CLI version matches your stack (e.g., php8.2).

Adjust paths and versions to match your environment.

Basic queue configuration in Laravel

In .env, I usually have something like:

QUEUE_CONNECTION=database

or, if using Redis:

QUEUE_CONNECTION=redis

For this post, the driver details don't matter much; the Supervisor config is similar either way. What matters is that:

• Jobs are being dispatched correctly.
• A worker process is running to handle them.

Supervisor config for a Laravel queue worker

Supervisor configs typically live in /etc/supervisor/conf.d/.

I create a file like:

sudo nano /etc/supervisor/conf.d/myapp-worker.conf

A minimal config looks like this:

[program:myapp-worker]
command=/usr/bin/php8.2 /var/www/myapp/artisan queue:work database --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasuser=false
killasgroup=true
user=deploy
numprocs=1
redirect_stderr=true
stdout_logfile=/var/log/supervisor/myapp-worker.out.log
stderr_logfile=/var/log/supervisor/myapp-worker.err.log

Key points:

• command points to your artisan file and desired queue driver.
• --max-time helps avoid memory leaks by restarting workers periodically.
• user=deploy runs the worker as the same user that owns the app files.
• Logs are written under /var/log/supervisor/.

Create the log directory if it doesn't exist:

sudo mkdir -p /var/log/supervisor
sudo chown deploy:deploy /var/log/supervisor

Adjust permissions as needed for your setup.

Enabling and starting the worker

After saving the config:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start myapp-worker

Check status:

sudo supervisorctl status

You should see something like:

myapp-worker                   RUNNING   pid 12345, uptime 0:00:10

If it fails to start, check:

• The command path is correct.
• PHP CLI is installed and matches the version in the command.
• The deploy user can execute artisan queue:work.

Running the scheduler with cron

Laravel's scheduler is designed to be triggered by a single cron entry that runs every minute.

Edit the crontab for the deploy user:

crontab -e

Add:

* * * * * cd /var/www/myapp && /usr/bin/php8.2 artisan schedule:run >> /dev/null 2>&1

Notes:

• Use the full path to php (e.g., /usr/bin/php8.2) to avoid environment issues.
• Redirecting output to /dev/null keeps cron quiet; logs should be handled in your Laravel code or schedule:run options if needed.

This single line is enough to enable all scheduled tasks defined in app/Console/Kernel.php (or the relevant scheduler file for your Laravel version).

Testing that jobs actually run

It's easy to configure Supervisor and cron and still have nothing actually working. I usually run a few quick checks:

1. Dispatch a test job

From the app directory:

cd /var/www/myapp
php8.2 artisan tinker

Then dispatch a simple job, or trigger something in your app that you know should create a job (e.g., send an email, process an upload).

2. Check Supervisor logs

sudo tail -f /var/log/supervisor/myapp-worker.err.log
sudo tail -f /var/log/supervisor/myapp-worker.out.log

Look for:

• Job processing messages.
• Any exceptions or connection errors.

3. Check scheduler execution

To verify cron is running the scheduler:

• Add a temporary scheduled command in Laravel that writes to a log or file every minute.
• Wait a couple of minutes.
• Check that the file/log is updated.

Once confirmed, remove or disable the test command.

Common mistakes I keep making

These are the issues I run into most often:

• Wrong PHP version
  Config uses php8.2, but the system default is 8.1 or 8.3, or CLI isn't installed.

• Wrong working directory
  command doesn't cd into the app directory, causing path issues for some jobs.

• Permissions
  The deploy user can run artisan, but some jobs need write access to storage/ or bootstrap/cache/.

• Cron environment differences
  Cron runs with a minimal environment; relying on .env loading via Composer or framework bootstrapping is fine, but assuming shell aliases or custom PATH is not.

• Assuming "RUNNING" means "working"
  Supervisor can show RUNNING while the worker is stuck or failing repeatedly. Logs are the source of truth.

When something feels off, I always go back to:

sudo supervisorctl status
sudo tail -n 50 /var/log/supervisor/myapp-worker.err.log
grep -i error /var/log/supervisor/myapp-worker.err.log

What this is not

This setup is not:

• A replacement for proper error handling and logging in your jobs.
• A monitoring solution. You still need to check logs and, ideally, have some form of alerting.
• A design for high-scale distributed systems.

It's just a reliable baseline for small apps where a single VPS is enough.

What comes next

With the app served by Nginx and background jobs running, the next important piece is backups:

• Database dumps.
• Important files (uploads, .env, etc.).
• Storing backups outside the VPS.
• Actually testing restores.

That's the topic for the next post in this series.

Before you move on

Before considering this step "done", I make sure:

• A queue worker is running under Supervisor and processing jobs.
• The scheduler is triggering every minute via cron.
• I know where to find worker logs and how to restart the worker.
• I have at least one real job running in production, not just a test command.

This isn't a complete job architecture, but it's the baseline I want before moving on to backups and monitoring.

Now that the server itself is in a sane state, the next step is getting a small web app in front of users without over-engineering the stack.

This is how I typically set up Nginx for small Laravel or Node apps on a fresh Ubuntu VPS. It's not a high-traffic architecture or a complete hardening guide. It's just the default pattern I reach for when the goal is "get this app online reliably."

Why Nginx, and what this is not

I use Nginx as a reverse proxy and/or web server because:

• It's lightweight and stable on small VPS instances.

• It handles TLS termination cleanly.

• It works well with both PHP-FPM and Node apps.

This post is not:

• A performance tuning guide for high-traffic sites.

• A complete security hardening reference.

• A comparison of Nginx vs Apache vs Caddy.

It's just the setup I actually run for small projects.

Directory structure and ownership

Before touching Nginx, I decide where the app will live and who owns it.

For most small apps, I use something like:

/var/www/myapp

with ownership:

sudo chown -R deploy:deploy /var/www/myapp

I avoid putting app code in home directories because:

• It keeps system users and app code conceptually separate.

• It's easier to reason about in Nginx configs and backup scripts.

The deploy user here is the same non-root sudo user from the first post in this series.

Basic Nginx installation

On a fresh Ubuntu server:

sudo apt update
sudo apt install nginx

Then I check that Nginx is running:

systemctl status nginx

At this point, Nginx is usually serving the default page on port 80. I leave that alone until I'm ready to switch traffic to the new site.

Server block layout

I manage sites using the standard Ubuntu pattern:

• Config file in /etc/nginx/sites-available/myapp

• Symlink in /etc/nginx/sites-enabled/myapp

Example:

sudo nano /etc/nginx/sites-available/myapp
sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp
sudo nginx -t
sudo systemctl reload nginx

I always run nginx -t before reloading. It's an easy way to catch syntax errors without taking down existing sites.

Minimal server block for a Laravel (PHP-FPM) app

For a typical Laravel app, my starting server block looks like this:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/myapp/public;
    index index.php index.html;

    access_log /var/log/nginx/myapp-access.log;
    error_log /var/log/nginx/myapp-error.log;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

Key points:

• root points to the public directory, not the project root.

• try_files handles Laravel's front controller pattern.

• PHP is passed to PHP-FPM via a Unix socket.

• Logs are namespaced per app (myapp-access.log, myapp-error.log).

Adjust the PHP version and socket path to match your installation (php8.1-fpm.sock, php8.3-fpm.sock, etc.).

Minimal server block for a Node app (reverse proxy)

For a Node app running on localhost:3000 (or similar), the server block is even simpler:

server {
    listen 80;
    server_name example.com www.example.com;

    access_log /var/log/nginx/myapp-access.log;
    error_log /var/log/nginx/myapp-error.log;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Notes:

• proxy_pass points to the local Node process.

• Headers like X-Real-IP and X-Forwarded-For help the app see the real client IP.

• No PHP configuration is needed here.

The Node process itself can be managed with systemd or PM2; that's a topic for a later post in this series.

Enabling the site and testing configuration

Once the server block is written:

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp
sudo nginx -t

If the test passes:

sudo systemctl reload nginx

I then test with:

curl -I http://example.com

and check:

• Status code (should be 200 or a redirect, not 500/502).

• That the expected app is responding, not the default Nginx page.

If something breaks, I check:

sudo tail -f /var/log/nginx/myapp-error.log

while hitting the site in a browser.

Common mistakes I keep making

These are the issues I run into most often:

• Wrong document root
  Pointing root at /var/www/myapp instead of /var/www/myapp/public for Laravel.

• PHP-FPM socket mismatch
  Config says php8.2-fpm.sock, but the system is running 8.1 or 8.3.

• Permissions
  Nginx can read files, but PHP-FPM runs as a different user and cannot write to storage/ or bootstrap/cache/.

• server_name does not match
  DNS points to the server, but Nginx is still serving the default site because server_name doesn't match the request.

• Forgetting to reload
  Changing the config but forgetting sudo systemctl reload nginx.

When in doubt, I re-check:

sudo nginx -T | grep -A 10 'server_name example.com'

to see the effective configuration.

What comes next

At this point, the app is reachable over HTTP, but there are still some important pieces missing:

• Background jobs and scheduled tasks (queue workers, cron).

• Backups for the database and important files.

• Basic monitoring so I notice when something goes wrong.

Those are the topics for the next posts in this series.

Before you move on

Before considering this step "done", I make sure:

• The app is accessible via the domain I expect.

• Logs are being written to the expected files.

• I can reproduce a request and see it in the access log.

• I know which user runs PHP-FPM or the Node process, and which user owns the files.

This is not a complete production checklist, but it's the baseline I want before moving on to queues, cron, and backups.

The stuff that's easy to miss is the server baseline: how I log in, which ports are open, whether I'm still using root, and whether the machine will keep getting security updates once I stop thinking about it for a few weeks.

This is the first-pass checklist I use before putting an app on a new VPS. It isn't a security audit or a promise that a server is fully secure. It's just the baseline I want in place before exposing an app to the internet.

1. Update the system first

sudo apt update
sudo apt upgrade

I do this before installing the app stack so I'm not starting from an old package set. On an existing server, I check what will change first instead of blindly accepting upgrades.

If an update includes a new kernel, I check whether a reboot is needed:

test -f /var/run/reboot-required && echo "Reboot required"

2. Create a non-root sudo user

I don't use the root account as my normal deploy account.

sudo adduser deploy
sudo usermod -aG sudo deploy

Before changing anything related to SSH, I open a second terminal and make sure the new user can log in and run sudo commands:

ssh deploy@your-server-ip
sudo whoami

The expected output is:

root

I keep the original root session open until this works. It's an easy way to avoid locking myself out halfway through the setup.

3. Confirm SSH key login first

On my local machine, I create a key if I don't already have one:

ssh-keygen -t ed25519 -C "my-laptop"

Then I copy the public key to the new server:

ssh-copy-id deploy@your-server-ip

I test key login in a new terminal before changing the SSH server configuration:

ssh deploy@your-server-ip

Only after that works do I disable direct root login and password authentication.

4. Harden SSH carefully

On Ubuntu, I prefer adding a separate config file instead of editing the main SSH configuration directly:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

My basic starting point looks like this:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Before reloading SSH, I validate the configuration:

sudo sshd -t

I also check the effective values, especially if the server already has other files under sshd_config.d:

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

Then I reload the service:

sudo systemctl reload ssh

I keep the current SSH session open and test a fresh login after the reload. If the new connection fails, the old session is still there to fix the configuration.

5. Enable a basic firewall

For a small web server, I normally start with a deny-by-default inbound policy:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH

If the server serves web traffic directly, I also allow HTTP and HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then I enable UFW and check the result:

sudo ufw enable
sudo ufw status verbose

Don't enable UFW before allowing SSH. That's an easy way to lose access to a remote VPS. If I use a non-default SSH port, I allow that exact port instead of relying on the OpenSSH profile.

6. Check automatic security updates

On current Ubuntu Server releases, unattended-upgrades is usually already installed. I still check that automatic security updates are enabled and configured the way I expect:

sudo dpkg-reconfigure unattended-upgrades

If the package is missing, I install it first:

sudo apt install unattended-upgrades

I also check the logs from time to time:

sudo ls -la /var/log/unattended-upgrades/

Automatic updates help avoid leaving known security fixes unapplied, but they don't replace backups, patch reviews, or monitoring.

7. Install only what the app needs

I try not to install a full collection of tools just because they're common in server setup guides.

For a typical web app, that might mean only:

• A reverse proxy such as Nginx or Caddy

• The runtime I actually need, such as Node.js or PHP

• A systemd service or Supervisor configuration for the app process

• A database client only if the server needs one

For Laravel deployments, I treat the Supervisor config and cron entry as part of the deployment, not something to add later after the first queue job gets stuck.

Every installed service is another thing to configure, patch, and monitor.

8. Verify the baseline before deploying

Before deploying the application, I check:

whoami
sudo ufw status verbose
sudo systemctl status ssh
sudo ss -tulpn

I also make sure I know:

• Which user owns the application files

• Which process starts the application

• Which ports are intentionally exposed

• Where logs will be written

• How I would restore the application and its data if the VPS disappeared

What this checklist does not cover

This is only a first pass. It does not replace:

• Application security reviews

• Database backup and restore testing

• Secret rotation

• Dependency vulnerability management

• DDoS protection

• Monitoring and alerting strategy

• Compliance requirements

• A professional security audit

A fresh VPS can be brought to a safer baseline fairly quickly, but security isn't a one-time command you run after provisioning.

Before you deploy

Before I put an app on a new VPS, I make sure:

• I can log in with a non-root user and an SSH key

• Root and password SSH login are disabled only after key login is verified

• The firewall allows only the ports the server actually needs

• I know how the app starts, where it logs, and how I would restore its data