It needs a feed. It needs metadata. It needs cards that do not look accidental when a link gets shared. These are small surfaces, but they are part of the publishing system.

The feed is the cleanest one. No chrome, no layout, just entries. The card is the opposite: pure presentation, generated at build time so the site still stays static.

Both make the site feel more real. Not bigger. Just reachable from more angles.

Badge. Counter. Clock. Ticker. Density grid. Globe. Status panel. Danger frame. Small parts with names, not one-off decoration.

That matters because this aesthetic can get sloppy fast. Manga cyberpunk HUD is close to parody if every page invents new chrome. The kit gives the pages a shared vocabulary. It also keeps the content in the middle, where it belongs.

Most of the chrome is decorative. It still needs rules.

Inspiration for this site comes from many places, but most recently when I came across the beutifual art made by Artem Filippov. It deeply resonated with me and inspired this direction of the site. Thank you Artem.

The site is hand-rolled because I wanted to understand the whole surface.

Markdown in, templates out. A small content loader. Explicit schemas. A build script that writes files, feeds, sitemap, and cards. Nothing here needed a framework.

That is not a general argument against frameworks. It is a local preference for this project. The site is small enough that the boring parts are still readable, and the weird parts are easier to shape when I own the pipeline.

The tradeoff is obvious: I have to maintain the little system myself. For a personal scratchpad, that feels like the point.

Especially for notes. Markdown files are easy to understand until the sync layer turns them into a magic trick. I want to know which folder is canonical, what moves where, how conflicts are handled, and how to recover when one machine goes stale.

That sounds like plumbing because it is plumbing.

The temptation is to design the future architecture first. The better note says what is actually running. What sync path exists. What is backed up. What happens when it fails.

Routine maintenance should be cheap: ingest a small batch, update existing pages, add links, keep indexes current. The model needs to be consistent, not brilliant.

The stronger model should be saved for the work that needs judgment: restructuring a messy topic, resolving ambiguous merges, writing a synthesis, reviewing whether the system is still useful.

Spending intelligence evenly is lazy. The workflow should route work by risk and ambiguity.

For me, the shape is closer to three layers: raw inputs, maintained wiki pages, and generated outputs. Raw notes stay messy. The wiki layer gets maintained. Outputs are briefings, summaries, drafts, or decisions that can be thrown away or promoted back into the wiki.

The mistake is asking AI to search the raw pile forever. That turns every question into archaeology. The better pattern is persistent synthesis: keep a maintained layer so knowledge can compound.

The raw material still matters. I just do not want to reread it every time I ask a question.

Noticed, acted, verified, reported. Escalated only when blocked.

That is the difference between an agent and a chatbot wearing a tool belt. The weak version notices something and talks about it. The useful version does the next safe thing, checks whether it worked, and reports only when the message carries signal.

The hard part is not sounding proactive. The hard part is being precise about state. What was observed directly? What was reported by another system? What was inferred? What is the next concrete action?

False confidence is worse than silence. If an agent says it is watching, there should be a real watcher. If it says something changed, it should know how it verified that change.

The useful split is simple: identity belongs to the domain, mail hosting is replaceable. The public address should survive provider changes. Forwarding, aliases, and mailbox backends are implementation details.

This matters more for agents than for normal email because the address becomes part of the system boundary. It receives alerts, forwards tasks, signs up for services, and becomes a durable contact point for automation.

If the identity is portable, the rest can stay boring.

There is an input, a plan, a tool call, a result, maybe a memory layer. The names change. The diagrams get more complicated. The core loop is usually the same.

The real differences show up when something breaks. Can the agent recover from a bad tool result? Can it preserve state across a long task? Can a human interrupt without corrupting the workflow? Can the system explain what happened after the fact?

That is where the architecture becomes visible. Not in the demo. In the retry, the handoff, the checkpoint, the review boundary.

That is the part I keep coming back to. The demos are all about generation: write the component, build the app, fix the bug, scaffold the service. The quieter cost shows up after the code exists. Someone still has to decide whether the code should exist, whether the shape is right, and whether the extra surface area is worth owning.

The frontier teams are already living in that world. OpenAI said GPT-5.3-Codex was “instrumental in creating itself.” Reports around Claude Code and Cowork tell the same story from the Anthropic side: small human teams describe the work, steer the agent, and review the output. That sounds like a productivity win until you follow the burden all the way to the reviewer.

