> ## Documentation Index > Fetch the complete documentation index at: https://nexohub.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Managing your files > Where everything lives on the proxy, and how to give one server different content. Everything you edit lives in one folder on the proxy: ``` plugins/nexohub/nexo-data/ ├── _shared/ goes to every backend │ ├── items/ │ ├── glyphs/ │ ├── recipes/ │ ├── pack/assets/ │ ├── pack/external_packs/ │ └── settings.yml ├── groups/ │ └── survival/ only the backends you list, wins over _shared │ └── items/ └── servers/ └── pvp/ only this backend, wins over both └── items/ ``` Anything in `_shared/` lands in `plugins/Nexo/` on every backend. Anything in `servers//` 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//`, matching the path it has in `_shared/`. Only that one file is overridden, everything else still comes from `_shared/`. ``` _shared/settings.yml most servers get this servers/pvp/settings.yml pvp gets this instead ``` 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](/guides/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`](/guides/commands#nexohub-stage-server) 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`: ```yaml theme={null} groups: survival: [smp, smp2, smp3] minigames: [bedwars, skywars] ``` 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//`. Each wins over the one before it, so a one-off override still beats its group: ``` _shared/settings.yml everything else groups/survival/settings.yml smp, smp2 and smp3 servers/smp2/settings.yml smp2, whatever its group says ``` 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](/reference/proxy-config#settings), not just files. Anything you write beside `servers:` in a group applies to those backends: ```yaml theme={null} groups: minigames: servers: [bedwars, skywars] poll_seconds: 30 ``` 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: ``` smp2 [4p] bundle 5d935602 +groups/survival+servers/smp2 in sync ``` 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/`: ``` _shared/ ├── items/ goes to plugins/Nexo/items/ └── _plugins/ ├── BetterModel/ goes to plugins/BetterModel/ └── CustomNameplates/ goes to plugins/CustomNameplates/ ``` Per-server and per-group overrides work the same: ``` groups/survival/_plugins/BetterModel/models/boss.bbmodel servers/pvp/_plugins/BetterModel/models/boss.bbmodel ``` A file you put here wins over anything a backend sent up for itself. See [plugin packs](/guides/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: ``` _shared/pack/external_packs/mcmodels/ _shared/pack/external_packs/mcmodels.zip ``` 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`](/reference/proxy-config#settings) 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](/guides/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: ```yaml theme={null} sync: preserve: Nexo/settings.yml: - Pack.server ``` 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 ```yaml theme={null} sync: exclude: - Nexo/pack/external_packs/BetterHud/ ``` 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](/guides/safety). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.