Day 0 — Server foundations

Debian, partitioning, Docker, Nginx, and a reproducible base so the KM0 stack stays auditable and operable.

Introduction

Day 0 is dedicated to foundations: without a reproducible operating system and working environment, any later stack would be fragile and hard to audit.

The goal is to end the day with stable Debian, an orderly disk layout, minimal but sufficient tooling, and a shell that encourages documenting every change.

Infrastructure

Bootstrap technical plan

KM0 aims for infrastructure the team can operate without opaque proprietary panels. The full bootstrap picture includes:

  • System: VPS on up-to-date Debian with partitions separating system from data where needed (clearer snapshots and backups).
  • Collaboration: OpenCloud as microservices on an official OpenCloud.eu image, with stable volumes (COMPOSE_PROJECT_NAME) independent of the Compose working directory.
  • Perimeter: Nginx as the sole HTTPS front; Docker publishing HTTP only on 127.0.0.1.
  • Communication: Dockerized Astro on another loopback port; separate vhosts for km0digital.com and cloud.km0digital.com.
  • Observability: rotated logs (json-file), runbooks with docker compose ps, logs, pull, and compressed volume backups.
  • Evolution: production TLS internally, automated backups, and Fail2ban per specific jails.

Disk and system

VPS provisioning and partitions

Debian was chosen for predictable packages and hands-on documentation, without mandatory control panels. The first step was to review disk layout:

  • Separate project data from the root filesystem when volume-level backup is needed.
  • Define mounts deliberately: /var/lib/docker may concentrate OpenCloud I/O depending on VPS size.
  • Document conventions to tell persistent mounts from the operating system.
Exact partition maps depend on provider and contracted size. They must live in the project wiki or runbook, not only in this blog, for disaster recovery.

Base packages

Base software

A reasonable minimum was installed for secure remote administration and Docker, without bloat:

  • Common utilities: curl, editors, network and diagnostics.
  • Docker Engine with rotated logs in /etc/docker/daemon.json.
  • Nginx from system packages as a stable front.
  • Certbot and TLS by phase (HTTP-01 or self-signed certificate in the lab).

Each piece has an observable role: systemctl status, nginx -t, docker compose ps.

Console

Shell ergonomics

For consistent SSH sessions, the wiki initialConfiguration guide was applied:

  • Readable Bash prompt (path, command status, visual hints).
  • History and safe defaults that reduce repeated mistakes.
  • Aliases and PATH geared toward Compose and Git under /opt/....

This base, documented off-server, lets the same template be repeated on other VPS instances without improvising.

Tooling

cursor-agent

Command-line assistance

cursor-agent was installed to bring daily work closer to an assisted development flow: reviews, helper scripts, and incremental documentation from the console.

It does not replace human review or team controls, but it lowers friction on repeatable tasks (Compose overlays, validating Nginx before reload, etc.).

End of day

State at the end of day 0

By the end of the day, the server satisfies three properties:

  1. Auditable: known disk layout and packages.
  2. Repeatable: main steps linked to wiki and runbooks.
  3. Ready for Docker without exposing services publicly too early.

Next step

Day 1

Day 1 brings up OpenCloud, the proxy virtual host, and the KM0 site over TLS. In the meantime, explore the published services or get in touch if you want to collaborate.