The old bottleneck was getting enough code written. The new bottleneck is proving that a larger amount of code is necessary, understandable, and covered by the right tests.

I think the review question is changing. It used to be “does this work?” That question still matters, but it is no longer enough. The more useful question is “should this much code exist?”

LogRocket had an example that stuck with me: a 29-line implementation turned into 186 lines from Claude Code. Same feature. More branches, more defensive handling, more surface area. That is not automatically bad. Sometimes the generated version is catching real edge cases. But someone has to read every line and decide which parts are care and which parts are clutter.

The OCaml maintainers ran into the harsher version of this. They rejected a 13,000-line AI-generated pull request. The issue was not simply whether the code compiled. It was review bandwidth, ownership, copyright risk, and whether future maintainers could explain the code at 2 a.m. when it broke.

That last part matters more than the benchmark charts. Code that works today but is not understood by anyone on the team is not free. It is borrowed confidence.

Cursor buying Graphite made more sense to me after that. Code generation is crowded. Review is where the pressure lands. Agent Trace is interesting for the same reason. Knowing which model produced a line, which conversation led to it, and which commit carried it gives teams a better audit trail. It does not prove the code is correct, but it gives reviewers a starting point.

Payments makes this less abstract. A sloppy UI branch is annoying. A sloppy payment path is a support queue, a reconciliation problem, a chargeback trail, or an audit conversation. “The AI wrote it and I glanced at the diff” is not a serious answer when money moved incorrectly.

The security numbers are ugly enough that I do not want to overstate them. The exact rates will move around as models and tooling change. The direction is still hard to ignore: AI-generated code is producing more review findings, more logic mistakes, and more security issues than teams expected. If generated code touches auth, money movement, customer data, or accounting state, the burden of proof needs to go up, not down.

This is the uncomfortable part: most developers do not love review. We understand why it exists, but given a choice between building something and auditing someone else’s patch, most of us would rather build. AI makes that tradeoff sharper. Now the patch may be larger, more polished, and less connected to a human author’s intent.

So the engineering job shifts. Less typing, more specification. Less authorship, more verification. The valuable skill is not producing lines quickly. The valuable skill is knowing what correct means before the lines exist, then building enough evidence that the team can trust the result.

That is why tests keep coming back into the center of this for me. Tests are not magic, and a green suite can still miss the important bug. But without tests, AI-assisted development turns into review by vibes. The code compiles. The assistant sounds confident. Everyone is tired. The diff goes in.

The path forward is probably less glamorous than the demos: smaller PRs, clearer ownership, traceable AI use, tests written against the requirement, property checks where invariants matter, and reviewers who are allowed to reject code they cannot explain.

I do not think this makes AI coding bad. I think it makes review discipline more important than generation speed. If the team cannot review the work, the speed is fake.

Sources I kept around while editing:

• OpenAI on GPT-5.3-Codex
• Axios on Anthropic Cowork
• LogRocket on AI moving the bottleneck to review
• DevClass on the OCaml AI-generated pull request
• Cursor’s Agent Trace spec
• Cursor on Graphite joining Cursor
• Addy Osmani on proving AI-written code works
• ITPro on AI-generated code security findings
• Cortex on engineering in the age of AI

That sounds obvious, but the pressure changes when code volume goes up. A human reviewer can skim a small patch and build a mental model. With generated code, that model gets expensive quickly. There is more surface area, more defensive branches, more plausible-looking glue.

Tests become the review surface. They are not proof that the design is good, but they force the generated work to state what it thinks should be true.

Without tests, AI-assisted development drifts toward vibes. The code compiles, the assistant sounds confident, and everyone is tired enough to accept the diff.

Why this setup?

Running your own AI gateway gives you control over your agents: their tools, memory, model providers, and who can access them. This guide sets up shared infrastructure where each agent is managed independently but uses a single Docker image and provisioning system.

Use cases:

• Personal agent and partner/family agent on the same server
• Team of specialized agents under one roof: research, ops, comms
• Development and production agents side by side

Architecture

