Reference

Every module, one entry each.

Image, ports, required environment variables, volumes and licence for each container, with the upstream link the entry was checked against.

How to read an entry

One entry per module. Every entry was checked against the project's own documentation on the date shown, not against a blog post or another guide.

Each entry lists the image, the ports, the volumes, and what else the module needs running alongside it. Container ports are given as the container sees them. Host ports are yours to choose, and the Generator assigns unique ones so nothing clashes.

Image
The registry path the project itself publishes
Ports
Container port, and what it serves
Volumes
Paths inside the container that must persist
Needs
Other services, or a variable you cannot leave blank
Checked
When this entry was last verified upstream
Every entry is currently checked. If one is ever marked not checked, that entry will carry no image name, no ports and no variables, and the generator will not write compose for it. An unverified entry states what is unknown rather than guessing at it.

Docker management

Arcane A web UI for Docker itself checked 12 Sep 2026
Image
ghcr.io/getarcaneapp/arcane
Ports
3552, web UI
Volumes
/app/data, plus the Docker socket
Needs
The Docker socket. It cannot work without it
Required vars
ENCRYPTION_KEY, JWT_SECRET, APP_URL
Licence
BSD 3-Clause

Containers, images, volumes, networks and Compose projects, in a browser. The same tool the media server introduces, which is why it is here: if you followed that site, this is already familiar.

The image path moved. Every Arcane repository moved to the getarcaneapp organisation, and releases after 1.7.2 come from ghcr.io/getarcaneapp/arcane. Guides still pointing at ghcr.io/ofkm/arcane are pinned to the old namespace. Contested: some recent guides use ghcr.io/getarcaneapp/manager instead. The organisation README names arcane, which is what the generator writes.
Never publish it. Arcane holds the Docker socket by definition, which is root on the host in practical terms. Anyone who reaches port 3552 can run any container as root. It is excluded from generated proxy configuration unconditionally, unlike Homarr where the socket is optional.

ENCRYPTION_KEY protects the credentials it stores and must be at least 32 characters; the generator writes 64 hex characters for both keys. Change the default login before anything else.

Arcane gets its own install-arcane.sh because it is the one thing here you would sensibly install before the rest of the stack exists. It runs the same platform checks as the main script.

PDF tools

Stirling-PDF Sixty-odd PDF operations, with an API checked 8 Sep 2026
Image
docker.stirlingpdf.com/stirlingtools/stirling-pdf
Ports
8080, web UI and API
Volumes
Optional, for custom config and OCR language data
Needs
Nothing. Single container
Licence
MIT, open core

The only PDF tool here with a proper API, so it is the one that fits into scripts and automation. Merge, split, OCR, convert, sign, redact, compress.

Read the licensing before you build a team around it. The project moved to an open-core model. Directories inside the repo are licensed separately from the MIT core. A maintainer stated in 2025 that there is currently no user limit and the pricing page claiming five users was wrong, but also that the plan is eventually to restrict the account system to five users. Single sign-on sits in the paid Server tier. If you need Stirling behind a login without paying, put a forward-auth gateway in front of it.

Contested: one software directory lists the licence as Apache-2.0. The repository's own LICENSE file says MIT with carve-out directories. Trust the repository.

BentoPDF The same kind of tools, entirely in your browser checked 8 Sep 2026
Image
ghcr.io/alam00000/bentopdf-simple
Ports
8080, static web server
Volumes
None. Nothing is stored server-side
Needs
Nothing
Licence
AGPL-3.0, or a commercial licence

Every operation runs in the browser. Files never reach the server, which is the whole point. That also means it can be served as plain static files from any web server, and the container is only a convenience.

Use the simple build. Upstream describes it as the full toolset with the marketing page removed, intended for internal deployments, and explicitly not a feature-reduced version.

What you give up. No API, no scripting, no automation, and file size is bounded by the browser's memory rather than the server's. For a large batch job, use Stirling-PDF.
PdfDing A reading library for PDFs, not a toolkit checked 8 Sep 2026
Image
mrmn/pdfding
Ports
8000, web UI
Volumes
Media directory for the PDFs, plus the database
Needs
SQLite by default, PostgreSQL optional
Licence
GPL-3.0

