Nexora is a proxy management platform made of a panel (this repository) and
any number of nodes (nexora-vpn/node).
The panel is the single source of truth — users, protocols, templates, nodes,
subscriptions — and drives every node over mutual TLS. Nodes hold no database.
This repository publishes the panel: its release binaries, container images, installer and documentation. The source is not public.
bash <(curl -fsSL https://raw.githubusercontent.com/nexora-vpn/panel/main/install.sh)That is the whole install. It asks nothing: the script sets up the database and the service, then prints a one-time link that opens the setup wizard, where the main admin account, the panel's port and paths, and HTTPS are chosen.
Until that wizard is finished the panel answers nothing else — every other path returns 404, and so does the wizard itself without the token in that link — so an unconfigured panel sitting on a public IP gives a scanner nothing to work with.
| Flag | Effect |
|---|---|
--postgres |
install and configure PostgreSQL instead of SQLite |
--version vX.Y.Z |
install a specific panel release instead of the latest |
--node-version vX.Y.Z |
stage a specific node release instead of the latest |
--uninstall |
stop and remove the panel (the database is kept) |
Running the script again on a server that already has Nexora updates it in
place, keeping the database, config.json, settings and admins.
Alongside the panel the installer stages node binaries under
/var/opt/nexora/bin/. Those are what the panel hands to node installers, so
adding your first node needs nothing staged by hand.
git clone https://github.com/nexora-vpn/panel
cd panel/docker/sqlite # or: cd panel/docker/postgres
docker compose up -d
docker compose logs panel | grep setupImages: ghcr.io/nexora-vpn/panel (linux/amd64, linux/arm64), published with
every tagged release.
A third stack, docker/panel-and-node, runs a node beside the panel on one
server. It works, and it is not recommended — a node's address goes into
every subscription link, so it publishes the panel's address to every user, and
a node under load takes the panel down with it. The
install guide has the
two-step start and the caveats.
The panel binds [::]:2095 by default, which serves IPv4 as well — a v4-only,
v6-only or dual-stack server all work with no configuration (on a host with IPv6
switched off the panel falls back to 0.0.0.0 by itself). A node with only an
IPv6 address is added with its address written plainly, 2001:db8::1, and the
panel brackets it wherever a link, a subscription URL or a client profile needs
it.
The panel backs up its own database — Settings → Backup in the sidebar.
An archive is a logical dump of every table, not a copy of the database file, so one taken on SQLite restores onto PostgreSQL and back: it is also how you move between the two, and how you move a panel to another server. It carries everything the panel knows, credentials included, which is why every backup route is limited to the main admin and why an archive is worth encrypting before it leaves the server.
| Download one | Straight to your browser, nothing kept on the server |
| Take one on the host | Written into the backup directory below |
| Schedule | Off by default; an interval in hours and how many archives to keep |
| Encryption | Optional passphrase (scrypt + AES-GCM). The panel cannot recover a lost one |
| Restore | From an upload or from an archive already on the host; the panel restarts into it |
Archives live in /var/opt/nexora/backups on a native install, and in
./backups next to the docker-compose.yml of whichever Docker stack you run.
Copy that directory off the server — a backup that only exists on the machine it
protects is not a backup.
Before replacing anything, a restore writes a pre-restore snapshot of the current database into the same directory. Retention never deletes those; they are the undo.
Moving to a new server: install the panel there and, on the setup wizard's first screen, choose Restore a backup instead of filling the form. The wizard is the only place a restore is possible before an account exists, which is exactly the state a fresh install is in. Take the licence key across too — it is bound to the host's fingerprint, so the new server needs its own.
The schedule is also settable from the command line, which is what a headless or scripted install wants:
nexora-panel config set backup_enabled true
nexora-panel config set backup_interval_hours 24
nexora-panel config set backup_keep 14
nexora-panel config set backup_passphrase "a long passphrase" # optional| Linux | nexora-panel-linux-{amd64,arm64,armv5,armv6,armv7,386,s390x,riscv64}.tar.gz |
| Windows | nexora-panel-windows-{amd64,arm64}.zip |
Each archive contains the nexora-panel binary and, on Linux, the systemd unit.
The panel and the node are versioned independently — a panel v1.4.0 does not
imply a node v1.4.0. Any node release is driven by any panel release of the
same or newer minor version.
Every setting that can make the panel unreachable is writable offline, so a wrong port, domain or path is never a dead end:
nexora-panel config set web_listen_port 2095
nexora-panel config set web_listen_ip ""
nexora-panel config set web_domain ""
nexora-panel config set web_basepath ""
systemctl restart nexora-panelSee nexora-panel help for the full command list.
- Bugs and feature requests — open an issue here.
Node issues belong in
nexora-vpn/node. - Security vulnerabilities — report them privately through the organisation's security advisories. Please do not open a public issue for those.
Nexora Panel is proprietary software, licensed per installation — see
LICENSE. Without a key it runs on a free tier (10 inbounds, 10
outbounds, 10 endpoints, 10 users, 10 nodes) with the full feature set, so everything
can be evaluated before buying. A key is bound to the panel host's hardware
fingerprint, which nexora-panel hwid prints.