/opt/openclaw/
├── repo/                             # Cloned openclaw source
├── Dockerfile                        # Custom image with extra CLI tools
├── templates/
│   ├── docker-compose.template.yml   # Per-agent compose template
│   └── env.template                  # Per-agent .env template
├── scripts/
│   ├── provision-agent.sh            # One-command agent provisioning
│   └── status.sh                     # Multi-agent status dashboard
├── total-recall/                     # Shared Total Recall source
├── docker-compose.<agent>.yml        # Generated per agent
├── .env.<agent>                      # Secrets per agent (mode 0600)
└── ports.conf                        # Port registry

/home/<agent>/.openclaw/              # Per-agent persistent data
├── openclaw.json                     # Agent config
├── workspace/                        # Working directory
│   ├── memory/                       # Total Recall observations
│   └── logs/                         # Observer/reflector logs
└── skills/
    └── total-recall/                 # Memory system installation

Each agent runs in its own Docker container with:

• Dedicated Linux user and home directory
• Unique port bound to 127.0.0.1
• Independent systemd unit for auto-start
• Its own gateway token and secrets
• Total Recall memory system with autonomous observation

Access is exposed via Tailscale Serve, with HTTPS inside the tailnet, and locked down with Tailscale ACLs per user.

Prerequisites

• A VPS or dedicated server, ARM64 or x86_64
• Ubuntu 22.04+ or Debian 12+
• Docker Engine installed
• Tailscale installed and authenticated
• At least 2 GB RAM per agent, plus OS overhead

Tested on

• Hetzner CAX11: 4 ARM64 cores, 8 GB RAM, 80 GB disk, Ubuntu 24.04
• Comfortable for 2 agents, feasible for 3

Step 1: System preparation

Add your user to the Docker group

sudo usermod -aG docker $USER
newgrp docker  # or re-login

Create swap

This is recommended for a small VPS.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Low swappiness: prefer RAM, use swap as safety net
sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-openclaw.conf

Configure Docker log rotation

Prevent logs from eating the disk:

sudo tee /etc/docker/daemon.json << 'EOF'
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
EOF
sudo systemctl restart docker

Step 2: Directory structure

sudo groupadd openclaw
sudo usermod -aG openclaw $USER
sudo mkdir -p /opt/openclaw/{repo,templates,scripts}
sudo chown -R $USER:openclaw /opt/openclaw
chmod 750 /opt/openclaw

Step 3: Build the Docker image

Clone OpenClaw

git clone https://github.com/openclaw/openclaw.git /opt/openclaw/repo

Create a custom Dockerfile

This extends the official image with additional CLI tools. Adjust the tool list to your needs. The example includes Gmail, WhatsApp, and Google Places CLIs.

# /opt/openclaw/Dockerfile

