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

Start by reading the root README.md, amplify.yml, and customHttp.yml, then inspect the app build scripts and worker scripts named in the issue. Compare the existing deployment headers and build outputs with the proposed Docker and Compose setup, and resolve the open questions about shared configuration, worker services, and Puter dependencies with maintainers. Done means a documented self-hosting path that builds and serves selected apps with the required headers.

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