With dev and prod open side by side in the same browser, the tabs were
indistinguishable. ENV is written into the title of every page unless it says
prod, so "dev · Foodster" picks itself out. The value is used verbatim, so
ENV=staging labels itself too, and prod and production both count as unmarked
so a stray capital cannot tag the real instance.
Environment variables lose their prefix: PASSWORD, DB, ENV, ADDR, HOST, REPO,
TAG. The container namespaces them already, and this matches how the other
services here are configured.
PUID/PGID are the exception rather than UID/GID. UID is read-only in bash, so
a value set in .env would be silently replaced by the invoking shell's own and
compose's user: would ignore what was asked for.
Breaking for a running instance: the deployed .env has to be rewritten in the
same deploy, or the app will refuse to start on an unset PASSWORD.
The deployment is a public hostname behind Traefik rather than a LAN-only
box, which changes two things.
TLS is now terminated by the proxy, so Basic credentials are no longer in
cleartext. The container publishes no ports: doing so would leave an
unencrypted copy of the app on the host, bypassing the proxy. The hostname
lives in .env rather than compose.yaml, so no infrastructure detail is
committed and the MIT publication option stays open.
The password is now the only thing between the internet and the app, and a
500 ms sleep is not a defence at that exposure. Wrong guesses are rate
limited per client address: five in a burst, then one per ten seconds,
answered with 429.
Two details that decide whether this works at all:
- a request with no Authorization header is not charged. That is the
handshake every browser session opens with, and counting it would lock the
household out for simply opening the app a few times.
- X-Forwarded-For is believed only when the connection arrived from a private
address, i.e. through the proxy, and then only its last entry, which is the
one the proxy observed. A direct client could otherwise forge a fresh
address per attempt and walk past the limiter entirely.
None of this substitutes for a strong password. It removes brute force as a
practical route, nothing more. PRD §3, §9 and §10 are updated: "no external
internet exposure" is no longer true.
SQLite writes three files — the database plus its -wal and -shm companions.
Putting them in one directory means a deployment mounts a single path and a
backup copies a single directory.
- FOODSTER_DB defaults to ./data/foodster.db, and openDB creates the parent
directory on startup rather than failing on a fresh checkout
- compose bind-mounts ./data instead of using a named volume, so the file can
be listed, copied and opened with any sqlite client without going through
the container engine
- the image runs as UID 65534, which cannot write to a host directory owned
by someone else, so compose now sets user: from FOODSTER_UID/FOODSTER_GID
- `make up` creates ./data first: left to the engine it appears root-owned
and the app silently cannot write to it
Foodster is a self-hosted dinner log and meal suggester for one household.
Stage 1 (eating history) is in development; stage 2 (the suggester) follows
once there is enough history to weight against.
Replace the PRD's original stack (Nuxt, Postgres, Drizzle, Pico CSS) with
Go 1.27, net/http, templ, Datastar and SQLite — one static binary, no
Node.js in the build. Sections 3, 4, 5, 9, 10 and 11 are rewritten to match.
Record the decisions made while reviewing mockups:
- the UI is written in Finnish; PRD, code and comments stay English
- access is one shared password over HTTP Basic rather than open on the LAN
- images are CalVer vYYYYMMDD-N, built with Podman, run under Docker Compose
- registry coordinates live in .env, so no infrastructure detail is
committed and the MIT publication option stays open
mockups/ holds standalone HTML design studies. log-fi.html is the current
one; the others are superseded exploration kept for reference.
Esa Kataja