Deploy Zabbix 7.4 on a VPS: Docker, Agent 2 and alerts

When one VPS turns into a dozen, top, df -h and "log in to investigate when the site won't open" are no longer enough. You need to know in advance whether the CPU is constantly maxed out, whether the disk will be exhausted within three days, whether a systemd service keeps restarting, and to be notified before a failure affects users. Zabbix brings metric collection, host discovery, templates, triggers, graphs, alerting and permission management together on one platform, making it suitable for teams that want to manage multiple Linux, Windows, network devices or business services over the long term.

This article uses Zabbix 7.4, Ubuntu 24.04, Docker Compose, PostgreSQL and Zabbix Agent 2 as its baseline, and covers server deployment, Caddy HTTPS, onboarding remote hosts, active and passive collection, PSK encryption, email/Webhook alerts, data retention, backups, upgrades and common troubleshooting. The version judgments and ports in this article follow the official Zabbix 7.4 documentation as of September 2026; the 8.0 documentation currently belongs to a development branch and should not be copied directly as a production-stable tutorial.

What scenarios Zabbix suits

Zabbix is not just a dashboard for "looking at CPU curves". Its core capabilities include:

Collecting data via Agent 2, SNMP, IPMI, JMX, HTTP, databases and cloud APIs;
Batch-creating items, triggers, graphs and low-level discovery rules through official templates;
Triggering alerts when disks run low, services stop, certificates are about to expire or interface error rates rise;
Sending notifications via email, Webhook, SMS or custom scripts;
Using host groups, user groups and roles to control which resources different teams can see;
Scaling to multiple data centers, internal networks and high-latency networks with proxy nodes.

If you only monitor 2–5 machines and want installation done within ten minutes, the Beszel lightweight server monitoring tutorial uses fewer resources; if you only care whether a website is online, Uptime Kuma is an option. When you need PromQL, log correlation and highly flexible visualization, read the Prometheus + Grafana monitoring solution. When you need a large number of ready-made templates, unified triggers, asset management and fine-grained permissions, Zabbix's integrated workflow is more suitable.

Solution	Main advantages	Main costs	Recommended scenarios
Zabbix	Complete templates, triggers, discovery, alerting and permissions	Many database and parameter details, higher learning cost	Multiple hosts, network devices, long-term operations
Prometheus + Grafana	Strong cloud-native ecosystem, flexible PromQL	Alerting, assets and long-term storage usually require combining multiple components	Kubernetes, application metrics
Beszel	Simple deployment, lightweight interface	Fewer enterprise-grade templates and complex triggers	Small-scale VPS
Uptime Kuma	Intuitive HTTP/TCP availability monitoring	Not suitable for deep host metrics and capacity analysis	Website and port liveness checks

Plan the architecture and VPS configuration first

This article uses four main components:

浏览器 -> Caddy :443 -> Zabbix Web :8080
                              |
                              +-> PostgreSQL

受监控主机 Agent 2 -> Zabbix Server :10051（主动检查）
Zabbix Server -> 受监控主机 Agent 2 :10050（被动检查）

The web frontend, Zabbix Server and PostgreSQL run as containers on the monitoring VPS; monitored hosts install Agent 2 directly. The database is not mapped to the public internet, the web container port is bound only to the loopback address, and Caddy provides the domain and HTTPS.

Zabbix officially states that database capacity mainly depends on the number of values processed per second, the history data retention period, the trend data retention period and the number of events. You cannot estimate it by "number of hosts" alone. Below are conservative starting values for a small VPS environment, not an official capacity guarantee:

Scale	Recommended starting configuration	Data retention recommendation
5–20 hosts, basic Linux metrics	2 vCPU, 4GB RAM, 60GB NVMe	History 7–14 days, Trends 365 days
20–100 hosts, including service and interface monitoring	4 vCPU, 8GB RAM, 120GB NVMe	Observe NVPS and database growth first
100+ hosts or many low-interval items	8 vCPU, 16GB RAM and up	Split Proxy and tune the database after load testing

Although 1GB or 2GB of RAM may start, PostgreSQL, Server, Web and Docker on the same machine leave very little headroom. Once the monitoring system itself stops due to OOM, it falls silent exactly when you need alerts most. Production environments should also place backups on another machine or object storage, not only on the same disk as the monitoring VPS.

