A live dev loop for Minecraft plugins (and the API behind it)

Every plugin developer knows this loop, because every host has forced them into it:

mvn package

Then: open the panel in a browser tab. Find the file manager. Drag the new jar over the old one, wait for the upload bar. Click into the console tab. Type restart, or find the restart button. Wait for the server to come back. Scroll the console for the stack trace you're hoping isn't there. Fix one line. Repeat.

None of that is hard, exactly — it's just slow, manual, and entirely disconnected from your editor. You built a jar in one second with your IDE and then spent the next thirty doing file management. Multiply that by the dozens of iterations a real feature takes and it's a meaningful chunk of a dev session spent context-switching into a browser instead of watching your code run.

We host Minecraft servers, and it bothered us enough that we built a CLI around fixing it.

The fix — truetick dev

TrueTick now ships @truetick/cli, and its centerpiece is a single command: truetick dev. Point it at your plugin, and every time you rebuild, it uploads the new jar and restarts the server automatically — no browser, no drag-and-drop. You can try it without installing anything first, straight through npx:

npx @truetick/cli servers list

Here's the whole loop, start to finish:

truetick login --key ttk_…
cd my-plugin
truetick init --create --name Dev --ram 4096 --type PAPER --yes
truetick dev

login saves your key locally so every later command is authenticated. init --create provisions a fresh Paper server sized for plugin dev and writes a truetick.toml in your project — the server ID, the build command, and the glob for your build artifact all live there, so nobody on the team has to remember the setup by hand. (--create actually creates a server, which is why the CLI insists on the explicit --yes.)

Then truetick dev takes over. It runs your build once, uploads the jar over per-server SFTP, restarts the server, and starts tailing the live log — all in your terminal. From there it watches your build output, and on every rebuild it repeats the cycle: upload, restart, tail. Save a file in your editor, run your build (or let a watcher run it for you), and the new behavior is live on a real server by the time you've alt-tabbed to check. Ctrl-C stops watching; the server itself doesn't move.

The part that matters for your wallet: the server init --create provisions is metered and scale-to-zero — you pay only while it's awake. You're billed only for the minutes it's actually running — not for the hours between your afternoon and evening dev sessions, not for the week you spend on something else entirely. When you're done, truetick down --yes deletes the dev server outright, so there's nothing quietly billing in the background after you've moved on.

The full walkthrough — including debounce behavior and how dev decides what counts as a rebuild — is in the deploy-a-plugin guide.

The rest of the surface

The CLI is the fastest way into a dev loop, but it's a thin client over the same public API that runs the dashboard — which means everything it does, you can also do from your own code, from an AI agent, or from raw HTTP.

The TypeScript SDK is the same primitives as the CLI, typed, for when you're scripting something more than a plugin reload — a deploy pipeline, a Discord bot that restarts a server on demand, a test harness that spins up a server, runs an integration suite against it, and tears it down.

npm i @truetick/sdk

import { TrueTickClient } from "@truetick/sdk";

const client = new TrueTickClient({ apiKey: "ttk_…" });

const servers = await client.servers.list();
const metrics = await client.servers.metrics(servers[0].id);
console.log(`${servers[0].hostname}: TPS ${metrics.tps}, ${metrics.players} players`);

The MCP server puts the same tool surface in front of an AI agent. Run npx -y @truetick/mcp from your Claude Desktop config with an API key in the environment, and you can ask Claude to list your servers, restart one, pull recent logs, or add a mod from Modrinth — in plain English, with the agent calling the real API underneath instead of guessing.

npx -y @truetick/mcp

The raw REST API is what both of the above actually call, and it's fully documented for anyone who wants to skip the wrapper. Every request needs only an x-api-key header:

curl -H "x-api-key: ttk_…" https://api.truetick.gg/v1/whoami

That single call is enough to confirm a key works and see which account it's bound to — no other setup required. From there, the full API reference covers servers, console, files, backups, and mods, plus which scope each endpoint needs.

All four surfaces — CLI, SDK, MCP, REST — are documented together at /developers and in the docs at docs.truetick.gg, if you want to see the full command and endpoint list in one place.

The honest part

We built TrueTick on a simple premise: show the real numbers, and don't let the platform do anything behind your back that you couldn't see or do yourself. That doesn't stop at the dashboard.

Every server exposes live TPS and MSPT through /metrics — the same never-oversold numbers you'd watch in the panel, available to client.servers.metrics() or a plain GET /v1/servers/{id}/metrics, no dashboard required. It's the same poll of the running server, the same staleness handling, the same honest-empty-state when a server is asleep. Nothing gets rounded up or smoothed over for the API consumer that wasn't already true for the browser.

API keys are scoped — a key with servers:read can't restart anything, a key without billing:read can't see your wallet — and the public reference doesn't expose a single admin endpoint. What the panel won't let you do, a key won't let you do either. There's no back channel.

That's the same idea that got TrueTick built in the first place: the metric is the contract. It just turns out a contract is more useful when it's also an API — something your build pipeline can read, your bot can act on, and your own tooling can hold us to, the same way a browser tab always could.

If you're building a plugin right now, the fastest way to feel the difference is to run the four commands under "The fix" above and watch your next mvn package show up on a live server without you ever opening a browser tab.