Zerta

Open Source XMPP

Zerta in Go.

XMPP server in Go, build v0.7.0. Tested with the compliance suite at compliance.conversations.im. Apache 2.0. For teams that want federation, mobile clients, and operational control without adopting an exotic runtime stack.

  • Compliance suite: compliance.conversations.im
  • Build v0.7.0
  • Apache 2.0
  • Single Go binary

Trust

Facts, not platform theatre.

Zerta is a hard fork of Jackal and continues as an independent Apache 2.0 project. This page stays with claims that are backed by the repository.

v0.7.0

Compliance tester

Checked with the suite at compliance.conversations.im, full report there.

2.0

Apache licensed

A permissive open-source license before the first prototype turns into a licensing meeting.

Go

Readable operations stack

Builds, debugging, and deployment fit normal SRE and Go toolchains.

SASL2

Modern authentication

SASL2, Bind2, and FAST for up-to-date client authentication.

Why Zerta

For operators who want to read the stack.

Zerta does not compete with age or scale promises. The advantage is controllable technology: Go, a clear license, familiar monitoring, and infrastructure backends you can choose.

Go instead of a specialist runtime

A codebase you can build, inspect, and debug with standard Go tooling.

Apache 2.0 instead of license friction

Suitable for extensions, SaaS operation, and product integration without early copyleft uncertainty.

Prometheus and pprof

No custom dashboard island. Metrics and profiles flow into the stack operations teams already use.

Five cluster backends

Redis, PostgreSQL, NATS, Raft, or etcd: the architecture follows your infrastructure, not the other way around.

Features

The current scope, grouped by operations view.

The feature list is intentionally technical. No customer logos, no scale numbers, no performance promises without measurement.

Auth & security

SASL2, Bind2, FAST, Channel Binding, OMEMO, Privacy Lists, Guardian, and anti-spam.

Messaging & sync

MAM, Message Carbons, Stream Management, CSI, Offline Messages, and roster.

Collaboration

Multi-User Chat, persistent rooms, moderation, MUC RTBL, HTTP Upload, TURN/STUN credentials (XEP-0215, external server), and push.

Operations

PostgreSQL, MySQL, BoltDB, Redis caching, Admin API, zertactl, Prometheus, health checks, and pprof.

Quick start

One binary. One config. Start.

The standard path is plain: clone the repository, install the binary, configure YAML, start the server. Docker and Helm are available in the project as well.

git clone https://git.uuxo.net/UUXO/zerta.git
cd zerta
make install installctl
zerta --config=config.yaml

# Create a user
zertactl user add username:password

# Docker
docker-compose -f dockerfiles/docker-compose.yml up

Documentation

From setup to operations.

A hosted docs structure is the next step. For now, the most important paths lead directly into the repository.

Installation & operations

Build, systemd, nginx, TLS, monitoring, security, and clustering in the Admin Guide.

Configuration

Complete YAML reference for listeners, storage, auth, TLS, modules, and clustering.

Compliance

Documented path to the compliance suite on compliance.conversations.im with the enabled module set.

FAQ

Questions before you decide.

Short answers, each backed by the repository. Where documentation is still missing, this page says so.

Setup

What do I need for a production Zerta server?

MySQL 8+ or PostgreSQL 12+ as the database, a valid TLS certificate (e.g. Let's Encrypt) and nginx in front for TLS termination, WebSocket and BOSH. HTTP Upload (XEP-0363) is built in. For TURN/STUN, Zerta generates time-limited credentials (XEP-0215); it does not ship its own TURN server, so an external one is required. The full list including the build toolchain is in the Admin Guide under “Requirements”.

HTTP Upload: built-in XEP-0363 module. For HMAC, dedup, or your own storage backend, optionally hmac-file-server.

Can I try Zerta without an external database?

Yes. BoltDB is embedded and needs no database server — but only for a single node, without replication and without clustering. For production use, MySQL or PostgreSQL are the intended backends. Zerta creates its schema on startup, so no manual import is required.

Operations

How do I run Zerta on multiple nodes?

Clustering runs through a shared KV store (cluster.type: kv). Five backends are implemented in code: Redis, PostgreSQL, NATS, Raft and etcd. The Admin Guide documents all five. BoltDB does not support clustering.

What monitoring interfaces are available?

The built-in HTTP server exposes Prometheus metrics at /metrics (OpenMetrics enabled) and Go profiling at /debug/pprof/. A Grafana dashboard ships in the repository under monitoring/. Storage metrics are enabled via storage.repository.type: measured. A dedicated monitoring section in the documentation has not been published yet.

How do I protect the server against brute force and spam?

Guardian limits failed logins per C2S listener (max_auth_failures), bans addresses for a configurable duration (ban_duration) and throttles new connections (connect_rate_limit). For messages there is the antispam module with a per-user rate limit, plus muc_rtbl for real-time block lists in rooms.

Are there guides for backup, restore and upgrades?

No. These operator guides are planned but not published. What is documented today: Zerta runs schema migrations automatically on startup. Backup and restore currently rely on the tooling of the database you run, plus the configuration and the upload directory. Anyone running Zerta in production has to define and test that procedure themselves for now.

Protocol

What does the compliance tester status mean?

Tested with the suite at compliance.conversations.im, last run on 2026-04-15 on 0ea1.net with the same result as uuxo.net. Currently running build v0.7.0 on uuxo.net. The full report is at compliance.conversations.im, no XEP catalog here.

What do SASL2, Bind2 and FAST give me?

SASL2 (XEP-0388) together with Bind2 (XEP-0386) handles login and resource bind in a single round trip, which cuts the number of round trips when a connection is established. FAST (XEP-0484) adds token authentication, complemented by channel binding (XEP-0440) and SCRAM hash upgrade (XEP-0480).

FAST tokens are issued as HT-SHA-256-NONE and are therefore not channel-bound. Treat them like a full access credential.

Migration

Can I migrate from ejabberd or Prosody to Zerta?

Yes, with the zerta-import tool. It reads an ejabberd or Prosody database (MySQL or PostgreSQL) and writes into the Zerta database: accounts, roster, vCards, archive (MAM), blocklist, MUC rooms and PubSub. With --dry-run it only counts and writes nothing. Passwords that cannot be carried over safely abort the import with a report instead of silently becoming unusable. There is also an export back to ejabberd or Prosody. A detailed migration guide is not published yet; details are in the operator guide in the repository (section “Migration of foreign servers”).

How does Zerta differ from Jackal?

Zerta is a fork of ortuman/jackal and is developed as an independent project under Apache 2.0. Current focus areas: compliance tester coverage, modern authentication (SASL2/Bind2/FAST), clustering via KV backends, plus Guardian and anti-spam.

Config file, binaries and environment prefix are Zerta's own (zerta.yml, ZERTA_*). A Jackal configuration therefore cannot be carried over unchecked.

Repository

The code is the proof.

Server, docs, example configs, Docker files, and Helm scripts live on git.uuxo.net. Managed hosting belongs separately on uuxo.net.

git.uuxo.net/UUXO/zerta