Tags, collections, annotations, share links, and it remembers where you stopped reading on each device. OIDC single sign-on is included rather than paid for. There is a consume directory for adding files without the UI.

The GitHub repository is archived. Development moved to Codeberg, at codeberg.org/mrmn/PdfDing. Any guide pointing you at GitHub is pointing at a repository that has stopped moving.

Document archives

Paperless-ngx Scan, OCR, tag, search. The default choice checked 8 Sep 2026
Image
ghcr.io/paperless-ngx/paperless-ngx
Ports
8000, web UI and API
Volumes
/usr/src/paperless/data, /media, /export and /consume
Needs
Redis and PostgreSQL. Gotenberg and Tika if you want office files
Required vars
PAPERLESS_SECRET_KEY, PAPERLESS_URL, plus the database and Redis connection

Drop a file in the consume directory and it is OCR'd, classified and indexed. It learns tags and correspondents from your corrections. Everything the UI does is available over the API.

Plan the consume directory first. Put it on a share your scanner can already write to. That single decision decides whether you actually use this.

Four volumes, and they are not interchangeable. media holds the documents themselves, data holds the search index and classifier. Back up both. export is where a proper document export lands, which is the migration path off Paperless if you ever want one.

Docspell Structured metadata and rules, at the cost of four services checked 8 Sep 2026
Images
Separate restserver and joex images, published by the project
Ports
7880, web UI and API
Volumes
Document storage plus the database and search index
Needs
PostgreSQL and Solr, plus a separate joex worker container
Licence
GPL-3.0

Stronger than Paperless on structured metadata: document types, folders, permissions, and a rule-driven workflow layer with a documented API.

Count the containers. Docspell is restserver plus joex plus PostgreSQL plus Solr. That is four services before you scan anything, and Solr in particular wants memory. On a small box, run Paperless-ngx instead.

Release cadence is slow but the project is not abandoned. The last tagged release was v0.43.0 in March 2025, while pull requests were still being merged in August 2026 and nightly builds continue. Judge it as slow rather than dead.

Notes, wikis and libraries

BookStack Structured wiki: shelves, books, chapters, pages checked 8 Sep 2026
Image
lscr.io/linuxserver/bookstack
Ports
80, web UI
Volumes
/config
Needs
MySQL or MariaDB
Required vars
APP_URL, APP_KEY, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD

The recommendation for most people who want a team wiki. The fixed hierarchy is the feature: non-technical writers put things in the right place without being told to. Ships on a calendar release schedule with regular security releases.

APP_KEY is not optional and not free-form. Generate it with the image itself: docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkey. It has the form base64: followed by 32 base64-encoded bytes. A random string in that field will not work.

The default login is admin@admin.com with the password password. Change it before anything else. If you are running behind a reverse proxy, APP_URL must be the external URL or links and redirects break.

Wiki.js Free-form page tree, Git-backed storage checked 8 Sep 2026
Image
ghcr.io/requarks/wiki:2
Ports
3000, web UI
Volumes
None required. Content lives in the database
Needs
PostgreSQL, recommended over the other supported engines
Required vars
DB_TYPE, DB_HOST, DB_PORT, DB_USER, DB_PASS, DB_NAME

More flexible than BookStack: several editor types over one page tree, optional Git synchronisation of content, and richer search backends.

Pin the major tag. The project's own documentation recommends against latest and tells you to use the major version you need. Version 3 has been in alpha since October 2022 with no announced release date, and its documentation says plainly that it is an unstable beta which should not be installed in production. Run ghcr.io/requarks/wiki:2.

Version 2.5.314 shipped in May 2026 and security fixes continue, but new feature work is going into version 3. If a predictable release schedule matters to you, that is the argument for BookStack.

Obsidian The desktop app, streamed to a browser checked 8 Sep 2026
Image
lscr.io/linuxserver/obsidian
Ports
3001 HTTPS, self-signed. 3000 HTTP, for use behind a proxy only
Volumes
/config, and a mount for your vault
Needs
Nothing, but see the warning

