easterbrooka/mike: storage layer generalized to support AWS S3, ECS-ready Dockerfile added
easterbrooka extended the backend storage client so it can talk to either Cloudflare R2 or native AWS S3 without code changes, then added a multi-stage Dockerfile aimed at ECS Fargate. Both pieces landed in PR #1.
The storage.ts rewrite makes endpoint and credentials optional. When R2_ENDPOINT_URL is absent the SDK talks directly to S3; when R2_ACCESS_KEY_ID and R2_SECRET_ACCESS_KEY are absent, the SDK's default credential provider chain runs instead, picking up an ECS task role automatically. Region resolution is layered: R2_REGION wins, then AWS_REGION (auto-set inside ECS), then "auto" as the R2 fallback. Existing R2 deployments pass through unchanged as long as R2_ENDPOINT_URL is still set.
One behavioral shift worth noting: storageEnabled now returns true when AWS_REGION is set even without explicit credentials. Previously it required all three cred vars. Any code that gates upload paths on storageEnabled will start seeing true in an AWS-ambient environment even before credentials are explicitly configured.
The Dockerfile is a two-stage build on node:22-bookworm-slim. The runtime layer installs libreoffice-core, libreoffice-writer, fonts-liberation, and tini. LibreOffice runs as the node user, which requires /home/node/.config to be writable - the Dockerfile handles that explicitly. Signal handling goes through tini so the soffice subprocess gets cleaned up correctly. The .dockerignore keeps the build context to source and lockfiles; dev artifacts, secrets, and the old nixpacks.toml are excluded.
The env example was rewritten to document the two deployment shapes side by side, with inline comments explaining when to omit credentials for task-role auth.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?