How to set up a Minecraft server network (Velocity proxy)

A server network is several Minecraft servers behind one entry point — a proxy. Players connect to a single address, land on a hub, and hop between your servers (survival, creative, minigames) in one session without disconnecting. On truetick the proxy is Velocity, and the servers behind it are called backends.

The proxy stays up 24/7 so the network is always reachable. Backends can be metered and scale to zero — sleeping when empty — which is where the cost savings live. For your first setup we recommend keeping backends on Flat too, so a join always lands on a server that's already up; once your network is running you can switch backends to Metered to let them sleep between sessions.

This guide is the exact flow, in order. It takes a few minutes the first time. Wiring the proxy to its backends — the Velocity config, the shared secret, matching the auth mode on both sides — is written for you. You don't open a config file for any of it; the panel's Network tab is where you act, and it tells you what it knows about whether that wiring has actually reached a running proxy yet.

Before you start — two things that will save you a retry:

• Match your Minecraft version to the backend. Velocity does not translate versions. A 1.21.11 backend needs a 1.21.11 client (or ViaVersion installed on the proxy).
• A backend and its own proxy must be on the same node. Attach won't let you mix them. A network itself can span multiple regions — see Multi-region networks below — but each backend is only ever reachable through the one proxy on its own node.

Step 1: create the proxy

New server → in Server type, pick the Proxy card (Velocity — link servers into a network). Give it a name (this becomes your network's public address, e.g. mynet.truetick.gg), and choose the Flat plan — a proxy should stay up so the network is always reachable; on Metered it would sleep when empty and drop the whole network.

Create it. It provisions Velocity and reaches running. Its dashboard shows RAM/CPU and a note that a proxy has no world tick — that's expected, proxies route players, they don't run a world.

Step 2: create your backend server(s)

New server → Plugins, core Paper or Purpur → same region/node as the proxy. Paper/Purpur specifically: that's the only core family that reads the Velocity forwarding config the platform writes for you (Vanilla has no forwarding mechanism at all; Fabric/Forge/NeoForge keep it in a separate mod we don't manage). Create as many backends as you want; each is a normal server you configure however you like.

Step 3: attach the backends

Open the proxy → Network tab → Create network. Then under Attach a backend, pick one of your servers, tick private (so it can only be joined through the proxy, never directly), and Attach.

Each attached backend also shows a proxy address like 172.17.0.1:32300 on this tab — that's the address the proxy dials internally to reach it. It's shown for your own reference, not something you need to copy anywhere: the platform wires it into the proxy's config itself.

Attaching records the wiring on our side immediately: the platform now knows the backend belongs to this network, at that address, under this auth mode. Nothing is written into a server's files at that moment — each server renders its own config when it next starts, which is why what you do next depends on whether the backend is running:

• Already running (typically a Flat backend you just created): restart the backend once, so it starts with the config (Step 5 below explains why).
• Asleep (a Metered backend, or one you haven't started yet): nothing to do — the config is written the next time it boots, which happens automatically the moment a player joins it.

The proxy itself works the same way: attaching a backend updates what the proxy should have, and the Network tab tells you whether that's reached the proxy's own running process yet — see Applying changes to a running proxy below.

Step 4: choose the network's authentication mode

Still on the Network tab: Authentication mode is Premium by default (real, Mojang-verified accounts) or Offline (cracked/self-issued identities) — one switch for the whole network, since PaperMC requires the proxy and every backend to agree on this exact value. You don't set it per-server; the platform keeps both sides in sync.

Leave it on Premium unless you specifically want to allow non-premium clients. Don't change it on a network that's already been played on: Premium and Offline derive a different player UUID from the same username, so switching later doesn't delete anyone's inventory or homes — it makes the game look for them under a UUID that no longer matches, so they appear empty. The panel's confirmation for this spells out that consequence and asks you to type the proxy's hostname before it lets you switch.

A mode change is a restart on both sides. The proxy and every backend have to carry the same value — that's PaperMC's rule, not ours — and each one only picks up the new mode when it next starts. The confirmation counts the backends running at that moment and says so; restart those as well as the proxies, or a player landing on a backend that still has the old mode is kicked at login.

Offline mode also doesn't add authentication on its own — if you allow non-premium clients, whatever keeps impostors from joining as someone else's username (an auth plugin, typically) is on you to install and configure; we don't ship or manage one.

Step 5: restart what's stale

Two restarts may be needed before the network actually routes players, and this flow makes both of them the normal case the first time through — not a rare edge you'll usually skip:

• Any backend you attached in Step 3 that was already running. Restart it now — the proxy's Network tab flags it on its own row ("Network configuration changed after this backend last started") with a Restart button, and Settings → Restart on the backend itself does the same thing. A backend that was asleep when you attached it doesn't need this: its config gets written the next time it wakes, and the tab says so instead of offering a button.
• The proxy itself. It reached running back in Step 1, before the network existed — and a proxy's first start is the one that downloads its Velocity config file, so at that moment there was no file for us to write the network wiring into. The wiring goes in on the start after that. Open the proxy's Network tab: it will say "This proxy has only started once, and its first start is the one that fetches its config file — the network wiring is written on the start after that," with a Restart this proxy button right there. Click it. (Once the proxy has more than one start behind it, later changes to the network show up in the same spot as "Network configuration changed after this proxy last started.") See Applying changes to a running proxy below for why the proxy can't just pick this up on its own.

Skip a restart the tab isn't asking for, but expect to need both the first time you follow this guide in order.

Step 6: join

Connect a client — matching a backend's version — to the proxy's address (mynet.truetick.gg). With a backend on Flat and up, you land on it. (If a backend is Metered and asleep, joining wakes it, then asks you to reconnect once it's ready.)

Applying changes to a running proxy

The proxy re-reads its wiring the next time its own process starts — same as a backend. Because a proxy is meant to stay up on Flat, that might not be for a while, so the Network tab tells you, per region, what it actually knows:

• When that proxy last started successfully, or "Not started yet" if it never has.
• Whether it has only ever started once. Your wiring is spliced into the velocity.toml the image downloads on that first start — we never write a config file of our own, because a file we invented would stop Velocity from booting at all. So a proxy with a single start behind it has not had the wiring written yet, whatever else changed and whenever: the tab says "This proxy has only started once, and its first start is the one that fetches its config file — the network wiring is written on the start after that" and gives you the Restart this proxy button.
• Whether the network's configuration has changed since — membership, auth mode, a backend's address. If so, it says so in plain words ("Network configuration changed after this proxy last started") with a Restart this proxy button right there.
• The reason its last start failed, if it did, with the same diagnosis the server's own page shows, and a Retry start button.
• The same thing for each backend in that region, on the backend's own row: a backend that hasn't started since the network's config changed says so, with a Restart button while it's running, or the fact that its config is written on its next start while it's asleep. Both sides of a pair need it, so both sides are shown.

There's no "applied" checkmark beyond that, because there's nothing on our side that confirms a running proxy actually picked up a given config — we show you what we know (when it last started, whether the desired config has moved since), not a guess dressed up as a fact. If a region says it couldn't be loaded, that's exactly what it means: we couldn't read that proxy just then, and nothing on that card is a statement about it.

Troubleshooting

• A backend you attached won't start, with an error naming its server type. Only Paper and Purpur backends can carry the forwarding config a network needs — a Vanilla, Fabric, Forge, or NeoForge backend can't, and the platform refuses to start it in that state rather than start it half-configured. Detach it, or recreate it as Paper/Purpur.
• You just attached or changed something and nothing looks different. A backend that was already running needs a restart (Step 5). A proxy needs one too, once the Network tab tells you it's stale (see Applying changes to a running proxy above) — restart it from there.
• Kicked with "Backend server is online-mode!" — the backend is still doing its own authentication, which a proxied backend must not do. It hasn't started since it joined the network: the platform writes that setting on a server's next start, not at the moment you attach it. Restart the backend (Step 5). The Network tab flags this backend on its own row when it's the cause.
• Kicked with "This server requires you to connect with Velocity" — the reverse: the backend has the network's forwarding config, and the connection didn't come through the proxy. Either the join went to a public backend's own address instead of the proxy's — once it's wired into a network, that's what its own address does now — or the backend was detached from the network and is still running with the config it started with, since a running server keeps the config it booted with. Join through the proxy's address.
• "You are logging in too fast" — you joined while the backend was still starting. Put the backend on Flat so it stays up, wait for it to finish booting, and join once.
• Kicked with a version message, or the client won't connect — your client version doesn't match the backend. Use the same version, or install ViaVersion on the proxy.
• A player from before an auth-mode switch has an empty inventory. That's the UUID change described in Step 4 — the data isn't gone, it's filed under their old identity. This is exactly why switching mode on a live network needs the explicit confirmation it asks for.

Multi-region networks

A network isn't limited to one region. It can have one proxy per node — add a proxy in a second region and it becomes a new part of the same network, with its own backends attached to it the same way you attached backends to the first proxy above.

• Add a region from the proxy's Network tab → Add a region: pick one of your own Velocity servers on the Flat plan that isn't already in a network. Each region gets its own proxy and its own backends — the wiring, secret, and auth mode are handled the same automatic way as a single-region network, per region.
• Moving a player between regions is a normal Minecraft transfer: your proxy sends the client a transfer packet and it reconnects to the other region's proxy address, same as if the player had typed in a different server address themselves. This needs a 1.20.5+ client — older clients don't understand the transfer packet, so they can't be moved between regions this way.
• Player data does not travel between regions. Inventory, economy balances, and permissions stay in the region they were created in — there's no shared database syncing them across regions today. You can set this up yourself with a plugin and your own database — the platform doesn't block it, we just don't run it for you.

Good to know

• One network per proxy. A Velocity server can anchor (or join, via Add a region) at most one network at a time; spin up another proxy for a genuinely separate network.
• Private vs public backends. Private (recommended) means the backend only resolves through the proxy — nobody can join it directly. Untick private if you want a backend to also be joinable at its own address.
• Keep every proxy on Flat. Proxies are the always-on front door for their region; backends are where scale-to-zero saves you money.
• A backend's proxy is always on its own node. Attach won't let you mix a backend with a proxy on a different node — see Multi-region networks above for how to serve more than one region.