This is not a web application. It is the real Obsidian desktop app running in a container and streamed to your browser through Selkies, which replaced KasmVNC in these images. Plugins work because it is the actual app.

Never publish this. LinuxServer's own documentation states that the container provides privileged access to the host system, that the web interface includes a terminal with passwordless sudo, and that anyone who can reach the GUI can gain root inside the container. It tells you to treat a session like an SSH login to a machine on your network. There is no authentication by default. Setting CUSTOM_USER and PASSWORD gives you HTTP basic auth, which upstream describes as adequate for a trusted LAN and nothing more. Reach it over your VPN.

HTTPS is required for the video and audio features to work at all, because the browser APIs involved only run in a secure context. That is why port 3001 serves its own certificate. A reverse proxy that validates upstream certificates will reject it, which is what port 3000 exists for.

Kiwix Wikipedia and other whole sites, offline checked 8 Sep 2026
Image
ghcr.io/kiwix/kiwix-serve
Ports
8080, web UI
Volumes
/data, holding your ZIM files
Needs
Nothing. The ZIM files are the whole dependency
Command
The ZIM files to serve, or the glob '*.zim'

Serves ZIM archives with full-text search. A full English Wikipedia with images is tens of gigabytes; the no-pictures build is far smaller. Stack Exchange sites, Project Gutenberg and WikiHow are also available.

The command argument is not optional if you are serving local files. Without it the container has nothing to serve. Quote the glob in compose, or YAML will not pass it through as you expect.

Image name to watch. Some directories list this as ghcr.io/kiwix/kiwix-tools, which is the bundle of command-line tools rather than the server image. Upstream's own Docker readme uses ghcr.io/kiwix/kiwix-serve.

Code forges

Forgejo Full forge with CI, registry and issues checked 8 Sep 2026
Image
codeberg.org/forgejo/forgejo:16
Ports
3000 web UI, 22 SSH
Volumes
/data
Needs
SQLite by default. PostgreSQL or MySQL for anything real
Required vars
USER_UID and USER_GID, matching the owner of your data directory

The recommendation of the two forges here. Forgejo Actions gives you CI compatible with GitHub Actions workflows, there is a package registry, and it can act as an OAuth2 provider for other services in your stack, which is worth knowing if you want single sign-on without running a separate identity server.

Governance is community-led under Codeberg e.V. Federation over ActivityPub exists but is experimental and off by default.

If Codeberg is unreachable, upstream publishes a mirror: replace codeberg.org with data.forgejo.org in the image name.

Map SSH to a spare host port such as 222 rather than 22, unless you have moved your host's own SSH daemon. Both cannot have port 22.

Gogs The smallest thing that is still a forge checked 8 Sep 2026
Image
gogs/gogs
Ports
3000 web UI, 22 SSH
Volumes
/data
Needs
SQLite by default, PostgreSQL or MySQL optional
Required vars
None. Configuration happens in a web installer on first run

Repositories, issues, pull requests, a wiki, webhooks, SSH and HTTP. That is the whole scope, and it has stayed that way deliberately. It will run on hardware where Forgejo would be uncomfortable.

What it does not have: built-in CI, a package registry, project boards, or an OAuth2 provider. If you want any of those, you want Forgejo.

The SSH port is set during the web installer. Whatever host port you published for 22 has to be entered there, or clone URLs will be generated with the wrong port and SSH pushes will fail with a confusing error.

File transfer

PairDrop AirDrop for everything, over your own network checked 8 Sep 2026
Image
lscr.io/linuxserver/pairdrop
Ports
3000, web UI and signalling
Volumes
None, unless you supply a custom STUN and TURN config
Needs
Nothing. A coturn server if you want it working across networks
Optional vars
WS_FALLBACK, RATE_LIMIT, RTC_CONFIG, DEBUG_MODE

Open the page on two devices on the same network and they find each other. Files go directly between browsers over WebRTC; the server only introduces them. Nothing is stored, so there is nothing to clean up.

If you reach this over a VPN, read this. Most VPN services block WebRTC entirely in order to hide your real address, so peer discovery fails. Setting WS_FALLBACK to true fixes it, but upstream is clear about the cost: fallback traffic is routed through the server, is readable by the server, and uses the server's bandwidth. It is no longer peer to peer.