Domain, time and port planning

Prepare a domain, for example zabbix.example.com, and add an A record pointing to the VPS public IP. If you do not have correct, working IPv6, do not add an incorrect AAAA record.

All Zabbix components must keep accurate time. The official requirements page specifically emphasizes time synchronization, because clock drift causes anomalies in data timestamps, trigger evaluation and graphs. On Ubuntu 24.04 you can check:

timedatectl status
systemctl status systemd-timesyncd --no-pager

Open default ports according to the actual collection mode:

Port	Direction	Purpose	Recommendation
`80/443 TCP`	Browser to monitoring VPS	HTTP validation and HTTPS management interface	Open to the public internet, can add VPN/IP restrictions later
`10051/TCP`	Agent/Proxy to Server	Active checks, Trapper, Proxy	Allow only monitored subnets or via VPN
`10050/TCP`	Server to Agent 2	Passive checks	Allow only the Zabbix Server IP on each Agent
`5432/TCP`	Internal container network	PostgreSQL	Not mapped to the public internet
`8080/8443 TCP`	Local Caddy to Web container	Container frontend	Bind only to `127.0.0.1`

Active checks have Agent 2 actively connect to the Server's 10051/TCP, which suits hosts behind NAT, with frequently changing IPs, or where you do not want to expose 10050 to the outside. Passive checks have the Server connect to Agent 2's 10050/TCP; configuration is intuitive, but the Server must be able to reach the Agent directly. Both modes can coexist; ultimately it depends on the item types in the template.

If a port is already listening but external connections still fail, follow the port, firewall and security group troubleshooting guide to check the cloud security group, UFW, Docker port mapping and listening address at the same time.

Install Docker and basic tools

First update the system and install Git, Make, OpenSSL and Caddy. Docker should be installed from the official Docker Ubuntu repository; if the machine is already running Docker, do not re-run scripts that would change the repository configuration.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y git make openssl ca-certificates curl caddy
docker --version
docker compose version

The official Zabbix 7.4 container documentation requires Docker Compose 2.24.0 or higher:

docker compose version --short

If the output is lower than 2.24.0, upgrade the Docker Compose plugin first. Production deployments should also understand health checks, log rotation, resource limits and rollback; you can first read the Docker Compose production configuration checklist.

Get the official Zabbix 7.4 Compose files

The official zabbix/zabbix-docker repository contains both MySQL/MariaDB and PostgreSQL combinations. This article explicitly checks out the 7.4 branch and uses compose_pgsql.yaml:

sudo git clone --depth 1 --branch 7.4 \
  https://github.com/zabbix/zabbix-docker.git /opt/zabbix-docker
sudo chown -R "$USER":"$USER" /opt/zabbix-docker
cd /opt/zabbix-docker
git branch --show-current
docker compose version

The expected branch is 7.4. The repository's default .env uses Alpine-series Zabbix 7.4 images and PostgreSQL 17 Alpine; the official Zabbix 7.4 requirements page supports PostgreSQL 15–18.

Do not use the example database password in the repository directly. The official repository's env_vars/.POSTGRES_PASSWORD is the example value zabbix, which must be replaced before the first start:

cd /opt/zabbix-docker
umask 077
openssl rand -base64 36 | tr -d '\n' > env_vars/.POSTGRES_PASSWORD
printf '\n' >> env_vars/.POSTGRES_PASSWORD
chmod 600 env_vars/.POSTGRES_PASSWORD

Do not copy real passwords into tutorials, tickets or Git commits. Compose provides the PostgreSQL user and password to the Server, Web and database containers through file-based secrets.

Make the Web port listen only on localhost

The official Compose publishes the Web port by default. To prevent 8080 and 8443 from bypassing Caddy and being exposed directly, create a local override file that restricts both ports to the loopback address:

services:
  zabbix-web-nginx-pgsql:
    ports:
      - name: web-http
        target: 8080
        published: "8080"
        host_ip: 127.0.0.1
        protocol: tcp
      - name: web-https
        target: 8443
        published: "8443"
        host_ip: 127.0.0.1
        protocol: tcp

