Build Log

This is the intentional changelog for the systems around the site: the development environment, maintenance automation, publishing workflow, and notable site features. The automatic Updates page answers which notes changed; this page records what capability was added and why.

Public entries replace private repository and hostname identifiers with functional placeholders; exact asset inventories stay in private operations records.

Each entry stays short:

• Added — new capabilities and commands;
• Changed — behavior that is now different;
• Verified — the checks that passed;
• Next — intentionally deferred work.

2026-08-09 — RSSHub Production Shadow Workload

Added

• The official RSSHub image, pinned by immutable digest in its own /srv/rsshub Compose project with memory cache, unless-stopped, and container health.
• HTTPS through rss.example.com, Caddy, and infra-edge; RSSHub port 1200 exists only inside Docker and has no host binding.
• A VPS-generated ACCESS_KEY and only the variables required by the representative Bilibili route, plus a keyless public-health monitor in Kuma.

Changed

• infra-edge now contains Caddy and RSSHub, with Caddy resolving the rsshub-prod alias.
• The current RSSHub release protects /healthz when ACCESS_KEY is enabled, so the container and Caddy use a route-bound derived code for health only; the raw key remains in the protected env file.
• The deployment remains a shadow: the existing feed consumer, its persistent data, scheduler, and local RSSHub are unchanged.

Verified

• Local, public, and authoritative DNS queries reached the VPS; HTTPS health returned 200 with valid TLS and HTTP returned 308.
• An unauthenticated real route returned 403. Authenticated local and VPS canaries matched the same RSS channel identity with 20 items and no error payload.
• Port 1200 was unreachable through both public and Tailscale host addresses; UFW, Tailscale-only SSH, Caddy, private Kuma, and zero failed systemd units remained intact.
• An RSSHub-only restart returned to running healthy without changing the Caddy or Kuma containers. A temporary downstream compatibility canary fetched representative items without touching production data.

Next

• Keep SQLite backup/restore, scheduler migration, RSSHub endpoint cutover, and local-fallback retirement together in a controlled Phase 4.

2026-08-09 — Shared VPS Ingress and Private Monitoring

Added

• Caddy as the only public Docker ingress, publishing only host TCP 80/443, plus the reusable external bridge infra-edge.
• Uptime Kuma with persistent data and an exact 127.0.0.1:3001 management binding, reachable only through a local-forward tunnel over Tailscale SSH.
• An HTTPS /healthz endpoint for infra.example.com, with Caddy managing its certificate and HTTP-to-HTTPS redirect.

Changed

• Infrastructure acceptance no longer treats “UFW active” as sufficient evidence for Docker port safety. Every deployment now checks Compose bindings, docker inspect, host sockets, UFW, and probes from another machine together.
• Added a controlled reboot survival check: reconnect only through Tailscale, then revalidate management access, containers, persistent state, TLS, denied paths, and failed units.

Verified

• The exposure audit found only Caddy TCP 80/443 on public addresses; Uptime Kuma's sole host binding was 127.0.0.1:3001, with no other Docker host publications.
• Public-IP SSH and TCP 3001 timed out from WSL2. With normal certificate validation, the HTTPS health endpoint returned 200 and ok, while HTTP returned 308.
• After one controlled reboot, Tailscale, Docker, Caddy, and healthy Kuma recovered automatically, Kuma's initialized state persisted, and systemctl --failed reported zero units.

Next

• Keep application migrations, image pinning, backup implementation, and restore drills as separate later phases instead of expanding the shared-ingress change.

2026-08-04 — WSL Development Environment Refresh

Added

• A safe configuration snapshot workflow with checksums, Conda exports, package lists, and restoration helpers. Projects, private SSH keys, and shell secrets are deliberately excluded.

• A maintain command for routine Ubuntu maintenance:

  maintain status   # disk, caches, and pending updates
  maintain update   # safe in-place Ubuntu upgrades
  maintain clean    # reproducible package caches only
  maintain all      # update, clean, and report

• Automatic Ubuntu security updates through systemd, limited to official security origins and configured never to reboot WSL automatically.

• Small command-line tools for everyday work: fd, jq, shellcheck, pipx, ncdu, direnv, and hyperfine.

• An optional Windows-side VHDX compaction helper for reclaiming host disk space after large Linux cache cleanups.

Changed

• Node.js moved from 20 to 24.18.1 and the site's pinned version was updated with it.
• Conda no longer activates base for every terminal. It loads on first use, so conda activate <environment> still works while ordinary shells use Ubuntu's Python.
• Shell startup now removes duplicate PATH entries, uses safer Git and system aliases, and integrates zoxide and direnv.
• Package caches were reduced by about 18 GB. This creates free space inside WSL; shrinking the Windows VHDX remains a separate, explicit operation.

Verified

• Docusaurus production builds completed for English, Simplified Chinese, and French.
• The Vite and Next.js projects passed their relevant build and test checks; known pre-existing lint debt was left unchanged.
• Ubuntu completed all pending package updates with no broken or half-configured packages.
• Fresh-shell testing confirmed lazy Conda activation, a deduplicated PATH, and working maintenance commands.
• The final configuration snapshot passed every SHA-256 check and contained no private key or secrets file.

Next

• Move daily development from root to a normal WSL user only after active repository work is committed or otherwise secured.
• Keep project migration separate from environment maintenance so file ownership and VS Code reconnection remain easy to verify and roll back.

Entry Template

## YYYY-MM-DD — Short Outcome

### Added
- New capability and its primary command or entry point.

### Changed
- Important behavior change and why it was made.

### Verified
- Build, test, health check, or backup result.

### Next
- Deliberately deferred work, if any.

My reading · Opened notes are remembered in this browser.