Leave DEBUG_MODE off. Upstream says not to use it in production, because it logs client IP addresses to standard output.

One naming trap. A site at pairdrop.org advertises a self-contained PHP script with no database. That is different software with the same name. The project this image wraps is the Node and WebRTC one, forked from Snapdrop.

PsiTransfer Send someone a link. No accounts checked 8 Sep 2026
Image
psitrax/psitransfer, also ghcr.io/psi-4ward/psitransfer
Ports
3000, web UI
Volumes
/data
Needs
Nothing
Optional vars
PSITRANSFER_ADMIN_PASS, PSITRANSFER_UPLOAD_PASS, PSITRANSFER_UPLOAD_DIR

The closest thing here to WeTransfer. Upload a bucket of files, set an expiry, get a link. Resumable uploads and downloads, one-time downloads, password-protected download lists, and everything can be pulled as a zip.

Chown the data directory before first start. Upstream is explicit: the data volume needs UID 1000. Run chown -R 1000 ./data or the container fails with permission errors that do not name the cause.

Two different passwords, easy to confuse. PSITRANSFER_ADMIN_PASS enables the /admin page, which is disabled entirely until you set it. PSITRANSFER_UPLOAD_PASS is what stops strangers uploading if the instance is reachable from outside.

Zipline Screenshot and upload server, ShareX compatible checked 8 Sep 2026
Image
ghcr.io/diced/zipline
Ports
3000, web UI and API
Volumes
/zipline/uploads, /zipline/public, /zipline/themes
Needs
PostgreSQL
Required vars
DATABASE_URL and CORE_SECRET. Everything else has a default

Built for ShareX, Flameshot and similar tools. Dashboard, API, URL shortener, paste bin, and embed metadata for links pasted into chat apps.

CORE_SECRET must be longer than 32 characters. Upstream rejects anything shorter. If you are generating it with a password manager, quote it in the compose file so special characters survive.

Version 4 was a complete rewrite and there is no in-place upgrade from version 3. Data moves across using a built-in importer. Several variables were renamed at the same time: CORE_DATABASE_URL became DATABASE_URL, and CORE_HOST became CORE_HOSTNAME. Old compose files fail in confusing ways because of this.

Chibisafe A gallery you upload to, with albums and tags checked 8 Sep 2026
Image
chibisafe/chibisafe, plus chibisafe/chibisafe-server in the split layout
Ports
8000 in the single-container layout, 24424 through Caddy in the split layout
Volumes
database, uploads and logs directories
Needs
Depends on layout. See below
Licence
MIT

More file hosting than file transfer. Albums, tagging, thumbnails, shareable galleries, multi-user with permissions, and ShareX support.

Upstream documents two different layouts and they disagree. The repository's compose example runs three services, a frontend, a server, and a Caddy instance that merges them onto port 24424, and requires you to create a Caddyfile by hand. The Docker Hub readme shows a single container publishing 24424 to container port 8000. The volume paths differ too: /app/database and friends in one, /home/node/chibisafe/database in the other. Pick one source and follow it all the way through rather than mixing them.

Some third-party comparisons state that Chibisafe requires PostgreSQL. Upstream's own compose files use a local database directory instead. Where a guide and the project disagree, the project wins.

Create the database, uploads and logs directories before first start. Letting Docker create them produces permission errors.

Workspaces and boards

CryptPad Encrypted collaborative documents checked 8 Sep 2026
Image
cryptpad/cryptpad
Ports
3000 and 3003
Volumes
blob, block, customize, data and datastore, under /cryptpad
Needs
A reverse proxy, and two distinct domains
Required vars
CPAD_MAIN_DOMAIN and CPAD_SANDBOX_DOMAIN

Documents, spreadsheets, kanban and more, encrypted in the browser so the server cannot read them. That property is also its main constraint: the server cannot help you if you lose a key.

Two domains, not one. CryptPad needs a main origin and a separate sandbox origin with restrictive content-security-policy headers applied. Its documentation states that using CryptPad in production without the sandboxing system may put users' information at risk. The two values must be genuinely different origins. A single-hostname install is not a working install.