# Stage 1: Build any tools that lack prebuilt binaries for your arch
FROM golang:1.25-bookworm AS wacli-builder
RUN apt-get update && apt-get install -y --no-install-recommends gcc libc6-dev git ca-certificates \
    && rm -rf /var/lib/apt/lists/*
WORKDIR /build
RUN git clone --depth 1 https://github.com/steipete/wacli.git .
RUN CGO_ENABLED=1 go build -tags sqlite_fts5 -o /usr/local/bin/wacli ./cmd/wacli

# Stage 2: Extend the base image
FROM openclaw:base

USER root

# System dependencies for Total Recall (inotify, cron) and networking (socat)
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
    socat \
    inotify-tools \
    cron \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Install prebuilt CLI tools (adjust URLs for your architecture)
RUN curl -fsSL https://github.com/steipete/gogcli/releases/download/v0.11.0/gogcli_0.11.0_linux_arm64.tar.gz \
    | tar -xz -C /usr/local/bin gog \
    && chmod +x /usr/local/bin/gog

RUN curl -fsSL https://github.com/steipete/goplaces/releases/download/v0.3.0/goplaces_0.3.0_linux_arm64.tar.gz \
    | tar -xz -C /usr/local/bin goplaces \
    && chmod +x /usr/local/bin/goplaces

# Install tools built from source
COPY --from=wacli-builder /usr/local/bin/wacli /usr/local/bin/wacli
RUN chmod +x /usr/local/bin/wacli

USER node

For x86_64, replace arm64 with amd64 in the download URLs.

Build

# Build base image from repo
docker build -t openclaw:base -f /opt/openclaw/repo/Dockerfile /opt/openclaw/repo

# Build custom image with tools
docker build -t openclaw:latest -f /opt/openclaw/Dockerfile /opt/openclaw

# Verify
docker run --rm openclaw:latest sh -c "which gog wacli goplaces"

Step 4: Create templates

Docker Compose template

# /opt/openclaw/templates/docker-compose.template.yml

services:
  openclaw-__AGENT_NAME__:
    image: openclaw:latest
    container_name: openclaw-__AGENT_NAME__
    env_file:
      - /opt/openclaw/.env.__AGENT_NAME__
    environment:
      HOME: /home/node
      TERM: xterm-256color
    volumes:
      - /home/__AGENT_NAME__/.openclaw:/home/node/.openclaw
      - /home/__AGENT_NAME__/.openclaw/workspace:/home/node/.openclaw/workspace
    ports:
      - "127.0.0.1:__AGENT_PORT__:18789"
    init: true
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 2560M
          cpus: "2"
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:18789/"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    command: ["node", "openclaw.mjs", "gateway", "--allow-unconfigured", "--bind", "lan"]

Key design choices:

• 127.0.0.1 binding: ports are never exposed to the public internet
• init: true: proper PID 1 for signal handling and zombie reaping
• Resource limits: prevents one agent from starving the other
• Health checks: Docker and systemd know when an agent is actually working

Environment template

# /opt/openclaw/templates/env.template

# OpenClaw Gateway: __AGENT_NAME__
OPENCLAW_GATEWAY_TOKEN=__GATEWAY_TOKEN__
OPENAI_API_KEY=
GOG_KEYRING_PASSWORD=__GOG_KEYRING_PASSWORD__

# Total Recall (memory system LLM: cheap model via OpenRouter)
LLM_BASE_URL=https://openrouter.ai/api/v1
LLM_API_KEY=
LLM_MODEL=google/gemini-2.5-flash

Step 5: Install Total Recall

Total Recall gives each agent autonomous memory. It watches conversations, compresses them into observations, and consolidates nightly. With cheap models through OpenRouter, it costs about $0.10/month per agent.

git clone https://github.com/gavdalf/total-recall.git /opt/openclaw/total-recall

The provisioning script handles per-agent installation automatically.

Step 6: The provisioning script

This is the core automation. Running provision-agent.sh <name> creates everything an agent needs.

# /opt/openclaw/scripts/provision-agent.sh

What it does:

1. Allocates the next available port from ports.conf
2. Creates a dedicated Linux user with a nologin shell and openclaw group
3. Creates the agent’s data directories with correct ownership, using uid 1000 for the container’s node user
4. Generates a unique gateway token and keyring password
5. Renders the compose file and .env from templates
6. Installs Total Recall into the agent’s workspace
7. Sets up host-level cron for memory observation every 15 minutes, reflection hourly, and dream cycles at 3am nightly
8. Creates and enables a systemd unit for auto-start on boot

The full script is available in the repository. This is the key pattern for the systemd unit it generates:

[Unit]
Description=OpenClaw Gateway - <agent_name>
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/openclaw
ExecStart=/usr/bin/docker compose -f <compose_file> up -d
ExecStop=/usr/bin/docker compose -f <compose_file> down
ExecReload=/usr/bin/docker compose -f <compose_file> restart
TimeoutStartSec=120

[Install]
WantedBy=multi-user.target

And the Total Recall cron entries it installs:

# Observer: compress recent conversations every 15 minutes
*/15 * * * * docker exec openclaw-<agent> bash -c 'OPENCLAW_WORKSPACE=... bash .../observer-agent.sh'

# Reflector: consolidate when observations grow large
0 * * * * docker exec openclaw-<agent> bash -c 'OPENCLAW_WORKSPACE=... bash .../reflector-agent.sh'

# Dream Cycle: nightly memory consolidation
0 3 * * * docker exec openclaw-<agent> bash -c 'OPENCLAW_WORKSPACE=... bash .../dream-cycle.sh preflight'

Step 7: Provision your agents

sudo /opt/openclaw/scripts/provision-agent.sh alice
sudo /opt/openclaw/scripts/provision-agent.sh bob

Each run prints the gateway token and next steps. Save those tokens. You need them to connect.

