What Remnawave is and why you need a panel at all

Before you install the panel, let's break down what it actually does and why you can't scale without it. Grasp Remnawave's architecture here and the step-by-step install in the paired practice will stop being magic.

This material covers the engineering of your own network infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

Why a panel at all

You can stand up a node by hand: write an Xray config, generate keys, hand the client a link manually. For one server and three friends, that'll do. For a service, no.

The moment you have more than a couple of nodes and a dozen clients, manual management turns into hell: a new client has to be written into every node's config, a key change means updating everyone, adding a node means rewriting all the subscriptions. One typo — and a client is without internet. The panel is what turns a pile of scattered configs into a manageable service.

The panel stores users, nodes, plans, and subscriptions in one place, lays configs out onto the nodes itself, and generates a link for each client. Added a node — it appeared for everyone entitled to it. Changed a key — it updated everywhere. Without this you're not a service operator but a person hand-editing JSON at night.

What Remnawave is

Remnawave is a control panel built on Xray-core. The key thing to grasp right away: Xray itself doesn't run inside the panel. The panel is the brain-orchestrator. It decides who has access to what, and pushes configs to the nodes, while traffic flows through the nodes.

A standard installation brings up three containers:

• The panel (backend) — the brain: users, subscriptions, nodes. Listens only locally, faces outward strictly through a TLS reverse proxy. It serves the subscription page itself.
• The database (PostgreSQL) — all the service's state: clients, nodes, squads. Lose it without a backup — you've lost all your clients.
• The cache (Valkey/Redis) — a service layer, lives on the internal network.

A node is a separate server, not a panel container. Xray runs on it and real traffic flows through it. At least one, but usually several.

An important security detail: the panel forcibly requires a reverse proxy with HTTPS. Without the protocol header being correctly forwarded, it simply doesn't respond — this isn't advice but a hard-wired safeguard against the panel sticking out over bare HTTP.

First login — the moment of risk

The super-admin isn't set in the settings. The first person to register on the panel's domain becomes the super-admin. Hence the rule: register immediately after start-up. Hesitate — and anyone who found the domain can grab the panel. This is literally seizing the whole service through open registration.

The chain you have to understand

Here's Remnawave's main scheme, without which nothing will assemble. A client's access travels along a chain of four links:

Config Profile  →  Inbound  →  Host  →  Squad  →  user
 (xray config)     (listener)  (what the   (plan /     (subscription)
                                client sees) access)

Let's break down the links:

• Config Profile — the full Xray JSON for a node: all inbounds and settings in one lump. A node references exactly one profile.
• Inbound — one listener inside the profile: a specific protocol on a specific port (for example, VLESS Reality on 443). There can be several in a profile.
• Host — what the client actually sees: server name, connection address, port, one associated inbound, and advanced settings (SNI, fingerprint). One visible host = one server in the client's list.
• Squad — the plan and access: which inbounds are available to members. Users and squads are linked many-to-many.

The beginner's main gotcha

Remember this so you don't waste an evening on debugging. Creating a profile, enabling an inbound on the node, and adding a host is not enough. Until the inbound is added to the user's squad, the client won't see it. There'll be no error, just an empty subscription.

The access formula is: a client sees a server only if the inbound is simultaneously (1) enabled on the node, (2) served by a visible host, and (3) included in that user's squad. Drop any of the three — the server isn't in the subscription. Half of the "my subscription is empty" tickets are the forgotten third point.

Plans through squads

Since the squad defines access — plans are built precisely on squads. Each plan = a separate squad with the right set of inbounds:

• Basic — one node.
• Main — all nodes without beating "jammers."
• Premium — everything plus circumvention and auto-select.

A client upgrade isn't a re-registration but adding them to the right squad. A client can be in several at once. It's flexible and doesn't require touching configs.

Why Remnawave specifically

There are several panels, but Remnawave has become the working choice: actively developed, holds a modern Xray stack, supports several subscription formats for different clients, serves a branded page, and has a proper API for a sales bot. Everything a commercial service needs, out of the box.

Now that the architecture is in your head, installation stops being a set of incomprehensible commands. Go to the paired practice — there we install the panel on a clean server in one evening, hook up a domain, and issue the first subscription. And you already understand the profile→inbound→host→squad chain, so you'll see what you're doing rather than just copying.