Experience program

The experience program sends the version and how many people use Zeabur each day, so we know how many installations are in use and what to fix first. The installer joins by default, and you can uncheck the box on its review page. With Helm, Zeabur stays out until you turn it on.

What is sent

Zeabur sends one event the first time each person uses it in a UTC day, and the installer sends one event when an install starts, finishes or fails. Each event carries a random installation ID, the properties below and nothing else. The installer makes the ID once, or you make it with uuidgen; nothing about your machine goes into it. The data is kept for 13 months.

Event	Sent by	When
zeabur_active	Zeabur	The first time each person uses Zeabur's web interface in a UTC day
install_started	Installer	apply begins
install_finished	Installer	apply succeeds
install_failed	Installer	apply stops

Property	Events	Values
zeabur_version	zeabur_active	Zeabur's version, such as 0.1.1
day	zeabur_active	The UTC date, such as 2026-10-30
person	zeabur_active	32 hexadecimal digits that tell people apart within one installation and one day
mode	zeabur_active	in-cluster
installer_version	the installer's events	The installer's version
profile	the installer's events	single-node, multi-node or personal
distribution	the installer's events	k3s, rke2 or kube-solo
step	install_failed	Where it stopped: plan, preflight, node-prep, cluster, cluster-setup, components, identity, zeabur or record
error	install_failed	config, plan, io, command, download, digest, parse or other; never a message
$process_person_profile	all	Always false: no person profile is made
$geoip_disable	all	Always true: no location is looked up

The event doesn't say who the person is. person is a keyed hash of the user name and the day. The key is derived from Zeabur's plan key, which stays in the cluster's Secret and is never sent, so we can't work out the user name from it. The same person gets the same person all day, even after Zeabur restarts, and a different one the next day, so their days can't be linked.

Events go to PostHog through oss-nori.zeabur.com over HTTPS, one try with a short timeout. A failed request isn't retried and doesn't affect Zeabur or the install. PostHog doesn't keep IP addresses.

What is never sent

Domains, host names, IP addresses, Git URLs, image or service names, project names, emails, user names, logs, and the contents of your cluster.

Turn it off

Any one of these is enough, and DO_NOT_TRACK wins over all the others.

• Set DO_NOT_TRACK=1 in the environment of the installer or of Zeabur. Any value but empty or 0 counts.
• In the installer, uncheck the box on the review page, run zeabur-installer --no-telemetry apply (or --no-telemetry gui), or set telemetry: false in /etc/zeabur-installer/config.yaml.
• With Helm, keep telemetry.enabled=false, the default. The chart refuses telemetry.enabled=true without an ID.

To join with Helm, pass in a new ID:

helm upgrade <release> oci://ghcr.io/zeabur-oss/charts/zeabur --reuse-values \
  --set telemetry.enabled=true \
  --set telemetry.installationId=$(uuidgen | tr 'A-Z' 'a-z')

The installer keeps its ID in /etc/zeabur-installer/installation-id (mode 0600) and gives it to Zeabur's chart.

See what would be sent

Set ZEABUR_TELEMETRY=debug and Zeabur or the installer prints the exact request body instead of sending it. An install in debug mode leaves Zeabur out of the program. For Zeabur, the line is in its log:

kubectl -n zeabur set env deployment/zeabur ZEABUR_TELEMETRY=debug
kubectl -n zeabur logs deployment/zeabur | grep telemetry

ZEABUR_TELEMETRY=off turns it off like DO_NOT_TRACK does.

Update check

Zeabur and zeaburctl tell you when a newer version is out and how to upgrade. Nothing upgrades on its own. This check is separate from the experience program and on by default.

What is checked. Both read https://api.github.com/repos/zeabur-oss/zeabur/releases and leave out drafts. They leave out pre-releases too, unless you run one. If the newest of the rest is newer than yours, you see its version, a link to its release notes and how to upgrade. If any newer release that is not a pre-release has a ### Security section in its notes, you see that your version has known security problems, with links to those releases.

Where it runs.

• The cluster page always shows Zeabur v<version>. The Zeabur server asks GitHub at most once an hour, however many people open Zeabur, and the page reads its answer each time it opens and every hour while it stays open. The server keeps the last answer: if GitHub can't be reached, that answer stays and the server tries again a minute later, or after GitHub's reset when GitHub refuses. Browsers make no request to GitHub. Settings › About shows the version too, and How to upgrade opens the steps for how Zeabur was installed, with zeabur-installer, Helm, Argo CD or Flux. See Upgrade Zeabur. Under zeaburctl ui, the page shows zeaburctl's own version and how to update it.
• zeaburctl checks each time a command runs. The check runs beside the command. When the command ends, zeaburctl waits at most a second more for the answer. When a newer version is out, it prints one line to stderr. It keeps nothing on disk. It doesn't check when stderr isn't a terminal or when CI is set.
• Without a token, GitHub answers 60 requests an hour from one IP address, shared by everyone behind it. When that's used up, zeaburctl says so instead. Set GH_TOKEN or GITHUB_TOKEN to a GitHub token, the same variables gh reads, and zeaburctl sends it so the requests count against your own limit. A fine-grained token with no permissions is enough.

What is sent. A plain request to GitHub with no ID or cookie, and no token unless you set one for zeaburctl. GitHub sees the IP address it comes from. The Zeabur server sends zeabur as its user agent, and zeaburctl sends zeaburctl/<version>.

Turn it off. Any one of these is enough. Once it is off, the Zeabur server makes no request to GitHub.

• In the installer, uncheck the box on the review page or set updateCheck: false in /etc/zeabur-installer/config.yaml. Running apply with DO_NOT_TRACK=1 or NO_UPDATE_NOTIFIER set turns it off too.
• With Helm, set updateCheck.enabled=false. The cluster page then only shows the version.
• Set DO_NOT_TRACK=1 in Zeabur's environment, or in yours for zeaburctl. It turns off the experience program too.
• Set NO_UPDATE_NOTIFIER to any value in your environment for zeaburctl, including zeaburctl ui. It turns off only the update check.