Summary

Three things to make the enclave-projects fork easier to discover, deploy and consume:

1. .github/workflows/docker.yml — automatic Docker image on every commit

Adds a GitHub Actions workflow that builds and publishes a container image to GHCR (ghcr.io/enclave-projects/opencloud) on:

• every push to main → tags latest + main-<short-sha>,
• every v* git tag → tags vX.Y.Z, X.Y, X, latest,
• every PR → builds the image to verify it still compiles, without pushing,
• manual workflow_dispatch → opt-in push for ad-hoc tags.

Implementation notes:

• Multi-arch: linux/amd64 + linux/arm64, via QEMU + Buildx.
• Authentication uses the workflow-scoped GITHUB_TOKEN (packages: write); no additional secrets required.
• Builds re-use the GHA cache (type=gha,mode=max) for incremental layers.
• concurrency cancels in-progress PR builds when a new commit is pushed to the same PR.
• permissions: is scoped to contents: read + packages: write only.

The repo's existing CI runs on Woodpecker (.woodpecker.star); this workflow is purely additive and does not change the Woodpecker pipeline.

2. README.md — fork banner, added features, deploy pointer

Replaces the upstream-mirrored README with a fork-aware version that:

• Adds a prominent banner at the top stating this is the enclave-projects fork of opencloud-eu/opencloud.
• Lists the features added in this fork (video previews/thumbnails, with full env-var table) — this section is structured so future fork features slot in without restructuring the README.
• Links to the new DEPLOYMENT.md for self-hosters.
• Adds a Docker badge linking to the GHCR package page.
• Keeps the upstream Build from source, Technology, Security and Getting involved sections so contributors can still build locally without surprise.

3. DEPLOYMENT.md — step-by-step deploy guide

A new top-level deployment guide aimed at developers who want to run this fork on their own server. Sections:

1. Prerequisites & sizing.
2. Five-minute local demo (single docker run).
3. Production Compose recipe with Traefik + Let's Encrypt + persistent volumes + health-check — the exact YAML, validated.
4. .env file template.
5. First-boot, admin password rotation, user provisioning.
6. Upgrade workflow (docker compose pull && up -d, pinned tags).
7. Backup / restore procedure (filesystem-only, no DB).
8. Fork-specific tunables (THUMBNAILS_VIDEO_*).
9. Observability and log notes.
10. Troubleshooting cheatsheet.

Both YAML payloads (the workflow and the embedded Compose snippet) were locally parsed with pyyaml to confirm they're well-formed.

Review & Testing Checklist for Human

This PR is docs + CI only (no Go source touched), so the risk is mainly around the workflow itself. Yellow risk:

• Workflow permissions. Confirm packages: write on GITHUB_TOKEN is acceptable for this repo and that you'd like images to land at ghcr.io/enclave-projects/opencloud. If you'd rather use Docker Hub or a different namespace, change IMAGE_NAME/REGISTRY in .github/workflows/docker.yml and (for Docker Hub) add DOCKERHUB_USERNAME + DOCKERHUB_TOKEN secrets — happy to ship that as a follow-up if you prefer.
• First-push validation. After merge, watch the first main build complete (this PR itself only builds without pushing — that's the verification step). The first push will create the opencloud GHCR package; set its visibility to Public in the GitHub UI so unauthenticated docker pull works.
• DEPLOYMENT.md sanity check. Walk through section 3 ("Production deployment with Docker Compose") on a throwaway VM or VPS — replacing cloud.example.com with a real DNS name you control — and confirm the recipe still boots end-to-end. The container image used in the recipe is the same one this workflow produces, so this is mainly a "do my words match reality" check.

Notes

• The PR does not modify .github/settings.yml (which extends gh-labels) or .github/workflows/labels.yml — those are upstream-mirrored configuration and unrelated to Docker image publishing.
• The new workflow uses concurrency with cancel-in-progress: true only for PR events. Pushes to main are never cancelled, so a fast follow-up commit will queue a new build rather than killing the in-flight one.
• The Compose recipe in DEPLOYMENT.md intentionally uses restart: unless-stopped and a healthcheck: so that docker compose integrates with systemd-monitored hosts; it also chmod 600's the .env file because the IdP admin password can be set there.
• I avoided embedding a hosted compose.yml file in deployments/ (next to the existing bare-metal-simple/ directory) so as not to overlap with upstream's deployment recipes. If you'd like one in-tree, I can add deployments/examples/enclave-projects-compose/ in a follow-up.

Link to Devin session: https://app.devin.ai/sessions/620d4cc7fd8b46a386213618cd65b662