v17.0.0

Changes

🚀 Features

• Enhancement: Run Zammad with a non-superuser PostgreSQL role (#611) @fliebe92
  • Zammad now connects to PostgreSQL with an unprivileged login role that owns nothing but its own database. Previously the stack used the postgres image's bootstrap role, which is always a database superuser. This matches the role that the packaged Linux installation creates.
  • The bundled PostgreSQL service now has a separate postgres superuser for administrative tasks, configurable via the new POSTGRES_SUPERUSER and POSTGRES_SUPERUSER_PASS variables. Its password follows POSTGRES_PASS unless you set it explicitly. POSTGRES_USER, POSTGRES_PASS and POSTGRES_DB keep their meaning and still describe the role and database Zammad uses.
  • Existing installations are not affected and need no action. They keep the role layout their database volume was created with, since the role is only provisioned while an empty volume is initialised.
  • Breaking Change: The stack now requires Docker Compose 2.23.1 or newer (November 2023), because the PostgreSQL initialization script is inlined with configs.content, which was introduced in that version. Older versions fail with a parse error. Distribution-packaged Compose plugins in particular are often older than this.
  • Breaking Change: The default of POSTGRESQL_DB_CREATE changed from true to false, because the stack's PostgreSQL service now creates the database itself and the Zammad role is deliberately not allowed to create databases. If you run Zammad against an external PostgreSQL server and rely on Zammad creating the database for you, set POSTGRESQL_DB_CREATE=true in your .env and make sure the configured role has the CREATEDB attribute.
  • If you maintain your own copy of docker-compose.yml, the changes to the zammad-postgresql service, the new top-level configs: section and POSTGRESQL_DB_CREATE need to be transferred to it.
  • Docker Swarm is now documented as unsupported, and the README points to the Zammad Helm chart for orchestrated deployments. This is not a regression: docker stack deploy already rejected this stack before, because it does not support the depends_on conditions the services rely on.
  • Existing installations that want the hardened role can migrate with a backup and restore into a fresh database volume. PostgreSQL does not allow the bootstrap role to be demoted, so there is no in-place path. The steps are documented in the README. This is optional: an over-privileged role is not exploitable on its own, since reaching those privileges requires valid database credentials and network access to the database in the first place.

Full Changelog: v16.2.1...v17.0.0