Feature request: Dockerfile + docker-compose for self-hosted deployment

Summary

Right now the only documented way to run an app is per-folder npm install && npm run dev, and the only documented production path is AWS Amplify (amplify.yml + customHttp.yml at the repo root).

There is no container image, no compose file, and no nginx/Caddy config anywhere in the repo — I walked the full file tree on main (34,886 paths) and found zero matches for Dockerfile, docker-compose, compose.yml or nginx.

That makes self-hosting impractical. Someone who wants these apps on their own VPS/NAS/home lab currently has to clone the repo, install Node 22.12+, run a build in each of the 51 app folders, and then hand-write a static file server that reproduces the caching behaviour the apps actually depend on.

What would make self-hosting work

1. A Dockerfile per app (or one parameterized Dockerfile plus a build arg) that:
   • builds in node:22 (README requires >= 22.12),
   • runs npm ci && npm run build,
   • serves dist/ from a multi-stage nginx or Caddy runtime image,
   • runs non-root and declares a HEALTHCHECK.
2. A docker-compose.yml at the repo root that brings up a chosen set of apps behind one reverse proxy on a single port, so a self-hoster gets one URL per app.
3. A short "Self-hosting" section in README.md with the exact docker compose up -d commands.

The part that's easy to get wrong: customHttp.yml

The Amplify config encodes real application behaviour, not just cosmetics. An nginx image would have to reproduce it, and I'd be happy to help get it right:

• / and **/*.html → no-cache, max-age=0, s-maxage=0, must-revalidate
• /assets/* → public, max-age=31536000, immutable (Vite content hashes)
• /assets/*.wasm → additionally Content-Type: application/wasm (circuits, parametric, music-studio)
• /sw.js, /worker/*, /manifest.json → no-cache, ... (teamchat, fleet, legal, property-management, help-desk, solitaire, cad, and others)
• chess, backgammon, checkers additionally ship a full Content-Security-Policy plus X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Strict-Transport-Security

Getting this wrong is not cosmetic: a stale sw.js pins returning users to an old build forever, and a missing application/wasm content type breaks the CAD / circuits / parametric engines outright.

Open questions

• Where should this live? One Dockerfile + compose file inside each of the 51 app folders is a lot of duplication. A shared deploy/ directory, or a single parameterized Dockerfile driven by a build arg, might be cleaner — I'd like to follow the maintainers' preference here.
• What about the worker components? documents, spreadsheet, teamchat, help-desk, fleet, legal and property-management have build:worker / deploy:email-worker scripts targeting Cloudflare Workers. Should the compose file run those locally too (workerd / wrangler dev), or is the expectation that they stay external and just get documented?
• How self-hosted is "self-hosted"? Several apps pull the Puter SDK from https://js.puter.com and talk to api.puter.com, and the shipped CSPs allow those origins. Should there be a documented path to point an app at a self-hosted Puter instance (cf. HeyPuter/puter), and would the baked-in CSPs need to become configurable?

Why it seems worth doing

The project's goal is free, open-source alternatives to proprietary software, and the audience for that is exactly the group that wants to self-host: home labs, small teams, privacy-sensitive organisations, people without an AWS account. docker compose up -d is the interface that audience already knows.

I'm happy to contribute a PR — for example documents and spreadsheet as a reference implementation, including the nginx header rules — if the approach is agreeable. Just wanted to check the direction before writing 51 near-identical Dockerfiles.

Checklist

• I have searched the existing issues and discussions for this and believe it is new
• I have read the contributing guidelines / README deployment notes