Managed servers

Provision game servers on your own Hetzner account, straight from the dashboard.

Managed servers let you provision game servers without renting a box first. You connect a Hetzner Cloud account, pick a region and a size, and HiveScale creates the server, installs the SDK, and joins it to your network. To the rest of the platform a managed server is just a server: it registers on its first heartbeat, joins matchmaking, and carries player data like any box you run yourself.

Preview. Regions are limited and per-network spend reporting is still on the roadmap.

Bring your own Hetzner account

The server lives in your own Hetzner project, not ours. You connect your account once with a Hetzner Cloud API token, and from then on every managed server is created under your account. That means:

• Root access is yours. SSH in, take snapshots, resize, or rebuild the box exactly as you would a server you rented by hand.
• Billing stays with Hetzner. The VPS appears on your Hetzner invoice. There is no HiveScale hosting markup, because we are not the ones hosting it.
• We only create and connect. HiveScale provisions the box, wires the SDK to your network, and tears it down when you ask. We never touch the rest of your account.

Hetzner is the first supported provider. The same bring-your-own-account model is planned for more clouds, including OVH and AWS. See the roadmap to follow along or vote it up.

Connect your account

1. In the dashboard, open Network settings -> Cloud and paste a Hetzner Cloud API token. A read/write token scoped to a dedicated project is recommended.
2. We validate the token and list the regions available to your account.
3. The connection is stored against your network and reused for every managed server you create.

Provision a server

1. On the network’s Servers board, choose Add server -> Managed.
2. Pick a region and a server type. We suggest a size from the server’s expected player count, which you can override.
3. Confirm. HiveScale creates the VPS in your Hetzner project, boots a pre-warmed image with the SDK already pointed at your network, and the server registers on its first heartbeat, usually within a couple of minutes.

The new server shows up in your activity feed before the dashboard finishes its spinner. From there it behaves like any other box: see Server registry for presence and transfers.

Updates land in place

A managed server keeps its Hive plugin current on its own. An agent on the box polls the hub for a newer plugin bundle for its server type, and when one is published it downloads it, swaps it in, and restarts the game container - no re-provision, no rebuilding the VM. The agent updates itself the same way. So shipping a plugin fix to your managed fleet is a publish on our side, not a box-by-box redeploy on yours.

Verify what’s deployed

Because a restart doesn’t necessarily re-pull the bundle, every Hive plugin carries a build hash - a short fingerprint of the exact jar it’s running. Run /hiveversion on any server to print it alongside the server’s identity:

Hive plugin build a1b2c3d4e5f6 | server=skywars-3 (skywars)

The hash is also logged at startup. It matches the fingerprint reported when the bundle was built, so you can confirm a server is actually running the build you think it is - handy after an update rolls out across the fleet.

What stays yours

Still in preview

This is shipped narrow and honest rather than wide and vague. Today that means a limited region list and no per-network spend reporting yet. For the background on why it works this way, read Managed servers, in preview.