Skip to main content
Everything you edit lives in one folder on the proxy:
Anything in _shared/ lands in plugins/Nexo/ on every backend. Anything in servers/<name>/ lands only on that backend and overrides the shared copy of the same file. The server name is whatever you called it in your proxy’s server list: velocity.toml, or BungeeCord’s config.yml.

​
Making one server different

Drop the file you want to change into servers/<name>/, matching the path it has in _shared/. Only that one file is overridden, everything else still comes from _shared/.
Overriding files that change what the pack contains means that server builds a different pack, so players re-download when they switch to it. Overriding configuration that only affects behaviour costs nothing. See plugin packs for the common case of different HUDs per server.
This is for a difference you mean to keep. To try a change on one server before the rest of the network gets it, use /nexohub stage instead, which holds every other backend on the files they already have.

​
Groups

If four servers want the same override, putting the same file in four servers/ folders means changing it in four places. A group is the layer in between. Name the group and list its backends in the proxy’s config.yml:
Then put the files in nexo-data/groups/survival/, laid out exactly as _shared/ is. The order is _shared/, then the groups a server belongs to, then servers/<name>/. Each wins over the one before it, so a one-off override still beats its group:
A server can be in more than one group. When it is, the groups apply in the order config.yml lists them, so the last one named wins. The same three layers also carry settings, not just files. Anything you write beside servers: in a group applies to those backends:
The plain list above is the shorthand for a group that layers files only, and it keeps working. /nexohub status names the layers each server actually received, which is the quickest way to check a group is doing what you think:
Editing groups: is a config change, so follow it with /nexohub reload. A group that lists no backends is ignored with a warning, and /nexohub doctor points out group members that are not in your proxy’s server list.

​
Sharing other plugins’ configs

Plugins other than Nexo can be managed the same way. Put them under _plugins/:
Per-server and per-group overrides work the same:
A file you put here wins over anything a backend sent up for itself. See plugin packs for which plugins need the same sources everywhere.

​
A pack you downloaded

A pack you bought or downloaded, from MCModels or anywhere else, goes in _shared/pack/external_packs/, either unpacked into a folder of its own or left as the zip you downloaded:
Nexo imports both. The zip is usually less work, and it has one practical advantage: the files inside it are never parsed, where an unpacked folder has every .json and .mcmeta in it checked before anything is pushed, and one malformed file in a bought pack blocks the whole push until you fix it. Unpack it if you want to edit what is inside, and keep the zip if you do not. It lands in plugins/Nexo/pack/external_packs/ on every backend and Nexo folds it into the pack. Deleting the folder on the proxy removes it from every backend on the next push, and so does deleting a single file inside it, as long as that backend still has prune on.
This is the opposite of what BetterHUD and friends write into external_packs/ on every boot, as a folder or as a zip depending on their pack-type. Those are never yours to place or the hub’s to remove, and NexoHub tells them apart from your packs by reading where each plugin says it builds. See plugin packs.
Do not put a pack of your own directly into a backend’s plugins/Nexo/pack/external_packs/. What happens next depends on how you put it there, and neither answer is the one you want:
  • As a zip, it stays on that one backend. Nothing carries it to the others and /nexohub adopt does not take it either, so it reaches the pack players download only while that backend’s pack is the one the network serves.
  • Unpacked into a folder, it is published to the whole network as that backend’s own output, because a folder there is how the plugins that generate directories are collected and nothing distinguishes yours from theirs. Your copy is left where it is and the backend says so.
Either way the backend names it on its console rather than leaving you to notice. The hub is the place for a pack every server should have.

​
Settings that stay local

Some settings belong to the individual server and must survive a push. By default NexoHub protects Nexo’s pack server settings, which is what points that backend at the hub in the first place:
Paths start with the plugin folder name. Add more entries if you have per-server values that should never be overwritten.

​
Files you never want pushed

An entry ending in / excludes a whole folder. You will rarely need this. Anything your other plugins generate at runtime is already safe, and so is a PackSquash executable in pack/packsquash/. Reach for exclude when a file NexoHub does manage has to survive a push anyway, or when an outdated copy of generated content has ended up in nexo-data/ by accident, for example after copying a whole plugins/Nexo/ folder up to the proxy.

​
What gets skipped automatically

Hidden files, editor backups ending in ~, and anything over 64 MB are never sent. Partial uploads ending in .tmp or .swp do not trigger a reload, so uploading a large folder over SFTP results in one reload after it finishes rather than one per file.

​
Before anything is sent

Every .yml, .yaml, .json and .mcmeta is checked first, and if any of them have a mistake in them, nothing is sent. A copy of your files is kept every time they change, so an edit can be undone. See not breaking your network.