The optional OnlyOffice integration is enabled by an environment variable that the shipped compose file leaves commented out, with a note telling you to read and accept its licence first. That comment is there deliberately.

Calligra An office suite, streamed to a browser checked 8 Sep 2026
Image
lscr.io/linuxserver/calligra
Ports
3001 HTTPS, self-signed. 3000 HTTP, behind a proxy only
Volumes
/config, and a mount for your documents
Needs
Nothing, but see the warning

The same Selkies base image as Obsidian, running KDE's office suite. Words, Sheets, Stage and the rest, in a browser tab. Useful when you need to open a document format nothing else handles and you do not want to install anything locally.

Same exposure as Obsidian, for the same reason. Privileged access to the host, a terminal with passwordless sudo in the web interface, and no authentication by default. Do not publish it. It is on the never-expose list on the Access page.

HTTPS is required for full functionality, because the browser features it depends on do not work over plain HTTP.

AppFlowy A Notion-shaped workspace with its own cloud backend checked 8 Sep 2026
Deploy
From the AppFlowy-Cloud repository, not a single service
Ports
80 and 443, through its own bundled nginx
Needs
PostgreSQL, Redis, MinIO and GoTrue, all part of its stack
Hardware
4GB RAM minimum, 8GB recommended, and a real domain

Documents, databases, kanban boards and calendars, with polished desktop and mobile clients that you point at your own server. AppFlowy Cloud is the server component; the apps are where you actually work.

This is not a module you can drop into a compose file. It is a multi-service stack deployed from its own repository with its own deployment configuration. The Generator treats it as an upstream install: it will write you proxy configuration and notes, not an invented compose service.

A domain name is required rather than recommended, because the clients connect to a base URL and a websocket URL that have to resolve.

Huly Projects, issues, documents, calls, in one platform checked 8 Sep 2026
Deploy
From the huly-selfhost repository, with its own setup script and nginx config
Ports
8087 in the local quick-start
Needs
Many services: account, front, transactor, database, queues and more
Hardware
Minimum 2 vCPUs and 8GB RAM. Recommended 4 vCPUs and 16GB

The largest thing on this site by some distance. Project management, issue tracking, documents, HR, and optional video calls through LiveKit.

Take the RAM figure literally. Upstream warns that servers below the minimum may stop responding or fail. Eight gigabytes is the floor, not a comfortable target. On a NAS with soldered 4GB, this is not going to work.

Upgrades need attention. Moving from any 0.6.x version to 0.7.x requires the dedicated migration steps in the project's migration guide rather than a direct in-place upgrade. The quick-start compose is described by upstream as intended for local testing only.

Wekan Kanban boards, with Trello import and export checked 8 Sep 2026
Image
ghcr.io/wekan/wekan, also quay.io/wekan/wekan
Ports
8080, web UI
Volumes
/data, set by WRITABLE_PATH
Needs
MongoDB
Required vars
MONGO_URL, ROOT_URL, WRITABLE_PATH

Boards, swimlanes, checklists, due dates and attachments, close enough to Trello that the import works. Boards export as JSON with attachments included, which is a real exit route rather than a claimed one. WITH_API turns on the REST API, off by default.

ROOT_URL is not cosmetic. It is the address Wekan believes it lives at. Get it wrong and logins and invite links break in ways that look like authentication bugs. Set it to the external URL you actually use, including the scheme.

Contested: the required MongoDB version. Community guides variously insist on 4.4.x, while others run MongoDB 6 or 7 without trouble, and upstream examples span everything from 3.2 to 4.4 depending on their age. Check the project wiki for the version matching the Wekan release you are pulling rather than copying a version number out of a blog post.

Meetings and signing

Jitsi Meet Video calls, four containers checked 8 Sep 2026
Images
jitsi/web, jitsi/prosody, jitsi/jicofo, jitsi/jvb
Ports
8443 HTTPS and 8000 HTTP by default, plus 10000/udp and 4443/tcp for media
Volumes
A config tree you create by hand before first start
Needs
A real domain, and UDP reaching the videobridge
Required vars
PUBLIC_URL, plus the passwords generated by the project's script

