This is my collection of Docker images, but this repository is intended for my personal projects. You are welcome to use these if you want, but there is no guarantee that I will fix them if you run into any problems.
  • Go 42.9%
  • JavaScript 33.2%
  • CSS 12.4%
  • Python 5.1%
  • HTML 2.8%
  • Other 3.6%
Find a file
X27 6f35887243 Handellist workflow: link the package to Docker-Images
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 21:52:12 +02:00
.forgejo/workflows Handellist workflow: link the package to Docker-Images 2026-10-08 21:52:12 +02:00
Dev-Box Use the Forgejo package registry for images 2026-10-06 21:43:11 +02:00
handellist Handellist: keep the source in Docker-Images instead of a separate repo 2026-10-08 21:48:13 +02:00
unbound Use the Forgejo package registry for images 2026-10-06 21:43:11 +02:00
X-Dashboard Use the Forgejo package registry for images 2026-10-06 21:43:11 +02:00
X27-Hub Use the Forgejo package registry for images 2026-10-06 21:43:11 +02:00
.gitignore Handellist: keep the source in Docker-Images instead of a separate repo 2026-10-08 21:48:13 +02:00
README.md Handellist: keep the source in Docker-Images instead of a separate repo 2026-10-08 21:48:13 +02:00

Docker-Images

Source code and Dockerfiles for the container images X27 builds and publishes to git.xlabsx27.com/x27/ (the Forgejo package registry). Each top-level folder is one image: its Dockerfile, build context, and a compose.yml for running the published image.

Images are built by Forgejo Actions (.forgejo/workflows), one workflow per image. Each one runs weekly (Dev-Box on Sunday, unbound on Monday, X-Dashboard on Tuesday, X27-Hub on Wednesday, Handellist on Thursday, all UTC), and you can also start it by hand from the repository's Actions tab. Pushing to main does not trigger a build. Each run pushes the tags latest, main, sha-<commit> and a date version YYYY.MM.DD. A second build on the same day gets YYYY.MM.DD.2, then .3, and so on.

After a successful push, the workflow creates a release named <Image> <version> and tagged <image>-<version> (e.g. x27-hub-2026.10.07) on the commit it built. X27-Hub also builds that version into its binary.

Runner and secret setup

  • Runner: a Forgejo runner with the docker label. Jobs run in ghcr.io/catthehacker/ubuntu:act-24.04 and build with buildx, so they need a Docker daemon. The workflows support two runner setups:

    • Docker-in-Docker (the current runner): a docker:dind container serves its daemon on tcp://…:2375 without TLS, and the runner runs its jobs there. No runner config is needed. The Find Docker daemon step points DOCKER_HOST at the job container's gateway, which is the DinD container. The DinD container must be privileged, so QEMU can register the arm64 emulator for the multi-arch images (unbound, X-Dashboard, Handellist).
    • Host Docker socket: set container.docker_host: automount in the runner config so the socket is mounted into job containers.

    The runner's data/ folder must be owned by the user the runner runs as (e.g. chown -R 1001:1001 data when user: 1001:1001). Otherwise jobs fail with "Permission denied" when the runner caches actions.

  • Secret: PUBLISH_TOKEN, a Forgejo access token for X27 with the write:package scope (to push images) and the write:repository scope (to create releases). Add it under repository Settings → Actions → Secrets.

Compose files for images pulled from other maintainers live in Docker-X27-Composes.

Images

  • Dev-Box — git.xlabsx27.com/x27/dev-box
  • Handellist — git.xlabsx27.com/x27/handellist
  • unbound — git.xlabsx27.com/x27/unbound
  • X-Dashboard — git.xlabsx27.com/x27/x-dashboard
  • X27-Hub — git.xlabsx27.com/x27/x27-hub