Zammad: the default branch is develop, and there are no GitHub releases to install

The image removes sendmail so mail cannot arrive and vanish

One line of the Dockerfile explains itself: the base packages are installed and then exim4-base, exim4-config and bsd-mailx are removed and purged, with the comment that the sendmail binary is taken out of the image because it could receive emails that go nowhere. Removing the local transport agent is the deliberate way to stop an unattended helpdesk instance from quietly absorbing mail it will never relay. The same block adds the official PostgreSQL apt repository rather than relying on the Debian one, and installs the postgresql-client meta-package so the image carries a pg_dump recent enough to work against current PostgreSQL servers, a point the comment ties to a specific issue number in the tracker. libimlib2 and nginx come in as well, and the purge leaves no apt lists or cached archives behind.

jemalloc is preloaded and the bundle excludes test and development gems

The production environment block sets six variables at once, and two of them describe memory and packaging decisions worth noticing. LD_PRELOAD points at libjemalloc.so.2, so the allocator is loaded ahead of Ruby rather than being left to the Ruby build default, and libjemalloc2 is installed in the base layer to match. BUNDLE_WITHOUT is set to "test development", meaning the shipped bundle carries neither group, and BUNDLE_PATH moves gems to /usr/local/bundle while BUNDLE_DEPLOYMENT pins them. RAILS_ENV is production and RAILS_LOG_TO_STDOUT is true, which is what makes container log collection work. The image builds on ruby:3.4.12-slim-trixie with NODE_VERSION 24 in a separate throw-away stage that installs corepack and pnpm and then deletes the yarn binaries.

Two linters and a formatter are pointed at the same frontend directory

The JavaScript lint step is not one tool but two run in sequence, and both receive the same pair of paths:

"lint:js": "pnpm lint:js:oxlint:cmd app/frontend/ .eslint-plugin-zammad/ && pnpm lint:js:eslint:cmd app/frontend/ .eslint-plugin-zammad/",
"lint:js:oxlint:cmd": "oxlint --tsconfig tsconfig.json",
"lint:js:eslint:cmd": "eslint --cache --cache-location ./tmp/cache/.eslintcache.js --cache-strategy content",

oxlint runs first against the TypeScript configuration, then eslint runs over the same directories with a cache keyed on file content. Alongside them sit vue-tsc for type checking with no emit, stylelint for scss, css and vue, markdownlint for markdown files, oxfmt as the formatter with a separate check mode, and coffeelint.json sitting in the root. The repository root shows the same split in configuration files, holding .oxlintrc.json, .stylelintrc.json, .oxfmtrc.json and .markdownlint.yml side by side. The aggregate lint script chains all of them and then runs the format check, so a change has to satisfy six separate tools before it is considered clean.

Package channels track stable while the repository default is develop

The distribution links are split along branch lines rather than gathered under one version. The DEB and RPM downloads come from a packager service and are offered twice, once for a stable reference and once for a develop reference. The Helm chart lives on its own artifact hub page with releases in a separate zammad-helm repository, and the Docker Compose images sit on Docker Hub under the zammad organization. Meanwhile the default branch of the source repository is develop, not master and not main, so a plain clone lands on the branch that the stable package deliberately does not track. The README points the way back for setup, sending readers to the documentation hub for installing and getting started, to a developer manual inside the tree, and to a REST API introduction page, while noting that the license file itself also sits on develop.

No GitHub releases exist, so the version string in the tree is the source of truth

This repository has no GitHub releases, and the README offers nothing that fills the gap: it describes the software and the company, then lists where to get it. That makes the VERSION file at the repository root, alongside CHANGELOG.md and BREAKING_CHANGES.md, the place a version number can actually be read. The last push to the default branch was on 2026-11-02, and the project is not archived, so the tree is moving even though the release history visible from the repository host is empty. For anyone tracking what they are running, the practical consequence is that the tag a vendor names and the version string in the tree are two different things to verify, and the CHANGELOG.md and BREAKING_CHANGES.md files are the only in-tree record of what changed between them.

Two CI systems and four license files sit in one root directory

The root is unusually crowded for a single project, and the arrangement is informative. Both .github/ and .gitlab/ are present, along with a separate .gitlab-ci.yml at the top level and .github/ holding the workflow badges the README links for the toolchain and the Docker release, so the project is wired into two forges rather than one. Licensing is split three ways: the AGPL LICENSE that the README points at, LICENSE-3RD-PARTY.txt, and LICENSE-ICONS-3RD-PARTY.json, which covers icon assets separately from code. SECURITY arrives twice as well, as a policy document and as a SECURITY.asc key file, alongside CODE_OF_CONDUCT.md and an AGENTS.md. Runtime and development entry points are duplicated on purpose too, with a Procfile for production and separate Procfile.dev and Procfile.dev-https files wired to the dev and dev:https scripts.

The Foundation owns the code while the company does the development

The README splits the software from the business in unusually plain terms. It states that the software is and will stay open source under the GNU AGPLv3, that the source is owned by the Zammad Foundation, and that the foundation is independent of commercial providers such as Zammad GmbH. Development is carried out by the team at Zammad GmbH in collaboration with the community. The same file then makes the commercial case directly, offering to take over setup, configuration, backup and update tasks through a paid cloud service, with a free trial instance linked. So the governance claim and the sales pitch appear in the same document, one after the other, rather than being separated. For an evaluator that matters in a specific way: the copyright holder and the vendor are different entities, while the code doing the work is written by the vendor.

Editorial conclusion

Zammad fits a team that wants a self-hosted helpdesk with the source under the AGPL and a vendor-backed option behind it, and that has a PostgreSQL server to give it. Two decisions deserve checking before you commit. Your package source has to match your branch, since the DEB and RPM are offered for both a stable and a develop reference while the Helm chart and the Docker images sit on their own release cadence, and the repository's default branch is develop rather than a stable line. And the image is built to hold no mail transport of its own, which means outbound mail is something you supply. A team that needs a ticketing system with zero external dependencies is not served here, since the README points to a paid cloud service and a Helm chart rather than to anything self-contained.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. zammad/zammad on GitHub