How NexorPanel is built

NexorPanel is a self-contained hosting control panel: its own interface, its own API, its own accounts, its own storage and its own agent on the machine. Nothing is borrowed from another program.

Panel and agent

browser ──HTTPS──► nexor-api (Go) ──── panel.db (SQLite): accounts,
  React/TS SPA          │                sites, log
                        │
                        └──HMAC──► nexor-agent on the machine
                                      │
                                      ├─ site folders, system users
                                      ├─ web server configuration + reload
                                      └─ metrics, services, files, logs

The panel stores what the server should look like. It does not walk the machine, does not know its paths and does not run programs on it. Its data file answers one question: “how should things be”.

The agent brings the machine to that state. It knows its machine, its folders and its services — and nothing about the panel except what the panel sent: a domain name, a mailbox name, an “enabled” flag. A path never arrives in a request; the agent takes its folders from its own configuration, written by the machine's administrator, not by the panel.

The main property follows from this: whoever gets into the panel does not get the machine. They get the right to ask the agent for what the agent was configured to do — and nothing beyond that. The one named exception is the Terminal section, which runs a typed command on the machine; it is off by default and is switched on by a person on the machine, with NEXOR_AGENT_CONSOLE=1 in the agent's settings.

Components

Source layout

Backend layers:

cmd/nexor-api       entry point, configuration, mode selection, graceful shutdown
cmd/nexor-agent     the agent on the managed machine
cmd/nexor-hook      the webhook receiver
internal/config     configuration from the environment
internal/native     own storage: the data file, accounts, sites
internal/agent      the agent and the panel's client to it
internal/store      what the panel needs from a data source: interface and implementations
internal/session    sessions, HttpOnly / SameSite=Strict cookies
internal/httpapi    routes, middleware, JSON responses and error codes

internal/store is the boundary: everything the panel can do is described there as an interface. Own storage, an external engine and fixtures all plug into the same place, and no screen knows which one is behind it.

On the server

The panel listens on 127.0.0.1:8080 and the agent on 127.0.0.1:8462 by default; nginx or another TLS terminator sits in front of the panel. One panel can manage several machines: each one runs its own agent, and the panel is told about them in NEXOR_AGENTS.

Run modes

The mode is not a separate setting; it follows from the others.

Order of operations

Record first, machine second. If writing the record fails, nothing is left on disk that the panel does not know about. The worst case is a record without a folder: it is visible in the list and can be applied again or deleted.

Deleting goes the other way: first removed from the machine, then forgotten. Deleting a site removes its configuration but does not touch its files — configuration is recreated in a minute, files are not.

Every section is being rewritten onto the panel's own code one by one. Until a section is ready, it answers “not connected yet” rather than an empty list, because an empty list reads as “there is nothing”.

Accounts and roles

• Roles: administrator (everything, including servers, plans, firewall and logs), reseller (their own clients and their objects) and client (only their own sites, mail, DNS, databases).
• A client sees only their own objects, and the query guarantees it, not a filter over the response. Someone else's object and a missing one both answer 404.
• Passwords are bcrypt hashes. A disabled account says “disabled” only to someone who knows the password.
• Sessions are sealed cookies (AES-256-GCM, HttpOnly, Secure, SameSite=Strict), rechecked on every request: a disabled account, a changed password or a removed role ends the session immediately.
• Second factor — TOTP codes with recovery codes.
• Programs use API keys, not passwords: one key per task, read-only if needed, with an expiry, revocable on its own. See API keys.
• The first administrator is created on the first start. The password comes from NEXOR_ADMIN_PASSWORD or is generated and written to the log once.

Storage

One SQLite file next to the panel: accounts, sites, the panel's log, second-factor bindings, API keys and revoked sessions. There is no separate database server — a panel that needs another program to start is no longer self-contained. A backup is a copy of the file, and on an empty machine with just the binary the panel comes up whole.

The schema is applied on every start, and every step is idempotent, so there are no schema versions to drift apart. Copies of the panel can also be sent to S3-compatible storage (NEXOR_S3_*), encrypted beforehand with NEXOR_BACKUP_KEY.

Configuration

Everything is configured with environment variables in the .env files above. The most important ones:

Run nexor-api doctor after changing them.

Security rules

• State-changing requests are only POST, PUT and DELETE, with an Origin check.
• Administrative sections are closed by a separate adminOnly layer, independent of storage ownership checks.
• The agent verifies an HMAC signature with a one-time nonce on every request; the secret is in a root-only file and is never sent anywhere.
• The agent runs only programs from its own list, with arguments it builds itself. There is no shell anywhere: a semicolon in a name is a semicolon, not a second command.
• Sign-in is rate-limited: 5 attempts a minute per address and login, plus a limit per address.
• File paths never leave the site's folder, including through symbolic links. Deleted files go to the site's .nexor-trash for 30 days.
• A secret entrance (NEXOR_ENTRANCE) hides the sign-in form from scanners: everything else gets an identical empty 404.
• The service sets its own security headers — content security policy without inline scripts, frame ban, nosniff, Referrer-Policy.
• The panel never stores database passwords; phpMyAdmin is opened with a half-hour account created for that one visit.

Stack

API reference Download