Configure the gateway

Each agent needs an openclaw.json with allowed origins for the Control UI. Create one per agent:

# Replace the hostname and port for each agent
sudo tee /home/alice/.openclaw/openclaw.json << 'EOF'
{
  "gateway": {
    "mode": "local",
    "controlUi": {
      "allowedOrigins": [
        "https://your-tailscale-hostname:18789",
        "http://127.0.0.1:18789"
      ]
    }
  }
}
EOF
sudo chown 1000:1000 /home/alice/.openclaw/openclaw.json

Configure model access

Option A: add OPENAI_API_KEY to /opt/openclaw/.env.<agent>.

Option B: use a ChatGPT/Codex subscription with OAuth:

docker exec -it openclaw-alice openclaw models auth login --provider openai-codex

Start

sudo systemctl start openclaw-alice openclaw-bob

Step 8: Expose via Tailscale Serve

Tailscale Serve gives you HTTPS access within your tailnet: no port forwarding, no certificates to manage, and no exposure to the public internet.

sudo tailscale serve --bg --https=18789 http://127.0.0.1:18789
sudo tailscale serve --bg --https=18790 http://127.0.0.1:18790

You may need to enable Serve for your node first in the Tailscale admin console.

Access from any device on your tailnet:

• https://your-vps-hostname:18789/: Alice
• https://your-vps-hostname:18790/: Bob

Step 9: Lock down access with Tailscale ACLs

This is where multi-user access gets interesting. Tailscale ACLs let you control exactly who can reach which agent.

Go to https://login.tailscale.com/admin/acls and set your policy:

{
  "tagOwners": {
    "tag:openclaw": ["your-login@example.com"]
  },

  "groups": {
    "group:admin":  ["your-login@example.com"],
    "group:family": ["partner@example.com"]
  },

  "acls": [
    // Admin: full access to everything
    {
      "action": "accept",
      "src":    ["group:admin"],
      "dst":    ["*:*"]
    },

    // Family: only their agent, nothing else
    {
      "action": "accept",
      "src":    ["group:family"],
      "dst":    ["your-vps-hostname:18790"]
    }
  ],

  // Restrict SSH to admins only
  "ssh": [
    {
      "action": "accept",
      "src":    ["group:admin"],
      "dst":    ["tag:openclaw"],
      "users":  ["your-ssh-user"]
    }
  ],

  // Prevent accidental Funnel exposure
  "nodeAttrs": [
    {
      "target": ["tag:openclaw"],
      "attr":   ["funnel": false]
    }
  ]
}

Then tag your VPS as tag:openclaw in the admin console: Machines, your VPS, Edit, Tags.

Invite additional users

1. Tailscale admin console: Users, Invite by email
2. They install Tailscale and join with their email
3. Add their email to the appropriate group in your ACL policy
4. Add an ACL rule granting access to their specific agent port
5. Share only their agent’s gateway token

Step 10: Connecting your client

Install the OpenClaw client on your local machine following the official installation docs. Once installed, point it at your self-hosted gateway:

openclaw gateway connect \
  --url "https://your-tailscale-hostname:18789" \
  --token "your-gateway-token-here"

The gateway URL is your VPS’s Tailscale hostname plus the agent’s port. The token was printed during provisioning and is stored in /opt/openclaw/.env.<agent> on the server.

Per-agent profiles

If you connect to multiple agents from the same machine, use profiles to switch between them:

# Save each agent as a named profile
openclaw gateway connect \
  --url "https://your-tailscale-hostname:18789" \
  --token "..." \
  --profile alice

openclaw gateway connect \
  --url "https://your-tailscale-hostname:18790" \
  --token "..." \
  --profile bob

# Switch between agents
openclaw gateway use alice
openclaw gateway use bob

For other users

Share only what they need:

1. The gateway URL for their agent, for example https://your-tailscale-hostname:18790
2. Their agent’s gateway token
3. A link to install the OpenClaw client

They do not need SSH access, Docker access, or server credentials. Tailscale handles authentication and encryption. They just need Tailscale installed and access to your tailnet.

# What you send them:
openclaw gateway connect \
  --url "https://your-tailscale-hostname:18790" \
  --token "their-token-here"

Web UI alternative

