Zabbix 8.0 LTS: What's New and How to Upgrade from 7.0

Zabbix 8.0 LTS: What's New and How to Upgrade from 7.0

Zabbix 8.0 LTS shipped on November 5, 2026, and Zabbix calls it its "most significant release yet." If you're on 7.0 LTS, you don't have to move this week: 7.0 gets full support until June 30, 2027. You do want a plan, though, and the first thing that plan needs to check isn't Zabbix at all. It's your database.

Here's what's new, what changes on the way from 7.0, and how to upgrade a Docker setup without losing your monitoring history.

What's New in 8.0

The What's new page is long. These are the parts most teams will care about:

  • Application performance monitoring with OpenTelemetry. The proxy can receive OTLP data, and a new APM menu shows traces, metrics and logs next to everything else Zabbix already watches.
  • ClickHouse as a history backend. Item history can now live in ClickHouse, which is built for this kind of high-volume, time-ordered data.
  • Complex event processing. Rule-based handling that groups related events, marks a cause and its symptoms, and cuts alert noise.
  • A built-in MCP server. AI agents can talk to Zabbix through the Model Context Protocol. They connect with a Zabbix API token, so they can only access what the token's owner can, and their changes show up in the audit log under that user.
  • Interface updates, including a dark blue theme, custom table layouts, dashboard export and import, and a scatter plot widget.

On the support side, 8.0 gets full support until November 30, 2029 and limited support until November 30, 2031. That's two and a half more years than 7.0.

Check Your Database First

This is the step that stops most upgrades. Zabbix 8.0 raised its minimum database versions, and by default the server checks the version at startup and refuses anything unsupported:

ComponentSupported in 8.0
PostgreSQL15.0 to 18.x
TimescaleDB2.20 to 2.29 (Community Edition)
MySQL / Percona8.4.0 to 9.7.x
MariaDB10.11 to 12.3.x
ClickHouse (history)26.3 to 26.9
PHP (frontend)8.2 to 8.5

Run this against your database container. Replace postgres and the zabbix user with what your docker-compose.yml uses:

docker compose exec -T postgres psql -U zabbix -c "SELECT version();"

If you're still on PostgreSQL 14, upgrade that first: it reaches end of life on November 12 anyway, and we covered it in PostgreSQL 14 End of Life: How to Upgrade to 18 in Docker. On MariaDB 10.6, see How to Upgrade MariaDB 10.6 to 11.8. On MySQL 8.0, you need 8.4 first.

One more for MySQL users: Zabbix strongly recommends converting the database to the utf8mb4 character set and utf8mb4_bin collation before upgrading.

The Other Changes That Can Bite

Most of 8.0's breaking changes are niche, but these are worth checking before you start:

  • API access for roles. An empty API allow list now blocks every method, where it used to be ignored. The upgrade adds a * wildcard to affected roles so nothing breaks, so review them afterwards under Users > User roles and narrow them down.
  • TLS verification for HTTP templates and webhooks. Templates and media types that call HTTPS endpoints now verify certificates by default, controlled by the new {$HTTP.TLS.VERIFY} macro. The upgrade doesn't update your existing templates and media types automatically, so plan to upgrade them yourself.
  • History storage settings. If you send history to Elasticsearch, the old HistoryStorageURL and HistoryStorageTypes parameters are deprecated in favor of HistoryProvider. Elasticsearch also needs 8.0 or later.
  • Host interface API methods were removed. Scripts that call them will fail.
  • Pre-1.6 agents are no longer supported.

You're also jumping over 7.2 and 7.4, so read their upgrade notes too. The 7.4 notes flag templates that need upgrading and a change to how users manage their own media.

Upgrading a Docker Setup

Direct upgrades to 8.0 are supported from any version since 2.0, so 7.0 can go straight there.

1. Back up the database. The official container guide doesn't mention backups, which is exactly why you shouldn't skip one. Zabbix rewrites its schema on first start, and you can't go back afterwards. For PostgreSQL:

docker compose exec -T postgres pg_dump -U zabbix -Fc zabbix > zabbix-7.0.dump

2. Note your configuration. Write down the environment variables and volume mounts of each Zabbix container before you change anything.

3. Change the image tags in your docker-compose.yml from 7.0 to 8.0. For a PostgreSQL setup, the official images are zabbix/zabbix-server-pgsql, zabbix/zabbix-web-nginx-pgsql and zabbix/zabbix-agent2, all with an ubuntu-8.0-latest or alpine-8.0-latest tag.

4. Start the server and watch the database upgrade:

docker compose pull
docker compose up -d
docker compose logs -f zabbix-server

Use your server's service name if it isn't zabbix-server.

Zabbix warns that depending on the database size, this step may take a long time. A large history table can keep you busy for a while, so schedule it outside working hours. Don't restart the container halfway through.

5. Upgrade proxies next, then agents. A 7.0 proxy still collects data and runs scripts with an 8.0 server, but it can't receive configuration updates, so new items won't reach it until you upgrade. Agents and agent 2 from older versions keep working, so you can update them gradually.

Doing It on Elestio

Zabbix on Elestio starts at $16/month for the VM, with automated backups included. The safe order is the same as above: check which database version your stack runs, take a backup, then upgrade.

Use the Clone button in your dashboard to rehearse on a copy first, especially if your history is large. That way you find out how long the database upgrade takes before it matters. Or let Elestio AI DevOps handle it: it takes a backup before touching anything, and you can watch every step.

Troubleshooting

The server stops at startup with a database version error. Your database is older than 8.0 supports. Upgrade the database first, then start Zabbix 8.0 again.

The upgrade seems stuck. It's probably still working through your history tables. Check docker compose logs before assuming anything is wrong.

Webhooks or HTTP templates fail after the upgrade. That's the new TLS verification. Fix the certificate on the remote side, or set {$HTTP.TLS.VERIFY} deliberately for that template.

An integration gets permission errors from the API. Check its role under Users > User roles, since API access rules changed.

New items never show up on some hosts. Those hosts sit behind a proxy that's still on 7.0. Upgrade the proxy.

Thanks for reading ❤️ See you in the next one 👋