Save it as /opt/zabbix-docker/compose.local.yaml, then render the configuration first to check syntax and final ports:

cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml config > /tmp/zabbix-compose-rendered.yaml
grep -nE 'host_ip|published|target' /tmp/zabbix-compose-rendered.yaml

Confirm that the Web's host_ip is 127.0.0.1, then start the minimal component set:

docker compose -f compose_pgsql.yaml -f compose.local.yaml pull
docker compose -f compose_pgsql.yaml -f compose.local.yaml up -d
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps

The first start needs to initialize the PostgreSQL schema, and the time depends on VPS disk and image download speed. Do not judge failure just because the initialization container exits; server-db-init is supposed to end after completing normally. Focus on whether PostgreSQL, Zabbix Server and Nginx Web are running or healthy:

docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 postgres-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-web-nginx-pgsql
curl -I http://127.0.0.1:8080/
ss -lntp | grep -E ':8080|:8443|:10051'

8080 and 8443 should appear only in 127.0.0.1; whether 10051 listens externally depends on whether you need external Agents to connect actively. Even if you must publish 10051, restrict the source in the cloud security group and host firewall.

Configure the domain and HTTPS with Caddy

Create /etc/caddy/Caddyfile:

zabbix.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:8080

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Replace the example domain with the real domain, check and reload:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
curl -I https://zabbix.example.com/

Caddy automatically requests and renews certificates, but only if the domain resolves correctly, public 80/443 can reach the VPS, and there is no incorrect AAAA record. For more on multiple domains, reverse proxy headers and certificate troubleshooting, see the Caddy automatic HTTPS tutorial.

The initial account given in the official Zabbix quick start is:

用户名：Admin
密码：zabbix

Change the Admin password immediately after the first login. Do not treat Caddy's HTTPS as a complete backend security strategy; you should also:

Create an independent account for each administrator, without sharing Admin;
Assign roles, user groups and host group permissions by responsibility;
Enable a strong password policy and configure MFA where conditions allow;
When public management is not needed, restrict the frontend via WireGuard/Tailscale or a fixed IP;
Record changes separately in the system, firewall and Zabbix;
Have the monitoring platform itself externally probed, so that "the monitoring system is dead but nobody knows" does not happen.

The Zabbix frontend pauses for 30 seconds after five consecutive failed logins, but this is not a reason to replace reverse proxy access restrictions, MFA and strong passwords.

Install Zabbix Agent 2 on Ubuntu 24.04

The following operations are performed on a monitored Ubuntu 24.04 VPS. Use the official Zabbix 7.4 software repository; do not install the Agent from unknown scripts:

cd /tmp
wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb
sudo apt update
sudo apt install -y zabbix-agent2
zabbix_agent2 -V

First decide whether to use active checks or passive checks.

Active check configuration

Active mode only requires the Agent to reach the monitoring VPS's 10051/TCP, making it more suitable for public VPS. Edit the key items in /etc/zabbix/zabbix_agent2.conf:

ServerActive=zabbix.example.com:10051
Hostname=web-01.example.com

Hostname is case-sensitive and must exactly match the Host name entered when creating the host in the Zabbix frontend. Without ServerActive, active checks are disabled.

Passive check configuration

Passive mode has the Server access the Agent's 10050/TCP:

Server=监控VPS的固定公网IP
ListenPort=10050
Hostname=web-01.example.com

Server determines which Servers or Proxies are allowed to initiate connections. Do not write 0.0.0.0/0 just for convenience. At the same time, allow only the monitoring VPS in the cloud security group and UFW:

sudo ufw allow from 监控VPS的固定公网IP to any port 10050 proto tcp
sudo ufw status numbered

Check the configuration and start:

sudo zabbix_agent2 -t system.cpu.load
sudo systemctl enable --now zabbix-agent2
sudo systemctl status zabbix-agent2 --no-pager
sudo journalctl -u zabbix-agent2 -n 100 --no-pager

Configure PSK encryption for Agent 2

HTTPS only protects the link from the browser to the Web frontend and does not automatically encrypt Agent-to-Server communication. Zabbix components support three connection methods: unencrypted, certificate and PSK. For small-scale VPS, generate an independent PSK for each host:

sudo install -d -m 750 -o root -g zabbix /etc/zabbix/keys
sudo sh -c 'openssl rand -hex 32 > /etc/zabbix/keys/web-01.psk'
sudo chown root:zabbix /etc/zabbix/keys/web-01.psk
sudo chmod 640 /etc/zabbix/keys/web-01.psk

For active checks add:

TLSConnect=psk
TLSPSKIdentity=web-01-psk
TLSPSKFile=/etc/zabbix/keys/web-01.psk

If passive checks are also used, add:

TLSAccept=psk

Then restart the Agent:

sudo systemctl restart zabbix-agent2
sudo journalctl -u zabbix-agent2 -n 50 --no-pager

On the Encryption tab of the host in the Zabbix frontend, select the same connection mode and enter exactly the same PSK identity and key. Do not send keys to group chats, and do not let multiple hosts share the same one. The official documentation states that Agent 2's TLSConnect is used for outbound connections for active checks, and TLSAccept is used for inbound connections for passive checks; when the modes on both ends differ, it will not automatically fall back to another encryption method.

Add the host and Linux template in the frontend

Go to Data collection → Hosts → Create host:

Set Host name to web-01.example.com, exactly matching Agent 2's Hostname;
Add a host group such as Linux servers;
For active mode you can create an Agent interface but do not rely on the Server connecting to it directly; for passive mode enter the host's reachable IP and 10050;
Link the corresponding Linux Agent/Agent active templates bundled with Zabbix 7.4;
Enter this host's PSK configuration in Encryption;
After saving, observe Availability, Latest data and the Agent logs.

Do not attach all templates at once at the beginning. The more templates and the shorter the collection interval, the faster the number of new values per second and database growth. First satisfy CPU, memory, disk, network, process and service status, then add Nginx, PostgreSQL, Docker or custom application monitoring according to business needs.

Recommended first verifications:

Whether Latest data shows CPU, memory and filesystem metrics;
Whether the host name matches exactly;
Whether active checks can connect to 10051;
Whether the Server can connect to the Agent's 10050 during passive checks;
Whether Monitoring → Problems shows unsupported items;
Whether the system times of the Server and Agent 2 are consistent.

Configure email and Webhook alerts

The current official Zabbix documentation supports Email, SMS, custom scripts and Webhook media types. To actually receive notifications, three conditions must all be met: a working media type, Media on the user account, and an Action matching the event.

Email alerts

Go to Alerts → Media types, open the Email type and fill in the SMTP server, port, encryption method, sender address and authentication information. Prefer managing the SMTP password with macros; do not leave plaintext secrets directly in a media type configuration that will be exported.

Then:

Open Media in the recipient's user profile and add the email address;
Select the receiving time period and severity levels;
Create an action in Alerts → Actions → Trigger actions;
Set conditions such as host group and severity;
Select users or user groups in Operations;
Create a test trigger and verify both the Problem and Recovery notifications.

Clicking "test successful" on the media type page alone does not mean real failures will be notified, because the Action, user Media or permissions may still be missing.

Webhook alerts

If you use a chat bot or ticketing system, you can copy the official built-in Webhook media type and fill in the target URL, Token, channel and message parameters. Store secrets in Secret-type macros and restrict Webhooks to send requests only to trusted domains.

Before production, at least test:

Whether the Problem message includes the host, trigger, severity and event link;
Whether Recovery can be correlated with the original event;
Whether repeated alerts and escalation steps match the on-call policy;
Whether Zabbix records send failures when the external service is rate-limited or unavailable;
Whether the trigger and action configuration are restored after test alerts end.

Control history data, trend data and disk growth

Zabbix's History stores raw high-granularity values, while Trends stores data aggregated by hour. Keeping all History for a year is usually unnecessary and will significantly increase PostgreSQL size, backup time and upgrade risk.

Small-scale environments can start with the following policy and then adjust according to compliance and troubleshooting needs:

Data	Starting retention period	Purpose
High-frequency History	7–14 days	Recent failures and fine-grained analysis
Regular History	Within 30 days	Routine troubleshooting
Trends	365 days	Capacity trends and year-over-year comparison
Events/Alerts	90–180 days	Failure post-mortems
Audit log	Per security and compliance requirements	Management operation tracking