Every agent also serves a Control UI in the browser. No client install needed. Visit the gateway URL directly:

https://your-tailscale-hostname:18790/

The browser prompts for the gateway token on first visit.

Scaling

Adding a new agent

sudo /opt/openclaw/scripts/provision-agent.sh <name>
# Add OPENAI_API_KEY to /opt/openclaw/.env.<name>
# Create /home/<name>/.openclaw/openclaw.json with allowed origins
sudo systemctl start openclaw-<name>
sudo tailscale serve --bg --https=<port> http://127.0.0.1:<port>
# Update Tailscale ACLs if new users need access

Checking status

sudo /opt/openclaw/scripts/status.sh

Output:

========================================
OpenClaw Agent Status
========================================

AGENT        PORT   CONTAINER    SYSTEMD    HEALTH
-----        ----   ---------    -------    ------
alice        18789  running      active     healthy
bob          18790  running      active     healthy

Resource Usage:
  openclaw-alice: CPU=0.01% MEM=334MiB / 2.5GiB
  openclaw-bob:   CPU=0.00% MEM=324MiB / 2.5GiB

Capacity planning

Each agent idles at about 330 MiB and peaks around 1-1.5 GiB under load.

Verification checklist

After deployment, run through these checks:

• [ ] docker ps: all containers running and healthy
• [ ] curl http://127.0.0.1:<port>/: each gateway returns HTTP 200
• [ ] Access https://your-hostname:<port>/ from your device: UI loads
• [ ] Access from restricted user’s device: only their agent is reachable
• [ ] sudo /opt/openclaw/scripts/status.sh: all agents show healthy
• [ ] Reboot the VPS: agents auto-start via systemd
• [ ] docker exec openclaw-<agent> which gog wacli goplaces: CLI tools present
• [ ] ls /home/<agent>/.openclaw/workspace/memory/: observations.md exists
• [ ] sudo crontab -l: Total Recall cron entries present for all agents

Troubleshooting

Gateway fails with an allowedOrigins error

The gateway refuses to start when binding to LAN without explicit CORS origins. Create or update openclaw.json:

{
  "gateway": {
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["https://your-hostname:PORT", "http://127.0.0.1:PORT"]
    }
  }
}

Container keeps restarting

docker logs openclaw-<agent> --tail 20

Common causes: missing config, port conflict, permission issues on mounted volumes.

Total Recall is not observing

Check that the cron entries exist and the container is named correctly:

sudo crontab -l | grep <agent>
docker exec openclaw-<agent> ls /home/node/.openclaw/skills/total-recall/scripts/

Check observer logs:

tail -f /home/<agent>/.openclaw/workspace/logs/observer.log

Tailscale Serve will not start

Visit the link in the error output to enable Serve for your node in the Tailscale admin console. This is a one-time approval per node.

SSH hardening

Move SSH to a non-standard port and lock down authentication.

Config is split across /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/*.conf.

# Key settings to ensure:
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 2
X11Forwarding no
AllowAgentForwarding no

Reload after changes:

sudo systemctl reload ssh

SSH keypair

Generate an Ed25519 keypair on your local machine:

ssh-keygen -t ed25519

Copy the public key to the server’s ~/.ssh/authorized_keys.

Firewall (UFW)

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Initially allow SSH on the public interface:

sudo ufw allow 2222

After Tailscale is set up, restrict SSH to the Tailscale interface only:

sudo ufw allow in on tailscale0 to any port 2222
sudo ufw delete allow 2222

Fail2Ban

Install and enable fail2ban to block brute-force attempts:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Unattended upgrades

Ensure automatic security updates are enabled:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Tailscale (zero-trust network)

Install Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Tailscale starts on boot automatically (tailscaled.service is enabled by default).

Once connected, lock down the firewall to Tailscale-only SSH. This makes SSH invisible on the public internet.

Disable unused services

Disable and mask serial consoles that are not needed:

sudo systemctl disable --now serial-getty@ttyAMA0.service serial-getty@ttyS0.service
sudo systemctl mask serial-getty@ttyAMA0.service serial-getty@ttyS0.service

Final state

• SSH only accessible via Tailscale on port 2222
• Key-only authentication, no root login
• Brute-force protection via fail2ban
• Automatic security updates
• No unnecessary services running