HubPilot Core

Start servers when players need them

HubPilot Core lets players request an offline Minecraft server from your hub, wait while it starts, and join once it is ready. When everyone leaves, HubPilot can shut it down according to your settings.

Core runs on your Velocity proxy and handles the requests, server discovery, provider connections, and routing behind HubPilot’s in-game interface.

For example, your survival server can stay offline while nobody is playing. A player selects it from the hub’s Navigator, Core asks your hosting provider to start it, and HubPilot handles the wait and transfer.

What Core handles

• On-demand startup: request an offline backend and connect players when it becomes available.
• Connection retries: retry transfers when a server needs more time before accepting players.
• Automatic shutdown: stop unused servers after a configured idle period, or stop a server started for a request that never completed.
• Server discovery: find servers through supported provider integrations.
• Status and telemetry: supply the hub interface with server state, player counts, and connection information.
• Network administration: handle setup, staff roles, server settings, and the main /hp commands.
• Hub routing: provide /hub and /lobby commands for returning players to the hub.

You can also mark an individual server Always-On to disable automatic shutdown while keeping provider startup and manual stop available.

Hosting providers

Core connects to the system that runs your servers:

Provider	Use
Crafty Controller	Discover and control servers through Crafty’s API.
Pterodactyl	Control servers through the panel’s API.
Generic HTTP	Connect to a custom service using configured HTTP requests.
Always-On	Route players to servers whose processes are managed elsewhere.

Crafty Controller has live network testing behind it. Pterodactyl and Generic HTTP have controlled test coverage, but have not received the same live testing.

The Always-On provider is different from the per-server Always-On setting: it does not start or stop the server.

Installation

Install Core only on your Velocity proxy. Put its JAR in Velocity’s plugins folder.

For the normal in-game setup, install these on your Paper hub:

• HubPilot Hub: the Navigator, setup flow, and administration menus.
• HubPilot Link: communication between the hub and Core.
• HubPilot Interact, optional: entity, sign, portal, and supported mannequin interactions.

Backend game servers do not need HubPilot JARs for normal requests, routing, or provider power control.

Restart Velocity and the hub, then join the hub as an operator and run:

/hp claimowner
/hp setup

Configure your provider, make sure Velocity can reach your backend addresses, and keep a hub online so players have somewhere to wait.

Core and Hub must use matching HubPilot versions. Check the release notes before mixing Link or Interact versions.

Compatibility

HubPilot works alongside ViaVersion and ViaBackwards. Those plugins handle protocol translation; HubPilot handles requests and routing. Strict HubPilot version rules can still block a transfer.

Modded servers may require a matching client version, loader, and modpack. They also need forwarding support appropriate to their server software. For Fabric backends using Velocity modern forwarding, this normally means FabricProxy-Lite with a compatible build and the correct Velocity forwarding secret.

LuckPerms is optional for granting HubPilot permissions on the hub. HubPilot also has its own staff roles.

Documentation and support

• Installation guide
• Provider setup
• Commands
• Permissions and roles
• Report a problem

For bug reports, include your Velocity version, HubPilot component versions, provider, and relevant console errors. Remove passwords, API tokens, and forwarding secrets before sharing logs.