Remnawave or 3x-ui: which panel to choose

Before you install a panel, you have to choose which one. I've worked with both hands-on and I'll show you honestly, without "this one's better": Remnawave and 3x-ui solve the same problem differently, and the choice depends on the scale you're planning. We'll break down the architecture, the entry barrier, and what to take for which scenario.

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.

Two philosophies for one job

Both panels do one thing: manage inbounds, clients, and subscriptions on top of the Xray core. But they approach it from different sides.

• 3x-ui is a panel on a single server. It's installed right where the traffic flows: the panel and Xray live on the same machine. One binary, one SQLite database, zero Docker. Install it with a command — it's working in five minutes.
• Remnawave is a node orchestrator. The panel (the brain) sits separately and holds no Xray inside itself at all; traffic flows through separate node servers to which the panel hands out config. It runs in Docker and requires a domain and a TLS reverse proxy out of the box.

Everything else grows out of that. 3x-ui is "a server with an admin panel." Remnawave is "a control center for a fleet of servers."

Entry barrier and runtime

3x-ui wins on start-up speed by a landslide. A one-line installer puts up the panel, brings up a systemd service, generates a random login/password/port/secret-path, and pulls in fail2ban to protect against brute-force. A domain isn't required — you can log in right by IP, and set up TLS for protocols later inside the panel. The current combo is 3x-ui v3.4.2 with Xray 26.6.27 inside, interface in Russian.

Remnawave is heavier at the entrance by design. It's a Docker stack of several containers (backend, database, cache, nodes separately); the backend forcibly requires a TLS reverse proxy and won't respond at all without one. A domain is mandatory from the very start. This is longer and more complex — but it's this architecture that gives scale.

Scale: one machine versus a fleet

This is where the main line of choice runs.

3x-ui lives on a single server. Yes, you can link several 3x-ui instances into something like a network (there are node mechanics), but in spirit it's "one server — one panel." Need a second server — you install a second 3x-ui on it and stitch the links together by hand. While you have one or two exits, that's not a problem but a plus: fewer entities, less that breaks.

Remnawave is built for many nodes under one panel. A single control center hands config out to dozens of servers, keeps unified traffic accounting across all of them, does cascades (entry in one country → exit in another), auto-select balancers, and complex routing from one point. When you have five, ten, twenty exit nodes, doing it by hand across twenty separate 3x-ui panels is already pain, while through one Remnawave it's the norm.

Convenience of the operator's routine

• Clients and subscriptions. Both can hand a client one subscription link for all their servers, traffic limits, expiry, device limit. 3x-ui has an important quirk: you have to create clients strictly through the interface — poke into the database by hand and the panel will wipe them on the next config rebuild. In Remnawave client logic is moved into a separate layer of users and squads, which is more convenient at scale.
• Protocols. The core is the same (Xray 26.x), so the set of transports matches: VLESS+Reality, XHTTP, gRPC, Hysteria2. The difference is in the UI you assemble it with. 3x-ui has a pleasant connection-creation form with tabs and auto-generation of Reality keys right in the interface. In Remnawave inbounds are described in a Config Profile, which is more flexible but requires understanding the config structure.
• Backup. 3x-ui is one database file: copy it — you've taken the whole panel. Remnawave is a Docker stack with Postgres; backup is more complex, but more portable between machines.

The shared trap of both panels

Regardless of choice, there's an Xray 26.x gotcha that bites everyone: on this core the donor www.microsoft.com breaks Reality — the tunnel won't come up. The working donor is www.cloudflare.com. This isn't about the panel, it's about the core, so it applies to both. Keep it in mind from the very first inbound.

Another shared point: one protocol isn't enough. In both cases it makes sense to keep two or three transports on the exit, so that when one is blocked another works — the mechanic is identical, only the way you set it up in the UI differs.

How to choose for your job

Short and to the point:

• Take 3x-ui if — you have one or two servers, want to start today without Docker and a domain, value "install and it works," the service is small, or you're just trying it out. The entry barrier is minimal, and for a single exit it does everything the heavy panel does.
• Take Remnawave if — you're planning many nodes, cascades, auto-select, and unified accounting across the whole fleet from one point; you're growing into a serious service with dozens of paying customers; you're ready to invest in Docker and a reverse proxy for the sake of scale.

A common working trajectory: people start on 3x-ui to quickly test demand on a single server, and when the number of nodes grows and the routine of separate panels starts eating time — they migrate to Remnawave for centralization. The reverse migration also happens — when they realize they don't need a fleet and the Docker stack only complicates life.

Chosen? Go to the practice of your branch: for 3x-ui that's "Installing 3x-ui in 10 minutes," for Remnawave — "The panel in 15 minutes." From there the paths diverge by interface, but the core and protocols under the hood are the same for both.