System Engineer knowledge hub on nuteo.info

About

Mon, 03 Aug 2026 00:00:00 +0000

About nuteo.info

I’m Nuteo, a System Engineer with 7+ years of experience running production infrastructure — Linux servers, container platforms, CI/CD pipelines, and the small automation scripts that keep everything alive at 3am.

What I do

🖥️ Infrastructure: Linux (Ubuntu/Debian), Docker, Caddy, Nginx, HAProxy
☁️ Cloud: AWS (EC2, S3, RDS), DigitalOcean, Hetzner
🔄 CI/CD: GitHub Actions, GitLab CI, Woodpecker CI
📦 Container orchestration: Docker Compose, basic Kubernetes
🔐 Security: SSH hardening, firewall, fail2ban, Let’s Encrypt, Vault
📊 Monitoring: Prometheus, Grafana, Netdata, Uptime Kuma
🛠️ Automation: Bash, Python, Ansible — anything that removes manual work

Why this site exists

I spent years collecting notes, scripts, and configs across Notion, local files, GitHub gists, and random .txt files on servers. None of it was findable. None of it helped anyone else.

CLI arsenal: the tools I actually use

Mon, 03 Aug 2026 00:00:00 +0000

CLI arsenal

This page grows over time. It’s not a “top 10” list — it’s the actual list of what’s in my shell history, my aliases, and my containers.

File & search

eza — ls replacement with git status, icons
fd — fast find with sane defaults
ripgrep (rg) — fast grep, ignores .gitignore
bat — cat with syntax highlighting and paging
fzf — fuzzy finder for everything

Process & resource

htop — interactive process viewer
btop — the prettier one
glances — web-based, for monitoring without Grafana
lsof — what’s using that port? lsof -i :8080

Networking

dog — dig for humans
cURL — yes, still
httpie — curl for humans, JSON-aware
mtr — traceroute + ping in one
nmap — for the occasional port scan

Server ops

docker + docker compose — containers, obviously
caddy — reverse proxy + auto HTTPS
restic — encrypted, deduplicated backups
fail2ban — (or CrowdSec)
ufw — firewall

Monitoring

netdata — gorgeous per-host dashboard, single Docker container
prometheus + grafana — for serious setups
uptime-kuma — self-hosted status pages
vnstat — bandwidth tracker (long-term trends)

Inside the shell

fish — my shell. Autosuggestions out of the box.
starship — fast, minimal prompt
tmux — terminal multiplexer (with tmux-pop for fuzzy session switching)
zoxide — smart cd that learns your habits

Reading config

delta — git diff that doesn’t hurt your eyes
lazygit — TUI for git when I need it

Aliases I can’t live without

# ~/.config/fish/config.fish (excerpt)
alias ll "eza -l --git --icons"
alias la "eza -la --git --icons"
alias cat "bat --plain"
alias grep "rg"
alias k "kubectl"
alias dc "docker compose"
alias dps "docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'"
alias dlog "docker logs -f --tail 100"
alias top "btop"
alias ping "ping -c 5"
alias ip "ip -c"

What did I miss? Let me know — I’m always looking for the next tool.

CrowdSec: collaborative intrusion prevention

Mon, 03 Aug 2026 00:00:00 +0000

CrowdSec: collaborative intrusion prevention

fail2ban works, but it’s solo — every server sees the same SSH brute-force attempts independently. CrowdSec fixes that: when one server bans an IP, all CrowdSec users benefit from the shared blocklist.

Install

# CrowdSec engine
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
apt install -y crowdsec

# Caddy bouncer (rejects bad IPs at the reverse proxy level)
apt install -y crowdsec-caddy-bouncer

CrowdSec auto-detects running services and activates parsers. For a stock setup, it will parse SSH, Caddy, and Nginx logs out of the box.

Healthchecks.io: cron monitoring ที่ใช้ได้จริง

Mon, 03 Aug 2026 00:00:00 +0000

Healthchecks.io: cron monitoring

Cron jobs เงียบ ถ้า restic-backup.sh fail เพราะ disk เต็ม ไม่มีใครบอก — จนกว่าคุณจะต้องใช้ backup แล้วพบว่ามันว่างเปล่า

Healthchecks.io แก้ปัญหานี้ cron jobs ของคุณ ping URL เมื่อเริ่มและเสร็จ ถ้าไม่มี ping มาตามกำหนด คุณจะได้ alert

ตั้งค่า

สมัครที่ healthchecks.io (ฟรี 20 checks)
สร้าง check:
- Name: “nightly backup”
- Period: 24 hours
- Grace: 1 hour (alert ถ้าไม่มี ping ใน 25h)
จะได้ URL เช่น https://hc-ping.com/UUID

