Files

T

dsql f9e5e4f24d split Deploy into a hub + 3 sub-pages; inline comments over annotations

The Deploy page got long and the code annotations rendered inconsistently
(some as (n) numbers, some as clickable +, and a marker on a fully-commented
line made that line vanish). Fix both:

- Deploy is now a HUB (docs/deploy/index.md): the intro + collision rule +
  central-deploy note, then card links to three focused sub-pages. Deploy
  stays the single global-nav entry; sub-pages are not_in_nav, reached from
  the hub cards.
  - deploy/compose.md — compose convention, storage tiers, how deploy fills
    it in, subprocess/browser knobs, checklist
  - deploy/dockerfile.md — services-account image, COPY, layer caching, uv
  - deploy/secrets.md — keeping secrets out of the image
- Replace code annotations with INLINE COMMENTS on the compose/Dockerfile
  examples: everything visible at once, no + to click, and the commented
  MOUNTS_DIR line no longer disappears.
- Update inbound links (index card, standards, workflow, environments) to
  deploy/ and deploy/compose.md; nav Deploy -> deploy/index.md with
  not_in_nav for the sub-pages.

Verified in-browser: hub cards link correctly, sub-pages render with visible
inline comments (0 annotation markers), left nav shows only Deploy;
mkdocs build --strict clean (validates not_in_nav + all cross-links).

Signed-off-by: disqualifier <dev@disqualifier.me>

2026-07-01 02:32:16 -04:00

2.0 KiB

Raw Blame History

Deployment Guide

How a project gets onto rethink-net — our Ubuntu 26.x servers. Get your container to follow a few consistent rules and deploying is mostly handing us a compose.yaml.

!!! tip "What can run here" APIs, websites, applets, bots, monitors.

!!! danger "Your compose names nothing repo-specific" No container_name. No hardcoded names, workspace, or /srv paths. The deploy layer injects identity and host paths at deploy time — your compose stays generic so it can't collide with any other service on the fleet.

- service key is always **`svc`**
- named volumes use **bare names** (`cache`, not `myapp_cache`)
- host paths come from **`${LOGS_DIR}` / `${CONFIG_DIR}`**

Naming things after your repo used to cause **container-name collisions** at
fleet scale — two repos shipping the same name clashed. The generic compose
convention fixes that.

!!! note "You don't run any deploy commands" All services are deployed centrally by the ops tooling. You don't pick a host, manage keys, or run anything — just make your repo follow the compose convention and it's deployable. At deploy time the tooling generates the environment your compose reads (${LOGS_DIR}, ${CONFIG_DIR}, optional ${MOUNTS_DIR}), so the same file works locally and on the fleet.

The three things your repo needs

:material-file-cog: Compose convention

The compose.yaml your repo ships — generic svc service, the ${...} host mounts, storage tiers, and how deploy fills it in.
:material-docker: Dockerfile & build

The uid-agnostic image (services account 1337), getting files in with COPY, layer caching, uv, and subprocess/browser workloads.
:material-key: Secrets

How secrets stay out of the image and reach the container read-only at runtime.

2.0 KiB Raw Blame History

Deployment Guide

The three things your repo needs

2.0 KiB

Raw Blame History