binsky/passman-dev repository overview

⁠Passman Docker images (dev & demo)

This repository builds and publishes Docker images for the Passman⁠ Nextcloud app. Each image is a ready-to-run Nextcloud stack (Apache, MariaDB, PHP) with Passman pre-installed and configured (with the latest Passman version during image build time).

Two image families serve different goals:

Default login (all images): user admin, password admin.

Rolling tag (only for dev images): binsky/passman-dev:latest tracks the newest supported dev stack (currently Nextcloud 33 / PHP 8.4 — see ci/registry.json).

Source: github.com/binsky08/passman-dev-docker-build⁠

⁠Development vs demo images

⁠Development (binsky/passman-dev)

Use these when you work on Passman itself:

• Passman source is cloned at build time; you typically bind-mount your local repo to /var/www/html/apps/passman.
• Node/npm + grunt are available (on newer stacks) so you can build frontend assets inside the container.
• SSH is enabled so you can ssh in or mount the whole Nextcloud tree with sshfs (IDE autocompletion).
• Several Nextcloud + PHP stacks are available; older recipes live in archived/ (see Published image tags⁠).

Older directories use a single-stage Dockerfile (one image = dev). Newer stacks (e.g. nc33_php8.4) use a multi-stage Dockerfile: stage demo is the runtime base; stage dev adds npm/grunt on top.

⁠Demo (binsky/passman-demo)

Use these for hosted demos or any setup where you only need a running instance:

• Same Nextcloud + Passman + DB baked in at build time (no bind-mount workflow).
• No dev extras (no grunt toolchain on top of the demo stage).
• Built from the demo stage of multi-stage Dockerfiles. Contexts without a demo stage do not publish a demo image.

Demo images (as well as dev images) can honor DEMO_EXTERNAL_FQDN at runtime (see entrypoint.sh) to automatically add an extra trusted domain.

⁠Published image tags

Tags match the directory name: nc<nextcloud>_php<version> (e.g. nc33_php8.4). On Docker Hub, public tags are multi-arch (linux/amd64 + linux/arm64); see CI⁠.

⁠Built by CI today

Only top-level directories with a Dockerfile are built (not archived/):

Rolling dev tag: binsky/passman-dev:latest → same as nc33_php8.4 (set in ci/registry.json → dev_latest_context).

⁠Older stacks

Dockerfiles for Nextcloud 20–31 (various PHP versions) live under archived/ for reference and manual rebuilds. They are not part of the CI matrix unless moved back to the repository root. Many corresponding tags may still exist on Docker Hub⁠ from earlier releases.

⁠Repository layout

passman-dev-docker-build/
├── entrypoint.sh
├── nc33_php8.4/              # active: multi-stage (demo + dev)
├── nc32_php8.4/              # active: single-stage (dev)
├── archived/                 # legacy Dockerfiles (not built by CI)
├── ci/
│   ├── registry.json
│   └── generate_matrix.py
└── .github/workflows/build-push.yml

Add a new variant: create a top-level ncXX_phpY.Z/ with a Dockerfile (and optional build.sh for local use). CI picks it up automatically. Set dev_latest_context in ci/registry.json if it should own passman-dev:latest.

⁠Quick start (development)

Create TLS files once (self-signed is fine for localhost):

mkdir -p ~/passman-dev-docker && cd ~/passman-dev-docker
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem

Run the latest dev image (or pick a specific tag from the table above). Optionally add
-v /path/to/passman:/var/www/html/apps/passman to use your local Passman clone.

docker run -d -p 8080:80 -p 8443:443 \
  -v ~/passman-dev-docker/certificate.pem:/etc/ssl/private/cert.pem \
  -v ~/passman-dev-docker/key.pem:/etc/ssl/private/privkey.pem \
  -v ~/passman-dev-docker/certificate.pem:/etc/ssl/private/fullchain.pem \
  --name passman-dev \
  binsky/passman-dev:latest

docker logs -f passman-dev
docker exec -it passman-dev bash

Open https://localhost:8443⁠ (HTTP also on port 8080).

Inside the container, Passman lives at /var/www/html/apps/passman/ — run grunt / grunt build there on stacks that include the dev tooling.

⁠Mount Nextcloud via SSH (optional)

For full-tree IDE support:

1. Add your SSH public key to /root/.ssh/authorized_keys in the container.
2. Get the container IP: docker exec passman-dev ip -4 addr show.
3. On the host:

mkdir -p ~/passman-dev-docker/passman-nc-complete
sshfs root@<container-ip>:/var/www/html ~/passman-dev-docker/passman-nc-complete \
  -o idmap=user -o uid=1000 -o gid=1000

# unmount:
fusermount -u ~/passman-dev-docker/passman-nc-complete

⁠CI (GitHub Actions → Docker Hub)

Workflow file: .github/workflows/build-push.yml⁠

⁠When it runs

⁠What gets built

• Matrix is generated by ci/generate_matrix.py⁠ from every top-level directory that contains a Dockerfile.
• Incremental builds: only contexts with file changes under their directory are rebuilt.
• Full rebuild if entrypoint.sh, anything under ci/, or .github/ changes.
• Per context:
  • passman-dev — always (final stage, or dev stage when multi-stage).
  • passman-demo — only if the Dockerfile has FROM … AS demo.
• Tags and Hub repo names come from ci/registry.json⁠ (dev_latest_context → passman-dev:latest).

⁠Multi-architecture (no QEMU)

On push, three job types run:

1. build-amd64 — ubuntu-latest, linux/amd64, pushes …:<tag>-amd64
2. build-arm64 — ubuntu-24.04-arm, linux/arm64, pushes …:<tag>-arm64
3. merge-manifests — docker buildx imagetools create so public tags (nc33_php8.4, latest, …) are manifest lists for amd64 + arm64

docker pull binsky/passman-dev:latest then works on both Intel/AMD and ARM64 Macs/servers.

Private repositories: GitHub’s free ubuntu-24.04-arm runners may be unavailable; point build-arm64 at a self-hosted ARM runner label in the workflow.

⁠Secrets (repository settings)

⁠Local builds

Each context may ship a build.sh that copies entrypoint.sh and runs docker build (see nc33_php8.4/build.sh for dev + demo targets). CI does not use build.sh; it invokes Buildx directly with the same contexts.