ใช้ใน bash

#!/bin/bash
set -e

curl -fsS -m 10 --retry 5 https://hc-ping.com/UUID/start > /dev/null

restic -r b2:my-bucket:vps-snapshots backup /etc /home /srv

curl -fsS -m 10 --retry 5 https://hc-ping.com/UUID > /dev/null

set -e ทำให้ success ping รันเฉพาะตอน success ถ้า restic fail script จะ exit โดยไม่ ping → healthchecks.io alert คุณ

Postmortem: the day Postgres took down production

Mon, 03 Aug 2026 00:00:00 +0000

Postmortem: the day Postgres took down production

TL;DR: A missing index on a foreign key column, combined with a cron job running during peak hours, caused a 47-minute outage on a billing API.

Timeline (all times UTC)

14:00 — Cron job starts: cleanup_old_invoices.sh
14:02 — Customer reports slow checkout
14:05 — PagerDuty alert: API latency p99 > 5s
14:08 — On-call engineer (me) opens laptop
14:14 — Identify: Postgres CPU 100%, hundreds of DELETE queries waiting
14:22 — Kill the cron job manually → queries drain in ~30s
14:25 — Service recovering
14:47 — Full recovery, replication caught up

Total impact: 47 minutes of degraded service, ~120 failed transactions.

Production homelab: 50+ services on 3 nodes

Mon, 03 Aug 2026 00:00:00 +0000

Production homelab: 50+ services on 3 nodes

Three Ubuntu boxes. One Caddy reverse proxy. Fifty-plus self-hosted services running the show — email, git, CI/CD, dashboards, password manager, photo backup, and a small Kubernetes cluster for the things that need it.

The stack

Node	Role	Specs
`edge-01`	Reverse proxy + firewall	2 vCPU, 4GB RAM, public IP
`app-01`	Application workloads	8 vCPU, 32GB RAM, NVMe
`data-01`	Databases + storage	8 vCPU, 32GB RAM, 2×4TB HDD (RAID1)

What runs where

edge-01 (public-facing):

Server inventory & deployment automation

Mon, 03 Aug 2026 00:00:00 +0000

Server inventory & deployment automation

When you have more than 5 servers, you stop remembering which one runs what. This tool fixes that. Single source of truth for: server, role, deploy status, uptime, and alerts.

What it does

📋 Inventory — name, IP, role, environment, tags
🚀 Deploy queue — what’s deploying where, status
📊 Dashboard — uptime, last deploy, alerts
🔔 Notifications — Slack/Telegram when deployments fail

Stack

Python (FastAPI) for the API
SQLite for local store (Postgres optional)
HTMX for the dashboard (no React, no build step)
systemd + cron for agent-side collection

Architecture

┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ each host │ │ central │ │ dashboard │
│ │ │ API │ │ │
│ agent.py ──┼──▶ │ FastAPI ────┼──▶ │ /dashboard │
│ (cron 5m) │ │ SQLite │ │ (HTMX) │
└─────────────┘ └──────────────┘ └─────────────┘
 │
 ▼
 ┌─────────────┐
 │ Telegram │
 │ alerts │
 └─────────────┘

The agent is a 50-line Python script that runs via cron every 5 minutes, collects uptime, df, docker ps, and POSTs to the central API.

Setting up a VPS for production: the 2026 playbook

Mon, 03 Aug 2026 00:00:00 +0000

Setting up a VPS for production

Every time I set up a new VPS, I do the same dance: patch it, lock it down, deploy Docker, set up backups. This guide is the playbook — every step I actually run, in order.

0. Pre-flight

Before I SSH in for the first time, I always:

Set the hostname in the cloud console
Add my SSH key (not password!)
Note the public IPv4 and private IP (if VPC)
Create a DNS A record pointing to the public IP

1. First 60 seconds

apt update && apt upgrade -y
apt install -y ufw fail2ban unattended-upgrades curl wget git htop vim
timedatectl set-timezone Asia/Bangkok

Set timezone first. Logs mean nothing without correct timestamps.

Uptime monitoring with Uptime Kuma

Mon, 03 Aug 2026 00:00:00 +0000

Uptime monitoring with Uptime Kuma

Uptime Kuma is the self-hosted alternative to UptimeRobot / Pingdom. It’s a single Docker container, has a beautiful UI, and supports every monitor type I actually need.

Deploy

# docker-compose.yml
version: "3.8"
services:
 uptime-kuma:
 image: louislam/uptime-kuma:1
 container_name: uptime-kuma
 restart: unless-stopped
 volumes:
 - uptime_data:/app/data
 - /var/run/docker.sock:/var/run/docker.sock:ro
 ports:
 - "127.0.0.1:3001:3001" # Bind to localhost only
