DEV.co
Open-Source Observability · zabbix

zabbix-docker

zabbix-docker provides official Docker containerization for Zabbix, an enterprise-class distributed monitoring platform. It offers pre-built images for multiple components (server, web UI, agents, proxies) across Alpine, CentOS, Oracle Linux, and Ubuntu base images, with Docker Compose support for quick setup.

Source: GitHub — github.com/zabbix/zabbix-docker
2.8k
GitHub stars
1.4k
Forks
Dockerfile
Primary language
AGPL-3.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryzabbix/zabbix-docker
Ownerzabbix
Primary languageDockerfile
LicenseAGPL-3.0 — OSI-approved
Stars2.8k
Forks1.4k
Open issues5
Latest release6.0.47 (2026-07-07)
Last updated2026-07-08
Sourcehttps://github.com/zabbix/zabbix-docker

What zabbix-docker is

Repository of Dockerfiles that package Zabbix monitoring components into container images published to Docker Hub. Supports multiple database backends (MySQL/MariaDB, PostgreSQL, SQLite3), web servers (Apache, Nginx), and includes tooling (Makefile, docker-compose) for local builds and orchestration.

Quickstart

Get the zabbix-docker source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/zabbix/zabbix-docker.gitcd zabbix-docker# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Rapid Zabbix Deployment at Scale

Organizations needing to deploy Zabbix monitoring infrastructure quickly across Kubernetes or Docker Swarm can use pre-built, officially-maintained images with minimal configuration.

Multi-Database Monitoring Setups

Teams requiring flexibility to choose between MySQL, PostgreSQL, or SQLite backends can select purpose-built images without rebuilding or maintaining custom Dockerfiles.

Local Development & CI/CD Testing

Engineers developing Zabbix integrations or testing monitoring policies can spin up full Zabbix stacks locally using provided docker-compose files and Makefile targets.

Implementation considerations

  • Database backend must be selected upfront (MySQL/MariaDB, PostgreSQL, SQLite3); switching requires data migration and redeployment.
  • Web server choice (Apache vs Nginx) should align with existing infrastructure and performance requirements; both are provided but not interchangeable without rebuilding.
  • Compose file variables and Makefile targets assume familiarity with docker-compose v2.24.0+; environments with older or restricted Docker tooling may face compatibility issues.
  • Agent and server components are separate images; multi-component deployments require coordinating multiple image versions and inter-service networking.
  • Data persistence (database volumes) must be explicitly configured in compose files; default in-memory or ephemeral setups will lose monitoring history on restart.

When to avoid it — and what to weigh

  • Proprietary Modifications Required — AGPLv3 licensing requires any deployed modifications to be made available under the same license. If you need closed-source customizations without source disclosure, this is not suitable.
  • No Commercial Support Expectation Without Purchase — The README explicitly states Zabbix requests commercial support purchases for production use. Expect community-only support unless you engage Zabbix formally.
  • Minimal Container Image Tuning — If you require heavily optimized, security-hardened, or specialized base images (e.g., distroless, custom minimal builds), the provided Alpine/CentOS/Ubuntu variants may not meet strict footprint or security policies.
  • Legacy Zabbix Versions Pre-7.0 — If locked to Zabbix versions 6.4 or earlier (GPLv2), be aware future images use AGPLv3. Migration path and licensing differences require review.

License & commercial use

Zabbix 7.0+ uses AGPLv3; versions 6.4 and earlier use GPLv2. AGPLv3 is a copyleft license requiring source disclosure of any modifications and derivatives distributed or networked. This repository contains Dockerfiles (infrastructure code) licensed under AGPLv3, meaning modifications to these Dockerfiles must be made publicly available under the same license.

AGPLv3 permits commercial deployment but triggers disclosure obligations for modifications. The README explicitly requests commercial support purchases for production use. Using unmodified images in production is permissible under AGPLv3, but the project maintainers recommend engaging Zabbix for support contracts. Custom modifications require careful license review before deployment.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

Repository includes OpenSSF Scorecard badge and CII Best Practices badge, indicating security review practices. Dockerfile images are built on standard base images (Alpine, CentOS, Oracle Linux, Ubuntu); inherit base OS vulnerabilities. No explicit security scanning or hardening steps are documented in the README. Network access to Zabbix server and database should be restricted; default docker-compose examples do not enforce network policies. Database credentials must be managed via secrets (docker secrets, Kubernetes secrets); examples use environment variables, which can expose credentials in logs.

Alternatives to consider

Prometheus + Grafana Stack

Modern, lighter-weight monitoring with pull-based metrics collection, simpler deployment model, and permissive (Apache 2.0 & AGPL) licensing. Better for cloud-native and Kubernetes-first environments.

ELK Stack (Elasticsearch, Logstash, Kibana) + Beats

Log aggregation and time-series analytics focus; less suited to agent-based system monitoring but superior for log searching and visualization. Elastic licensing has restrictions; consider OpenSearch for fully open alternative.

Datadog / New Relic / Observability SaaS

Fully managed, no deployment complexity, built-in support and integrations. Suitable if commercial support budget and vendor lock-in are acceptable; avoids licensing concerns.

Software development agency

Build on zabbix-docker with DEV.co software developers

Clone the repository, review the Makefile, configure your database backend, and run `make up`. Consult the official Zabbix documentation and GitHub Wiki for production hardening.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

zabbix-docker FAQ

Can I use these images commercially without contacting Zabbix?
AGPLv3 permits use, but Zabbix explicitly requests commercial support purchases. Unmodified images can be deployed in production; any modifications trigger disclosure requirements. Consult Zabbix or legal counsel if modifying Dockerfiles.
What database should I choose?
MySQL/MariaDB is widely compatible and performant for small-to-medium deployments. PostgreSQL scales better for large environments. SQLite3 is suitable only for small, single-node proxies; not recommended for servers.
Do I need separate agent images on every monitored host?
Yes. Zabbix agents (zabbix-agent or zabbix-agent2) must run on monitored systems to send metrics to the server. Dockerfiles provide agent images for containerized hosts; non-containerized hosts require native agent installation.
How do I persist monitoring data across container restarts?
Mount named volumes or bind-mounts for the database container's data directory in docker-compose. Provided compose files define volumes but require explicit configuration via .env or Makefile variables to avoid data loss.

Custom software development services

Adopting zabbix-docker is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source observability software in production.

Ready to containerize Zabbix monitoring?

Clone the repository, review the Makefile, configure your database backend, and run `make up`. Consult the official Zabbix documentation and GitHub Wiki for production hardening.