Four services: the web UI, an XMPP server, a conference focus component, and the videobridge that actually moves the media. Optional add-ons for SIP and recording are separate compose files layered on top.

Do not clone the repository. Upstream says explicitly to download and extract the latest release instead. Then copy env.example to .env and run the project's own gen-passwords.sh, which generates every required secret with openssl and rewrites .env in place. Do not invent these passwords yourself; the components have to agree on them.

You also have to create the config directories before the first start, or the containers have nowhere to write. Upstream gives the exact mkdir line, covering web, transcripts, prosody config and plugins, jicofo, jvb, jigasi and jibri.

Plain HTTP will appear to work and then fail. Port 8000 exists for reverse-proxy setups only. Reaching Jitsi directly over HTTP produces camera and microphone errors, because the browser APIs it needs are only available in a secure context. Also set PUBLIC_URL to the real domain for any deployment that is not a local test.

The firewall rules differ from everything else on this site. Media needs 10000/udp open, and 4443/tcp for the case where UDP is blocked at the client's end. A reverse proxy alone does not carry that traffic.

OpenSign Document signing workflows checked 8 Sep 2026
Images
opensign/opensignserver and opensign/opensign, plus MongoDB and Caddy
Ports
3000 client, 8080 server, 3001 through the bundled Caddy
Volumes
/usr/src/app/files for documents, plus the MongoDB data volume
Needs
MongoDB, an SMTP server, and a signing certificate
Required vars
PUBLIC_URL, SERVER_URL, MONGODB_URI, MASTER_KEY, PARSE_MOUNT, SMTP settings, PFX_BASE64

Send a document, place fields, collect signatures, keep an audit trail. Deployed from upstream's own compose file and Caddyfile rather than a service you write yourself, with configuration in a .env.prod file.

Configure SMTP before you invite anyone. Email is not optional here. Without a working mail adapter, account verification and password resets fail with an error that does not explain itself, and a signing request nobody can be notified about is not a signing workflow.

MASTER_KEY is described by upstream as the key that allows access to all the data. Treat it as the most sensitive value in your whole stack, keep it out of version control, and do not reuse it anywhere. PARSE_MOUNT should be left at /app; upstream says not to change it.

PFX_BASE64 holds the signing certificate. Upstream's example file ships a sample certificate, which is fine for trying it out and wrong for anything you would actually rely on.

Dashboards

Homarr Drag and drop dashboard with live integrations checked 8 Sep 2026
Image
ghcr.io/homarr-labs/homarr
Ports
7575, web UI
Volumes
/appdata. Optionally the Docker socket
Needs
Nothing. It bundles its own database
Required vars
SECRET_ENCRYPTION_KEY, a 64-character hex string

You build the board in the browser rather than in a file. Tiles pull live data from services you point them at, and it ships its own user accounts and login, so it does not need an auth layer bolted on.

Keep the encryption key. It encrypts every stored integration credential. Generate it with openssl rand -hex 32, store it outside version control, and do not rotate it casually: change it and every saved credential becomes undecryptable, so you re-enter all of them.

The Docker socket mount is what gives you container status, and it is optional. Mount it read only if you mount it at all, and understand that read only limits the damage rather than removing it. The socket is root on the host in practical terms.

The version 1 rewrite changed the architecture and required manual reconfiguration for people upgrading from earlier versions.

Dashy Dashboard as a config file, with a UI editor checked 8 Sep 2026
Image
lissy93/dashy, also ghcr.io/lissy93/dashy
Ports
8080, web UI
Volumes
/app/user-data, holding conf.yml and any icons or themes
Needs
Nothing
Licence
MIT

Your whole dashboard is one YAML file, which means it lives in Git next to your compose file and is restored by copying a file. There is a UI editor too, so you are not forced into a text editor. Status checks per tile, and a large theme collection.

Two breaking changes to know about. Version 3 moved the config from /app/public/conf.yml to /app/user-data/conf.yml and changed the container port from 80 to 8080 so the image could run as non-root. Version 4 removed the build-and-start entrypoint; compose files that override the command crash on start until changed to node server.js. Older guides still show all three of the old values.

Actively released through 2026, on the 4.5.x line as of August.