volumes:
 uptime_data:

Then expose it via Caddy on a private subdomain (e.g. status.internal.example.com) behind your WireGuard VPN.

Welcome to nuteo.info

Mon, 03 Aug 2026 00:00:00 +0000

👋 Welcome

The site is live. The design works. The content pipeline is AI-assisted. Time to explain what this is and why.

What’s working

✅ Hugo + custom theme (dark by default, gradient hero)
✅ Bilingual: TH + EN, switchable from the header
✅ Sections: Work, Guides, Tools, Blog
✅ RSS, sitemap, OpenGraph basics
✅ Git-tracked for version control
✅ Deployed via Docker + Caddy, zero-downtime

What’s next

🔍 Full-text search (Pagefind)
💬 Comments via Giscus (GitHub Discussions)
📊 Analytics (Plausible — privacy-friendly)
📝 More guides, more postmortems

The AI experiment, in one paragraph

Every piece of content on this site was drafted by AI. Every line of theme CSS was written by AI. Every Docker config, every Caddyfile, every deploy script. I reviewed and edited. I made decisions. But the typing? AI.

WireGuard VPN for admin access

Mon, 03 Aug 2026 00:00:00 +0000

WireGuard VPN for admin access

Once your VPS is in production, you don’t want to expose admin UIs (Grafana, Netdata, internal tools) to the public internet. WireGuard gives you a private tunnel to your VPS — only clients with the right keys can reach those services.

Server setup

apt install -y wireguard

# Generate server keys
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
chmod 600 /etc/wireguard/server_private.key

# Server config
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.10.10.1/24
ListenPort = 51820
PrivateKey = $(cat /etc/wireguard/server_private.key)
# Forward traffic from VPN clients
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# admin-laptop
PublicKey = <client_public_key>
AllowedIPs = 10.10.10.2/32
EOF

# Enable IP forwarding
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

systemctl enable --now wg-quick@wg0

# Open firewall
ufw allow 51820/udp comment 'WireGuard'

Client setup (macOS, Linux, iOS, Android)

For each client:

Zero-downtime Docker deploys with health checks

Mon, 03 Aug 2026 00:00:00 +0000

Zero-downtime Docker deploys with health checks

I don’t need Kubernetes for a 3-node homelab. But I do want zero-downtime deploys. Here’s the bash script I use — pulls new image, swaps container atomically, rolls back if the new container fails health check.

The script

#!/bin/bash
set -euo pipefail

SERVICE="${1:?usage: deploy.sh <service> <image>}"
IMAGE="${2:?usage: deploy.sh <service> <image>}"
COMPOSE_DIR="/srv/compose/${SERVICE}"
HEALTH_URL="${HEALTH_URL:-http://localhost:8080/health}"
OLD_CONTAINER="${SERVICE}_app_1"

cd "$COMPOSE_DIR"

# Save current image for rollback
CURRENT=$(docker inspect --format='{{.Image}}' "$OLD_CONTAINER" 2>/dev/null || echo "")

echo "▶ Pulling $IMAGE"
docker pull "$IMAGE"

# Update image in compose and start new container alongside old
echo "▶ Starting new container"
IMAGE="$IMAGE" docker compose up -d --no-deps --scale app=2 app

# Wait for new container to be healthy
echo "▶ Waiting for health check"
NEW_CONTAINER="${SERVICE}_app_2"
RETRIES=30
until docker inspect --format='{{.State.Health.Status}}' "$NEW_CONTAINER" 2>/dev/null | grep -q healthy; do
 RETRIES=$((RETRIES-1))
 if [ $RETRIES -le 0 ]; then
 echo "✗ Health check failed, rolling back"
 docker compose up -d --no-deps --scale app=1 app
 exit 1
 fi
 sleep 2
done

# Stop old container
echo "▶ Stopping old container"
docker compose up -d --no-deps --scale app=1 app

echo "✓ Deployed $SERVICE"

How to use

./deploy.sh myapp myuser/myapp:v1.2.3

Why not docker-rollout / kubectl?

Simpler: One file, ~30 lines, no Go binary
No state: Stateless nodes can run this without a cluster manager
Rollback included: Keeps old container until health check passes
Auditable: Plain bash, every step is visible

Limitations (be honest)

Single-node only (fine for my homelab, not for prod at scale)
No blue/green across multiple hosts
Health check is HTTP-only — for TCP services you’d want to extend it

For anything bigger, use Kubernetes. For a homelab or a single production host, this is enough.