Install Postgres and Redis on your server

The "would six hours of downtime be okay?" question

Reasons self-hosted is fine:

• Personal project, hobby site, or low-traffic SaaS in early stages.
• You'd rather spend $0/month and run a backup script than $20+/month for a managed instance.
• Dataset is under a few GB and you can recreate it from a backup if something catastrophic happens.

Reasons to pay for managed:

• You have paying customers whose data must survive any single-machine failure.
• You don't want to run point-in-time recovery scripts at 3 AM.
• You want major-version upgrades that don't require a maintenance window you plan personally.
• You're already on AWS / GCP and the latency to a managed instance in the same region is identical to a local one.

Rough costs at small scale: Supabase free tier (Postgres) supports projects up to 500 MB; Upstash free Redis covers 256 MB. Above that, the cheapest managed Postgres runs $10–25/month; the cheapest managed Redis runs $5–10/month. Self-hosted on an existing VPS is free.

One apt command, then verify

sudo apt update
sudo apt install -y postgresql postgresql-contrib

# Postgres starts automatically. Verify:
sudo systemctl status postgresql
# Active: active (exited) is correct — the wrapper unit is "exited",
# but the actual cluster (postgresql@<ver>-main.service) is running.

# Check the version that landed:
psql --version

Ubuntu 22.04 ships Postgres 14; Ubuntu 24.04 ships 16. For a newer version, add the official Postgres apt repo (apt.postgresql.org) and install postgresql-17 instead. The setup below works on any version >= 12.

One role + one database per application; never use the postgres superuser

Postgres ships with a Unix user postgres that has full database superuser rights via "peer" auth — your Unix user has to match. Switch to it to administer the cluster:

sudo -u postgres psql

You're in the psql prompt as the superuser. Create a role and a database for your app:

-- Replace mybrand_app and the password.
CREATE ROLE mybrand_app WITH LOGIN PASSWORD 'long-random-password-from-pwgen';
CREATE DATABASE mybrand_prod OWNER mybrand_app;

-- Verify:
\du
\l
\q

Generate the password locally with pwgen -s 32 1 or openssl rand -base64 24 — long, random, stored in your password manager. Your app will use it via an env var, never typed by hand.

What method Postgres uses to verify "who is asking"

The default pg_hba.conf on Ubuntu has these meaningful lines (paraphrased):

# Unix socket (local pipe, not network) — peer auth (Unix user must match role)
local   all             postgres                                peer
local   all             all                                     peer

# TCP from 127.0.0.1 — scram-sha-256 (password auth)
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256

For an app on the same box connecting to 127.0.0.1:5432, this is already correct — the app authenticates with the password from Step 3. Nothing to change.

If your app connects via Unix socket (no password) instead, change the local all all peer line to:

local   all             mybrand_app                             scram-sha-256
local   all             all                                     peer

This says: the app role uses password auth even on Unix socket; everyone else uses peer auth. Reload Postgres after any change to this file: sudo systemctl reload postgresql.

The unbackup'd database is the production database you don't have

Daily snapshot via pg_dump, compressed, shipped to S3 (or any object store). Save as /usr/local/bin/pg-backup.sh:

#!/usr/bin/env bash
set -e
DB=mybrand_prod
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_DIR=/var/backups/postgres
S3_BUCKET=s3://mybrand-backups/postgres

mkdir -p "$BACKUP_DIR"
sudo -u postgres pg_dump -Fc "$DB" | gzip > "$BACKUP_DIR/$DB-$TIMESTAMP.dump.gz"

# Ship to S3. Configure AWS CLI as the deploy user first (aws configure).
aws s3 cp "$BACKUP_DIR/$DB-$TIMESTAMP.dump.gz" "$S3_BUCKET/$DB-$TIMESTAMP.dump.gz"

# Keep 14 days locally; S3 retention is set via lifecycle policy on the bucket.
find "$BACKUP_DIR" -type f -mtime +14 -delete

chmod +x the script. Add a cron entry as the deploy user:

crontab -e
# Add:
30 3 * * * /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1

The harder, more important second step: practice a restore. On a different box, aws s3 cp a recent dump back down, gunzip, pg_restore, verify the row count. A backup you've never restored is hope, not a backup.

Install + set auth in the same breath

sudo apt install -y redis-server
# Service starts automatically, bound to 127.0.0.1 by default. Good.

# Set a password BEFORE doing anything else network-related.
# Generate one:
REDIS_PASSWORD=$(openssl rand -base64 24)
echo "$REDIS_PASSWORD"
# Save it to your password manager. You'll set it as an env var for the app too.

Edit Redis config:

sudo nano /etc/redis/redis.conf

# Find and set:
requirepass <THE_PASSWORD_FROM_ABOVE>
# (Make sure there's NO # at the start of the line.)

# Verify the bind line is:
bind 127.0.0.1 -::1
# (This is the default. Do NOT change to 0.0.0.0 unless you're absolutely
#  sure you want Redis exposed to the network, and have the firewall + auth
#  set up correctly.)

# Disable the COMMAND command in production (optional, paranoia level):
rename-command CONFIG ""
rename-command FLUSHALL ""

Reload:

sudo systemctl restart redis-server
redis-cli
# Inside redis-cli:
AUTH <the password>
PING    # → PONG
exit

Connection string for your app: redis://default:<password>@127.0.0.1:6379. (default is the implicit username when only requirepass is set; if you set up Redis ACLs with named users, the username matters.)

RDB for snapshots, AOF for write-log, or neither for pure cache

Redis can be used three ways, each with a different persistence story:

• Pure cache — sessions, query caches, ephemeral data you can regenerate. Disable persistence to avoid disk overhead: save "" in redis.conf, appendonly no. On restart, you start with an empty Redis; the app refills it.
• Snapshot persistence (RDB, the default) — Redis dumps a binary snapshot to disk on a schedule. Default save 3600 1 300 100 60 10000 means "after 1 change in an hour, 100 in 5 minutes, or 10000 in a minute, write to disk." Recovery loses anything since the last snapshot. Good for "I'd like data to survive a restart but I can tolerate losing minutes."
• Append-only log (AOF) — Redis writes every command to a log; on restart, replays the log. Set appendonly yes in redis.conf. Recovery loses at most 1 second of commands (default fsync policy everysec). Use when Redis is your primary store, not a cache.

For most app caches: RDB defaults are fine; don't change anything. For session stores or queues: set appendonly yes too. Reload: sudo systemctl restart redis-server.

From your app, end to end

# Verify Postgres connection (replace credentials):
psql "postgresql://mybrand_app:[email protected]:5432/mybrand_prod" -c "SELECT version();"

# Verify Redis connection:
redis-cli -a "REDIS_PASSWORD" ping    # → PONG

# Verify the firewall isn't leaking (from your laptop, not the server):
nc -zv <SERVER_IP> 5432    # → Connection refused (good — Postgres is not public)
nc -zv <SERVER_IP> 6379    # → Connection refused (good — Redis is not public)

If nc from your laptop connects to either port, something's wrong — the service is bound to 0.0.0.0 or the firewall is missing a deny rule. Fix immediately; an open Redis is exploited within hours.