Self-Hosting Zabbix with Docker Compose

What Is Zabbix?

Zabbix is an enterprise-grade open-source monitoring platform for networks, servers, VMs, cloud services, and applications. It monitors everything from CPU load on a Raspberry Pi to thousands of network switches via SNMP. Auto-discovery finds devices on your network, templates provide out-of-box monitoring for hundreds of platforms, and the alerting system escalates through email, Slack, PagerDuty, and custom scripts. If you’ve outgrown Uptime Kuma or Gatus and need to monitor actual infrastructure — not just HTTP endpoints — Zabbix is the tool enterprises use.

Official site: zabbix.com | GitHub

Prerequisites

A Linux server (Ubuntu 22.04+ recommended)
Docker and Docker Compose installed (guide)
4 GB of RAM minimum (8 GB recommended for 100+ hosts)
10 GB of free disk space
A domain name (optional, for remote access)

Docker Compose Configuration

Zabbix has multiple components. This configuration uses the PostgreSQL backend with the Nginx web frontend:

services:
  zabbix-server:
    image: zabbix/zabbix-server-pgsql:alpine-7.4.8
    container_name: zabbix-server
    restart: unless-stopped
    environment:
      - DB_SERVER_HOST=zabbix-db
      - DB_SERVER_PORT=5432
      - POSTGRES_USER=zabbix
      - POSTGRES_PASSWORD=changeme_db
      - POSTGRES_DB=zabbix
      - ZBX_CACHESIZE=128M
      - ZBX_STARTPOLLERS=5
      - ZBX_STARTDISCOVERERS=2
    ports:
      - "10051:10051"
    volumes:
      - zabbix-server-data:/var/lib/zabbix
    depends_on:
      zabbix-db:
        condition: service_healthy
    networks:
      - zabbix-net

  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:alpine-7.4.8
    container_name: zabbix-web
    restart: unless-stopped
    environment:
      - DB_SERVER_HOST=zabbix-db
      - DB_SERVER_PORT=5432
      - POSTGRES_USER=zabbix
      - POSTGRES_PASSWORD=changeme_db
      - POSTGRES_DB=zabbix
      - ZBX_SERVER_HOST=zabbix-server
      - ZBX_SERVER_PORT=10051
      - ZBX_SERVER_NAME=Zabbix Monitoring
      - PHP_TZ=UTC
    ports:
      - "8080:8080"
    depends_on:
      - zabbix-server
    networks:
      - zabbix-net

  zabbix-agent:
    image: zabbix/zabbix-agent2:alpine-7.4.8
    container_name: zabbix-agent
    restart: unless-stopped
    environment:
      - ZBX_HOSTNAME=zabbix-server
      - ZBX_SERVER_HOST=zabbix-server
      - ZBX_SERVER_PORT=10051
    ports:
      - "10050:10050"
    depends_on:
      - zabbix-server
    networks:
      - zabbix-net

  zabbix-db:
    image: postgres:16-alpine
    container_name: zabbix-db
    restart: unless-stopped
    environment:
      - POSTGRES_USER=zabbix
      - POSTGRES_PASSWORD=changeme_db
      - POSTGRES_DB=zabbix
    volumes:
      - zabbix-pgdata:/var/lib/postgresql/data
    networks:
      - zabbix-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U zabbix"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  zabbix-server-data:
  zabbix-pgdata:

networks:
  zabbix-net:

Change POSTGRES_PASSWORD in both zabbix-server and zabbix-web to a strong password that matches zabbix-db.

Start the stack:

docker compose up -d

The first start takes a minute — the Zabbix server initializes database schema and imports default templates.

Initial Setup

Access the web UI at http://your-server-ip:8080.

Default credentials:

Username: Admin
Password: zabbix

Change the admin password immediately: Administration → Users → Admin → Change password.

Adding Your First Host

Go to Monitoring → Hosts → Create host
Set the hostname and select a host group (e.g., “Linux servers”)
Add an agent interface: IP address of the machine running the Zabbix agent, port 10050
Link a template: Templates/Operating systems → Linux by Zabbix agent
Click Add

Within minutes, Zabbix starts collecting CPU, memory, disk, and network metrics from the agent.

Key Components

Component	Docker Image	Purpose
Zabbix Server	`zabbix-server-pgsql`	Core monitoring engine — polls agents, processes data, triggers alerts
Zabbix Web	`zabbix-web-nginx-pgsql`	Web dashboard and API
Zabbix Agent 2	`zabbix-agent2`	Runs on monitored hosts, collects metrics
PostgreSQL	`postgres:16-alpine`	Stores configuration, history, and trend data

Monitoring Methods

Zabbix supports multiple data collection methods:

Method	Use Case
Zabbix Agent	Linux/Windows hosts — CPU, memory, disk, processes, logs
SNMP	Network devices — switches, routers, printers, UPS
IPMI	Server hardware — BMC, DRAC, iLO for temperature, fans, power
JMX	Java applications — heap, threads, GC stats
HTTP checks	Website and API monitoring
SSH/Telnet	Remote command execution for custom checks
Calculated items	Derived metrics from other items

Configuration

Auto-Discovery

Zabbix can scan IP ranges and automatically add discovered devices:

