zabbix/zabbix-docker: official images and a Makefile-driven Compose stack

What the zabbix-docker repository actually is

This repository is not a monitoring tool. It is the set of Dockerfiles and Compose files that produce the zabbix/* images published to Docker Hub, and it exists so that the images you pull are the ones the vendor builds rather than something a third party assembled. The README describes Zabbix itself as an enterprise-class open source distributed monitoring solution, and then lists the component images: zabbix-agent, zabbix-agent2, zabbix-server-mysql, zabbix-server-pgsql, four web interface variants split across Apache and Nginx and MySQL and PostgreSQL, three proxy images, zabbix-java-gateway, zabbix-web-service and zabbix-snmptraps. If you are deploying Zabbix in containers and you care about provenance, this is the source of truth. If you only want to run Zabbix, the images matter more than the Dockerfiles, and the Docker Hub pages linked from the README carry the per-component usage instructions. The repository also carries kubernetes.yaml, templates/ and sources/ at the top level, so the container story is not limited to Compose, though the README only walks through the Compose path.

How the compose files and Makefile fit together

The Compose setup is split across several files rather than being one monolithic definition. compose.yaml targets MySQL or MariaDB, compose_pgsql.yaml targets PostgreSQL, and both pull service definitions from compose_zabbix_components.yaml through the extends key. compose_databases.yaml and compose_additional_components.yaml hold the rest. Each service in compose.yaml pins its image with a variable plus a shared tag, for example "${ZABBIX_SERVER_MYSQL_IMAGE}:${ZBX_IMAGE_TAG}", and attaches a label com.zabbix.os set from the OS variable. Startup order is expressed with depends_on conditions: the database must be service_healthy before the server starts, and the server-db-init service must reach service_completed_successfully before zabbix-server and the web containers come up. That init service is what applies the schema, so the ordering is not cosmetic. The Makefile on top of this exposes OS, DB, ZBX_VERSION and the port variables as overridable knobs, defaults to alpine and mysql and version 7.4, and picks a base image per OS: alpine:3.24, quay.io/centos/centos:stream10-minimal, container-registry.oracle.com/os/oraclelinux:10-slim, ubuntu:resolute, or registry.access.redhat.com/ubi10/ubi-minimal:10.2. It also defaults the remote image prefix to zabbix/ with the tag $(OS)-$(ZBX_VERSION)-latest.

Installing Zabbix with docker compose and make up

The README states that the Compose files require make and docker compose version 2.24.0 or greater. Clone the repository and run make help from the root directory to see the available targets and variables before starting anything.

make help

The default target is up, so the shortest path to a running stack is a single command. By default this uses Alpine-based images, MySQL, and the latest version from the current branch.

make up

To change the database engine, base OS and published ports, pass variables on the command line. The README gives this exact example, which selects PostgreSQL, Alpine, and exposes the web interface on ports 8282 and 8443.

make up DB=pgsql OS=alpine ZABBIX_WEB_NGINX_HTTP_PORT=8282 ZABBIX_WEB_NGINX_HTTPS_PORT=8443

Tear the stack down with the matching database variable, since the down target needs to know which Compose file was in play.

make down DB=pgsql

One detail worth knowing before you start: the default set of services is deliberately minimal. The README says additional components such as the Zabbix Agent only come up when you select the full or all Compose profile, and that you can also start only the components you need. The Makefile exposes COMPOSE_PROFILES for this. If make or docker compose are missing, the Makefile keeps help and print-vars usable and lets the real targets fail with an ordinary "docker: command not found" style error, which is a reasonable design but means a missing dependency shows up as a failed start rather than a clear preflight message. The README does not document a rollback procedure for a failed or partial deployment.

Where zabbix-docker stops being the right tool

The README is explicit that issues and feature requests filed here should relate to Docker images only, and that anything about improving Zabbix itself belongs in the official bug tracker. That boundary matters when you are debugging: a wrong metric collected by the server is not a container problem, and filing it here will not get it fixed. A second limit is the Windows story. The repository runs a separate GitHub Actions workflow for Windows image builds, but the README's image list and usage section describe the Linux-oriented component images, and the Compose path assumes a Linux container runtime. The Makefile can fall back to Podman when Docker is absent, which is a useful escape hatch, but the README does not present Podman as a tested configuration. The third limit is operational. The compose files express startup ordering carefully, yet nothing in the README covers backup, restore, or version rollback of the database behind the server. If you are running this in production, that gap is yours to close, and it is the kind of thing you want to know before the first upgrade rather than after it.

zabbix-docker compared with installing Zabbix on a VM

The search data shows people weighing these two directly, and the difference is not about which one monitors better. A VM or package install gives you the whole Zabbix stack on one filesystem with the distribution's service manager in charge: you upgrade by replacing packages, and the database lives where you put it. The container path here splits the stack into separately versioned images, all pinned to one shared ZBX_IMAGE_TAG, and coordinates them through depends_on health conditions. That makes the topology reproducible and makes the version of every component visible in one variable. It also means the database is a container in the default Compose setup, so persistence and upgrade of that database become a Compose concern rather than a package one. The repository does not argue for one approach over the other. What it does give you is a single command to raise the whole stack and a single variable to move the whole stack forward, which is the trade you are making against the familiarity of a conventional install.

Maintenance cadence, licence and what an upgrade costs

The 7.4 branch was last pushed on 2026-09-24, and releases in the recent list include 7.4.15 on 2026-09-23, 7.0.31 on 2026-09-22 and 7.4.14 on 2026-08-25. Two maintained lines, 7.4 and 7.0, are receiving releases in the same week, which tells you the project supports more than one version at a time and that you should expect to choose a line rather than follow a single moving target. The Makefile defaults ZBX_VERSION to 7.4, so the default path tracks the newer line. Because every service in compose.yaml draws its image tag from ZBX_IMAGE_TAG, an upgrade is conceptually a change to one value, but the README does not describe the database migration steps that a server version change implies, and the server-db-init service exists precisely because schema work is a separate stage. Treat the version bump as the beginning of an upgrade, not the whole of it. On licensing, the README states that starting from Zabbix version 7.0, all subsequent versions are released under the GNU Affero General Public License, and the repository's own LICENSE is AGPL-3.0. The AGPL's network-use clause is the part teams usually need to read, and that is a question for your own counsel rather than for this article.

Editorial conclusion

Adopt zabbix-docker if you want the vendor's own images and a Compose stack you can start with make up, and if your environment can run docker compose 2.24.0 or newer with make available. Do not adopt it if you need a documented rollback path, a supported Windows server image, or an upgrade procedure spelled out in the README; the repository does not provide one. Before committing, verify which tags exist for the branch you intend to run, confirm that the .env variables you plan to override are the ones the compose files actually read, and check the Wiki page for the problem you are most likely to hit.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. zabbix/zabbix-docker on GitHub