Go to Administration → Housekeeping to check internal housekeeping. The official documentation states that it deletes expired or deleted data to prevent unbounded database growth and performance degradation. Do not suddenly shrink the retention period from one year to one day and expect the database to immediately become smaller; mass deletion creates database load, and space reclamation also depends on PostgreSQL's maintenance mechanisms.

Record container, database and data directory sizes weekly:

cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
docker system df
sudo du -sh /opt/zabbix-docker/zbx_env
df -h /

At the same time, monitor the "monitoring VPS" itself for disk space, queues, processes and internal performance metrics within Zabbix.

Back up PostgreSQL, configuration and keys

A valid backup includes at least:

A logical backup of the PostgreSQL database;
/opt/zabbix-docker/.env, env_vars, override files and custom scripts/certificates in zbx_env;
/etc/caddy/Caddyfile;
The Agent-side /etc/zabbix configuration and PSK;
A recovery document that clearly states the version, recovery order and DNS/firewall dependencies.

Create a database backup:

cd /opt/zabbix-docker
sudo install -d -m 700 /var/backups/zabbix
docker compose -f compose_pgsql.yaml -f compose.local.yaml \
  exec -T postgres-server pg_dump -U zabbix -d zabbix -Fc \
  > /var/backups/zabbix/zabbix-$(date +%F-%H%M).dump
ls -lh /var/backups/zabbix/

Configuration files can be archived separately, but they contain database passwords and PSKs, so the backup medium must be encrypted and permissions restricted:

sudo tar -C / -czf /var/backups/zabbix/zabbix-config-$(date +%F-%H%M).tar.gz \
  opt/zabbix-docker/.env \
  opt/zabbix-docker/env_vars \
  opt/zabbix-docker/compose.local.yaml \
  etc/caddy/Caddyfile