Go to Data collection → Discovery → Create discovery rule
Set the IP range (e.g., 192.168.1.1-254)
Choose checks: Zabbix agent, SNMP, ICMP ping
Set discovery interval (e.g., every hour)
Create discovery actions to auto-link templates and add to host groups

Alerting

Set up email notifications:

Administration → Media types → Email — configure SMTP settings
Administration → Users → Admin → Media — add your email address
Create a trigger action: Alerts → Actions → Trigger actions → Create action
Set conditions (e.g., severity ≥ Warning) and operations (send email)

Zabbix supports escalation — if a problem isn’t acknowledged within 30 minutes, notify a manager.

Templates

Templates are Zabbix’s biggest strength. Each template defines what to monitor for a specific platform:

Linux by Zabbix agent — CPU, memory, disk, network, processes
Windows by Zabbix agent — same plus Windows services, event log
Docker by Zabbix agent 2 — container stats, images, volumes
Network generic device by SNMP — interfaces, traffic, errors
PostgreSQL by Zabbix agent 2 — connections, queries, replication lag

Hundreds of templates are included by default. Community templates cover everything from Proxmox to Unraid.

Reverse Proxy

For HTTPS access, point your reverse proxy at port 8080. See Reverse Proxy Setup.

Backup

Back up the PostgreSQL database:

docker compose exec zabbix-db pg_dump -U zabbix zabbix > zabbix-backup-$(date +%Y%m%d).sql

For a full backup strategy, see Backup Strategy.

Troubleshooting

”Zabbix server is not running”

Symptom: Web UI shows “Zabbix server is not running” in red.

Fix: The server may still be initializing. Wait 60 seconds and refresh. Check logs:

docker compose logs zabbix-server

If you see database connection errors, verify POSTGRES_PASSWORD matches across all services.

Agent Shows “Unavailable”

Symptom: Host status shows a red “ZBX” icon.

Fix: Verify the agent can reach the server. The agent’s ZBX_SERVER_HOST must match the server’s container name. Check agent logs:

docker compose logs zabbix-agent

High Database Disk Usage

Symptom: PostgreSQL volume grows rapidly.

Fix: Zabbix stores historical data by default for 90 days and trends for 365 days. Reduce retention in Administration → General → Housekeeping, or per-item in template configuration.

Resource Requirements

RAM: ~500 MB idle (server + web + agent + PostgreSQL), grows with monitored hosts
CPU: Low at rest, spikes during discovery and large polling intervals
Disk: ~500 MB base, 1-10 GB per year depending on monitored host count and data retention

Verdict

Zabbix is the most capable open-source monitoring platform, period. Nothing else matches its breadth — SNMP, IPMI, JMX, agent-based, agentless, calculated metrics, log monitoring, and auto-discovery in one tool. The trade-off is complexity. Setting up Zabbix properly takes hours, not minutes. Templates help, but tuning alert thresholds and dashboards for your environment is an ongoing process. For simple HTTP endpoint monitoring, Uptime Kuma or Gatus are far simpler. For full infrastructure monitoring at homelab or enterprise scale, Zabbix is the gold standard. LibreNMS is the closest alternative for network-focused monitoring.

Frequently Asked Questions

Is Zabbix free for commercial use?

Yes. Zabbix is fully open-source under the GPL v2 license with no per-host or per-check fees. You can monitor thousands of devices commercially without any licensing cost. Zabbix LLC offers optional paid support subscriptions but the software itself is completely free for any use.

How many hosts can Zabbix monitor?

Zabbix scales to thousands of hosts on a single server. With 4 GB RAM and PostgreSQL, a typical deployment handles 100-500 hosts comfortably. For 1,000+ hosts, increase ZBX_CACHESIZE, add more pollers (ZBX_STARTPOLLERS), and allocate 8-16 GB RAM. Zabbix proxies distribute the polling load for geographically dispersed or very large environments.

How does Zabbix compare to Prometheus + Grafana?

Zabbix is an all-in-one monitoring platform with built-in alerting, dashboards, auto-discovery, and configuration. Prometheus + Grafana is a modular stack where Prometheus collects metrics and Grafana visualizes them — you assemble the pieces yourself. Zabbix excels at SNMP/IPMI infrastructure monitoring and auto-discovery. Prometheus excels at cloud-native, container, and microservice monitoring with its pull-based model. For traditional infrastructure, Zabbix is easier to deploy; for Kubernetes environments, Prometheus is the standard.

Can Zabbix monitor Docker containers?

Yes. The Zabbix Agent 2 has a built-in Docker plugin that monitors container status, resource usage, image information, and volume data. Link the “Docker by Zabbix agent 2” template to any host running the agent with Docker access. The agent needs access to the Docker socket (/var/run/docker.sock).

How do I reduce Zabbix database disk usage?

Zabbix stores historical data for 90 days and trends for 365 days by default. Reduce retention in Administration → General → Housekeeping, or override per-item in template configuration. For aggressive reduction, set history to 7 days and trends to 30 days. PostgreSQL’s TimescaleDB extension (supported by Zabbix) provides much better compression for time-series data.

Do I need Zabbix Agent on every monitored host?

No. Zabbix supports multiple monitoring methods: agent-based (richest data), SNMP (network devices), IPMI (server hardware), HTTP checks (websites), and SSH/Telnet (remote commands). For network switches and routers, SNMP is used instead of an agent. For simple availability checks, HTTP monitoring works without any agent.