What the agent can do — and what it never can

The Tickwise agent runs inside your server and reads its logs, and those logs contain your players' data too. So the product is built to need as little trust in the Tickwise cloud as possible: the agent cannot run commands, secrets never leave the server, and diagnoses come from a signed signature pack.

This page explains in plain terms what the agent can and cannot do, what goes to the cloud and what happens if the cloud is compromised.

0

commands the agent can run on your server

Ed25519

signature on the signature pack; the key is kept offline, not on Tickwise servers

7 days

maximum retention of log excerpts in the cloud

Russia

where cloud data is stored, backups included

The agent does not run commands

The agent contains no code that could start a shell, run a Minecraft console command or load code on the cloud's instruction. This is a design decision, not a setting: the build fails if ProcessBuilder, Runtime.exec, dispatchCommand or URLClassLoader appear in the agent or cloud code.

What this means for you:

• in the closed beta the agent is read-only, with no automatic fixes;
• the Telegram bot manages notifications and incidents, not your servers;
• the agent does not update itself: you install a new version by replacing the jar in plugins/.

What goes to the cloud

Nothing is sent before you run tickwise link. After linking, the agent sends:

• per-minute metrics: TPS, MSPT, memory, GC, CPU, disk, player count;
• platform, Java and plugin versions;
• values of config keys from a public allowlist only; keys that look like secrets (pass, secret, token, key and so on) are sent only as “present / length”;
• errors: fingerprint, template and counter;
• sanitised log excerpts for new errors with no known signature — up to 16 KiB each, no more than 20 an hour by default.

Never sent: chat and private messages, player command arguments, passwords and tokens, the Velocity forwarding secret (the agent reads it only to redact it from logs), and IP addresses, UUIDs and player names in the clear. IPs, UUIDs and names are replaced with pseudonyms based on a salt that stays on your server. The sanitiser runs on the server before sending and again in the cloud.

You can narrow what is sent in config.yml: privacy.send_log_excerpts, privacy.send_player_counts, privacy.send_jar_hashes (off by default), and privacy.ip_mode: drop to remove IPs instead of hashing them.

An honest limitation: a secret shorter than 32 characters, in a non-standard format and without a hint such as password=, may slip past the sanitiser. That is why log excerpts are sent sparingly and kept briefly.

The signed signature pack

The agent recognises known problems itself, using a signature pack. The pack is signed with an Ed25519 key kept offline by the maintainer — not on cloud servers and not in CI. The agent checks the signature and hash of every downloaded pack. If the check fails, the pack is rejected, the agent falls back to the previous pack or the one bundled in the jar, and reports the failure to the cloud.

There is no AI diagnosis in the beta: causes come only from verified signatures and cloud rules. Log content is treated as untrusted: regular expressions run on RE2/J in linear time, and text from logs is displayed as plain text.

Linking and tokens

• The link code is single-use and valid for 15 minutes. Even a code the bot has accepted does nothing without tickwise link confirm in your console, and before that the bot shows the agent's name, version and masked IP.
• The tickwise.owner permission needed to link is not granted automatically, not even to operators. In a Telegram group, only chat administrators can link servers and change settings.
• The agent token lives in credentials.json on the server; the cloud stores only its SHA-256 hash. The token allows sending one server's data and nothing else.
• If the token is stolen, an attacker can send junk data for that one server. Press “🔌 Отвязать” (Unlink) on the server card in the bot and the token is revoked.
• Every cloud data query is limited to your chat's organisation: other people's servers and incidents cannot be opened through the bot.

If the Tickwise cloud is compromised

We assume this can happen and design so that the damage stays limited.

Where data is stored and for how long

The cloud and all databases, backups included, are located in Russia. The pseudonymisation salt never leaves your server, so cloud data cannot be used to recover a player's IP or name, or to match a player across different servers.

The cloud does not store your servers' secrets at all, because it never receives them.

What Tickwise does not protect against

The agent runs in the same JVM as your other plugins, and Bukkit does not isolate plugins from each other. A malicious plugin on your server can read the agent's token — and can do anything to the server without Tickwise anyway. We have no protection against a malicious plugin that is already installed. Only install plugins from sources you trust.

Check it yourself

• The agent is open source: everything on this page can be verified in the code.
• tickwise privacy in the console shows what is sent with the current settings and what went out in the last batch.
• tickwise pause [min] pauses sending, tickwise unlink stops it entirely. Local diagnostics keep working either way.

More about data is on the Privacy page, setup is in the installation guide, and the bot is covered on the Telegram bot page.