sudo chmod 600 /var/backups/zabbix/*

Then sync the backup to another machine or object storage, and regularly restore it in an isolated environment. Merely seeing that a backup file exists does not mean it can be restored. For a complete drill process covering databases, Docker Volumes, restic and rclone, see VPS backup and recovery drill.

When testing recovery, first deploy the same major version of Zabbix and an empty PostgreSQL, then import:

cat /path/to/zabbix.dump | docker compose \
  -f compose_pgsql.yaml -f compose.local.yaml \
  exec -T postgres-server pg_restore -U zabbix -d zabbix --clean --if-exists

This command will clean up objects that already exist in the target database; it can only be executed in a confirmed disposable recovery test database or an explicit disaster recovery process, and must not be run casually against a production database still serving traffic.

Safely upgrade the Zabbix 7.4 containers

The official 7.4 Compose uses the latest tag of the same branch by default, so pull may pull a new 7.4 patch image. Before upgrading, you must read the upgrade notes and back up the database, configuration and files. Zabbix Server may automatically perform a database upgrade on startup; if the database upgrade fails, the service will not start normally.

Recommended process:

Record the current image ID, Zabbix version and Git commit;
Complete off-machine database and configuration backups;
Verify the upgrade in a test environment;
Schedule a maintenance window and stop writes;
Update the 7.4 branch Compose files and render the diff;
Pull the images and rebuild;
Continuously observe the Server and PostgreSQL logs;
Verify login, Latest data, Problems, notifications and Agent connections.

Check the current status:

cd /opt/zabbix-docker
git rev-parse --short HEAD
docker compose -f compose_pgsql.yaml -f compose.local.yaml images
docker compose -f compose_pgsql.yaml -f compose.local.yaml exec -T zabbix-server zabbix_server -V

Do not blindly change branches across major versions and then run up -d directly, and do not rely on cloud snapshots when there is no database backup. Database rollback and container image rollback must go together; an old Server cannot be guaranteed to read an upgraded new database schema.

Common troubleshooting

The Web frontend shows a database connection error

Check the PostgreSQL health status, secret file permissions and the logs of the three components:

cd /opt/zabbix-docker
docker compose -f compose_pgsql.yaml -f compose.local.yaml ps
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 postgres-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-server
docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-web-nginx-pgsql

If you changed the PostgreSQL password after the first start, the old password in the database volume will not be synchronized automatically. Do not repeatedly delete volumes hoping for luck; first confirm whether there is production data, then change the PostgreSQL password and sync the secret, or rebuild from a verified backup.

Agent 2 shows unavailable

For active mode, focus on checking:

getent ahosts zabbix.example.com
nc -vz zabbix.example.com 10051
sudo journalctl -u zabbix-agent2 -n 100 --no-pager

For passive mode, test the Agent's 10050 from the network where the Server resides, and check the cloud security group, UFW and the Server= allowlist. Both modes require checking the case-sensitive Hostname.

Logs show no active checks or host not found

This is usually because Agent 2's Hostname does not match the frontend Host name, the host is disabled, the template has no active-type items, or the Agent cannot connect to ServerActive. Do not just change the Display name; it is not the Host name used for active check matching.

PSK handshake fails

Check the connection direction between the frontend and the Agent, the PSK identity, the key content and permissions. For active checks look at TLSConnect; for passive checks look at TLSAccept. An extra newline when copying the key can usually be handled by file reading, but spaces, wrong paths, different identities or the wrong encryption mode selected in the frontend will all cause failure.

Database and disk grow too fast

First look at newly added hosts, templates, low collection intervals, LLD discovery items, History/Trends retention periods and the number of values processed per second. Blindly expanding the disk only postpones the problem. First reduce worthless items and adjust retention policies, then evaluate PostgreSQL parameters, partitioning or TimescaleDB.

The IP works but domain HTTPS fails

Check A/AAAA resolution, Caddy logs, public 80/443, the security group, and whether the Web port still listens only on 127.0.0.1:

getent ahosts zabbix.example.com
sudo journalctl -u caddy -n 100 --no-pager
curl -I http://127.0.0.1:8080/
curl -I https://zabbix.example.com/
ss -lntp | grep -E ':80|:443|:8080|:8443'

Go-live acceptance checklist

Zabbix Server, Web and PostgreSQL all run normally, and the initialization container completes normally;
The Web's 8080/8443 is bound only to 127.0.0.1;
The domain HTTPS is valid, and HTTP automatically redirects to HTTPS;
The default Admin/zabbix password has been changed;
Administrators use independent accounts, least privilege and MFA;
Agent active/passive modes match the firewall direction;
PSK is configured per host, not reused, and not committed to Git;
Latest data keeps updating, and host clocks are synchronized;
Both Problem and Recovery for email or Webhook have been actually tested;
History, Trends, Events and Audit retention periods have been planned;
PostgreSQL and configuration are backed up off-machine, and a recovery drill has been completed;
External liveness probing can detect that Zabbix itself is offline.

FAQ

Can a VPS with 2GB of RAM run Zabbix?

It may run with small scale and low-frequency collection, but PostgreSQL, Server, Web and Docker on the same machine leave very little memory headroom. New deployments are better off starting at 4GB of RAM, with Swap configured and OOM and database growth monitored. The number of hosts is not the only variable; the number of items and the collection interval matter more.

Should Zabbix Agent 2 use active mode or passive mode?

Public VPS, hosts behind NAT and hosts with dynamic IPs should prefer active mode, which only requires outbound access to the Server's 10051/TCP. Passive mode can be used when the network is controllable and the Server can reach the Agent directly. The two can coexist, but the template item types, port directions and encryption configuration must match.

Must port 10050 be opened after installing Agent 2?

Not necessarily. When only active checks are used, the Agent actively connects to the Server's 10051, so 10050 does not need to be open to the public internet. Only when passive checks are used do you need to let the Server access the Agent's 10050, and you should allow only the fixed IPs of the Server or Proxy.

Why do I still not receive emails on failure after configuring the mailbox?

A working media type is only the first step. You also need to add Media to the recipient user, enable the corresponding severity and time period, and create a Trigger action and Operation matching the event. Test the media type, Problem, Recovery and escalation steps separately, and check the send errors in Alerts.

Can Zabbix monitor Docker containers?

Yes, Agent 2 has a plugin and template ecosystem, but permissions such as the Docker Socket must be granted carefully. Reading the Docker Socket is usually equivalent to high host privileges; do not expose the Socket without restriction to arbitrary containers or users just to display a container list. Monitor the host and key services first, then add container metrics with least privilege.

How can a Docker-deployed Zabbix be upgraded safely?

First back up PostgreSQL, configuration and keys, verify the same-major-version upgrade in a test environment, then pull images during a maintenance window and observe the database upgrade logs. Do not back up only the containers, and do not simply switch back to an old Server image after the database has already been upgraded. Read the official upgrade notes before crossing major versions.

Official resources

The value of Zabbix is not "how many graphs it can draw", but turning collection, thresholds, notifications, permissions and recovery verification into a continuously maintainable operations process. Start with a small number of key metrics, run through one real alert and recovery, and then gradually expand templates; this is more reliable than importing tens of thousands of items on day one.

Solution

Main advantages

Main costs

Recommended scenarios

Zabbix

Complete templates, triggers, discovery, alerting and permissions

Many database and parameter details, higher learning cost

Multiple hosts, network devices, long-term operations

Prometheus + Grafana

Strong cloud-native ecosystem, flexible PromQL

Alerting, assets and long-term storage usually require combining multiple components

Kubernetes, application metrics

Beszel

Simple deployment, lightweight interface

Fewer enterprise-grade templates and complex triggers

Small-scale VPS

Uptime Kuma

Intuitive HTTP/TCP availability monitoring

Not suitable for deep host metrics and capacity analysis

Website and port liveness checks

浏览器 -> Caddy :443 -> Zabbix Web :8080 | +-> PostgreSQL 受监控主机 Agent 2 -> Zabbix Server :10051（主动检查） Zabbix Server -> 受监控主机 Agent 2 :10050（被动检查）

Scale

Recommended starting configuration

Data retention recommendation

5–20 hosts, basic Linux metrics

2 vCPU, 4GB RAM, 60GB NVMe

History 7–14 days, Trends 365 days

20–100 hosts, including service and interface monitoring

4 vCPU, 8GB RAM, 120GB NVMe

Observe NVPS and database growth first

100+ hosts or many low-interval items

8 vCPU, 16GB RAM and up

Split Proxy and tune the database after load testing

Port

Direction

Purpose

Recommendation

80/443 TCP

Browser to monitoring VPS

HTTP validation and HTTPS management interface

Open to the public internet, can add VPN/IP restrictions later

10051/TCP

Agent/Proxy to Server

Active checks, Trapper, Proxy

Allow only monitored subnets or via VPN

10050/TCP

Server to Agent 2

Passive checks

Allow only the Zabbix Server IP on each Agent

5432/TCP

Internal container network

PostgreSQL

Not mapped to the public internet

8080/8443 TCP

Local Caddy to Web container

Container frontend

Bind only to 127.0.0.1

sudo git clone --depth 1 --branch 7.4 \ https://github.com/zabbix/zabbix-docker.git /opt/zabbix-docker sudo chown -R "$USER":"$USER" /opt/zabbix-docker cd /opt/zabbix-docker git branch --show-current docker compose version

services: zabbix-web-nginx-pgsql: ports: - name: web-http target: 8080 published: "8080" host_ip: 127.0.0.1 protocol: tcp - name: web-https target: 8443 published: "8443" host_ip: 127.0.0.1 protocol: tcp

docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 postgres-server docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-server docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=100 zabbix-web-nginx-pgsql curl -I http://127.0.0.1:8080/ ss -lntp | grep -E ':8080|:8443|:10051'

zabbix.example.com { encode zstd gzip reverse_proxy 127.0.0.1:8080 header { Strict-Transport-Security "max-age=31536000; includeSubDomains" X-Content-Type-Options "nosniff" Referrer-Policy "strict-origin-when-cross-origin" } }

cd /tmp wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu24.04_all.deb sudo dpkg -i zabbix-release_latest_7.4+ubuntu24.04_all.deb sudo apt update sudo apt install -y zabbix-agent2 zabbix_agent2 -V

sudo install -d -m 750 -o root -g zabbix /etc/zabbix/keys sudo sh -c 'openssl rand -hex 32 > /etc/zabbix/keys/web-01.psk' sudo chown root:zabbix /etc/zabbix/keys/web-01.psk sudo chmod 640 /etc/zabbix/keys/web-01.psk

Data

Starting retention period

Purpose

High-frequency History

7–14 days

Recent failures and fine-grained analysis

Regular History

Within 30 days

Routine troubleshooting

Trends

365 days

Capacity trends and year-over-year comparison

Events/Alerts

90–180 days

Failure post-mortems

Audit log

Per security and compliance requirements

Management operation tracking

cd /opt/zabbix-docker sudo install -d -m 700 /var/backups/zabbix docker compose -f compose_pgsql.yaml -f compose.local.yaml \ exec -T postgres-server pg_dump -U zabbix -d zabbix -Fc \ > /var/backups/zabbix/zabbix-$(date +%F-%H%M).dump ls -lh /var/backups/zabbix/

sudo tar -C / -czf /var/backups/zabbix/zabbix-config-$(date +%F-%H%M).tar.gz \ opt/zabbix-docker/.env \ opt/zabbix-docker/env_vars \ opt/zabbix-docker/compose.local.yaml \ etc/caddy/Caddyfile sudo chmod 600 /var/backups/zabbix/*

cd /opt/zabbix-docker git rev-parse --short HEAD docker compose -f compose_pgsql.yaml -f compose.local.yaml images docker compose -f compose_pgsql.yaml -f compose.local.yaml exec -T zabbix-server zabbix_server -V

cd /opt/zabbix-docker docker compose -f compose_pgsql.yaml -f compose.local.yaml ps docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 postgres-server docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-server docker compose -f compose_pgsql.yaml -f compose.local.yaml logs --tail=200 zabbix-web-nginx-pgsql

What scenarios Zabbix suits

Plan the architecture and VPS configuration first

Domain, time and port planning

Install Docker and basic tools

Get the official Zabbix 7.4 Compose files

Make the Web port listen only on localhost

Configure the domain and HTTPS with Caddy

Harden immediately after the first login

Install Zabbix Agent 2 on Ubuntu 24.04

Active check configuration

Passive check configuration

Configure PSK encryption for Agent 2

Add the host and Linux template in the frontend

Configure email and Webhook alerts

Email alerts

Webhook alerts

Control history data, trend data and disk growth

Back up PostgreSQL, configuration and keys

Safely upgrade the Zabbix 7.4 containers

Common troubleshooting

The Web frontend shows a database connection error

Agent 2 shows unavailable

Logs show no active checks or host not found

PSK handshake fails

Database and disk grow too fast

The IP works but domain HTTPS fails

Go-live acceptance checklist

FAQ

Can a VPS with 2GB of RAM run Zabbix?

Should Zabbix Agent 2 use active mode or passive mode?

Must port 10050 be opened after installing Agent 2?

Why do I still not receive emails on failure after configuring the mailbox?

Can Zabbix monitor Docker containers?

How can a Docker-deployed Zabbix be upgraded safely?

Official resources

Loading…

What scenarios Zabbix suits

Plan the architecture and VPS configuration first

Domain, time and port planning

Install Docker and basic tools

Get the official Zabbix 7.4 Compose files

Make the Web port listen only on localhost

Configure the domain and HTTPS with Caddy

Harden immediately after the first login

Install Zabbix Agent 2 on Ubuntu 24.04

Active check configuration

Passive check configuration

Configure PSK encryption for Agent 2

Add the host and Linux template in the frontend

Configure email and Webhook alerts

Email alerts

Webhook alerts

Control history data, trend data and disk growth

Back up PostgreSQL, configuration and keys

Safely upgrade the Zabbix 7.4 containers

Common troubleshooting

The Web frontend shows a database connection error

Agent 2 shows unavailable

Logs show no active checks or host not found

PSK handshake fails

Database and disk grow too fast

The IP works but domain HTTPS fails

Go-live acceptance checklist

FAQ

Can a VPS with 2GB of RAM run Zabbix?

Should Zabbix Agent 2 use active mode or passive mode?

Must port 10050 be opened after installing Agent 2?

Why do I still not receive emails on failure after configuring the mailbox?

Can Zabbix monitor Docker containers?

How can a Docker-deployed Zabbix be upgraded safely?

Official resources