Remnawave panel: what the repository actually contains

What remnawave/panel actually is, and who it is for

The README opens with one sentence: "A powerful proxy management tool, built on top of Xray-core, with a focus on simplicity and ease of use." That is the whole product description in the repository. The topics list adds the vocabulary the project uses for itself: censorship-resistant, proxy-management, vless, trojan-gfw, xray, xtls-core, nestjs, typescript. Read together, the target user is someone already running Xray-core who wants a management layer over it rather than a new proxy protocol.

The repository you are looking at, however, is not the panel. The package name in package.json is @remnawave/docs, marked "private": true, and the scripts are Docusaurus scripts: start, build, swizzle, deploy, clear, serve, write-translations, write-heading-ids. The top-level entries include docusaurus.config.ts, sidebars.ts, docs/, _panel-docs/, static/ and a Caddyfile. This is the documentation and landing site, served by Caddy from a build directory. If you came here expecting the panel source, you are in the wrong repository.

That distinction matters for anyone evaluating the project. The README points to https://docs.rw as the get-started destination, and the repository you can clone is the thing that produces that site. Judgements about the panel's internals cannot be made from these files. What you can judge is the documentation pipeline, the release cadence visible in the tags, and the licence. Those three things are enough to decide whether to spend an afternoon on docs.rw, and not enough to decide whether the panel fits a production network.

How the documentation site is put together

The build is a standard Docusaurus 3 site with a few additions. Dependencies include @docusaurus/core, @docusaurus/preset-classic, @docusaurus/plugin-client-redirects and @docusaurus/theme-mermaid. The redirects plugin implies old documentation URLs are kept alive, which is what you would expect from a project whose docs have moved. Mermaid support means diagrams are written as text in MDX rather than exported images, so a diagram change shows up as a diff in review.

Two dependencies stand out. @scalar/docusaurus renders API reference pages, which suggests the panel exposes an HTTP API that the docs describe. @tabler/icons-react and react-icons supply icons for the landing page. The site also pulls postcss-preset-mantine and postcss-simple-vars in devDependencies, so Mantine styling conventions reach the CSS pipeline even though the site itself is Docusaurus. That is a mild inconsistency: the docs site borrows the design system of the panel it documents.

Formatting and linting are handled by oxfmt and oxlint rather than Prettier and ESLint. The check script runs oxfmt --check && oxlint, and the fix script runs oxfmt && oxlint --fix. TypeScript is pinned at ~5.8.3, and engines.node requires >=22.0. The Dockerfile is small: it takes CADDY_VERSION with a default of 2.10, builds from caddy:${CADDY_VERSION}-alpine, copies build into /app/docs and landing into /app/landing, copies the Caddyfile to /etc/caddy/Caddyfile, and runs caddy run --config /etc/caddy/Caddyfile --adapter caddyfile. Note that it copies a build directory that the Dockerfile itself does not produce. The docusaurus build has to run before the image is built, which means the container image is only as fresh as the last build step someone ran. There is no multi-stage build here that would make the image self-contained.

Running the documentation site locally

If you want to read the docs offline or contribute a page, the local workflow is the Docusaurus one. Node 22 or newer is required by the engines field. The repository ships a package-lock.json, so npm ci is the reproducible install path.

npm ci
npm run start

The start script runs docusaurus start, which serves the site on Docusaurus's default development port and reloads on file changes. The documentation states nothing about the panel itself here; you are reading the site that describes it.

For a production build, the build script sets NODE_ENV=production before invoking docusaurus build, and the output lands in the build directory that the Dockerfile expects to copy.

npm run build

To check formatting and linting the way CI would, run the check script. It fails on any formatting drift rather than rewriting files, which is why there is a separate fix script.

npm run check

The serve script runs docusaurus serve, which is the quickest way to confirm the production build behaves before you containerise it. Beyond this, the README does not document installation of the panel itself; it points to https://docs.rw for that. One practical consequence: if you want to audit what the panel does before installing it, you cannot do that from this repository. You can only audit how its documentation is generated.

Where the documentation is thin

The README is a logo, a one-line description, a link to docs.rw, a release badge, a stars badge, a screenshot and a Telegram invite. It contains no installation instructions, no configuration reference, no architecture description and no upgrade notes. Everything substantive lives on the external documentation site, which is not in this repository in a form you can read from the README alone.

That is a real constraint. If docs.rw is unreachable, or if a page you need has not been written, the repository gives you almost nothing to fall back on. The _panel-docs directory suggests content is staged there, but the README does not explain the relationship between _panel-docs and docs, and this article cannot confirm it. A reader who wants to know whether the panel supports a particular Xray-core transport has no answer in the repository.

The Telegram invite is the only support channel the README names. For an operator debugging a production outage at an inconvenient hour, a chat group is a different proposition from a versioned issue tracker, and the README does not describe an escalation path beyond the chat.

Maintenance status is the one thing the repository does tell you plainly. It is not archived, and the last push was on 2026-09-12, with release 3.4.4 tagged the same day and 3.4.3 and 3.4.2 in the two weeks before that. The release cadence is visible; the content of those releases is not described in any file provided here. Three tags in thirteen days is either rapid iteration or rapid patching, and nothing in the repository distinguishes the two.

The licence question

The repository carries AGPL-3.0, and the licence file is spelled LICENCE at the repository root. AGPL-3.0 is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the licence text requires you to offer those users the corresponding source. For a proxy management panel, that clause is not hypothetical, because the panel is by definition operated as a network service.

This is not legal advice, and the exact obligations depend on what you modify and how you deploy. What can be said from the repository is that the licence is AGPL-3.0 and that the project does not ship an alternative commercial licence in the files provided. If your organisation has a policy against AGPL dependencies in network services, that policy applies here before you install anything.

There is a second cost dimension: the documentation site pins Node >=22.0 and TypeScript ~5.8.3, and the panel itself is TypeScript on NestJS according to the topics list. Upgrading the panel means tracking a NestJS codebase and an Xray-core dependency at the same time. The repository does not document a rollback path, and the README does not describe a migration guide for major versions. For a self-hosted operator, that means the upgrade procedure has to be reconstructed from release notes on docs.rw or from the chat, neither of which is versioned in this repository.

Alternatives and what actually differs

The obvious comparison is running Xray-core directly. Xray-core is the proxy engine; Remnawave is a management layer on top of it. If you run Xray-core yourself, you edit a JSON configuration, restart the process, and manage users by hand or with your own scripts. You get no web interface, no user database, no API, and no multi-node coordination, but you also get no NestJS service, no database and no AGPL network obligation from a panel. For a single server with a handful of users, the direct route is less machinery, and the failure surface is a process you can restart.

The trade-off is operational. Manual user management does not scale past the point where you are editing configuration files by hand, and it gives you no audit trail of who changed what. A panel exists to move that work into a database and an interface. Whether that is worth a second service, a database and a licence obligation depends entirely on how many users and nodes you are running, and the repository does not state a scale at which Remnawave becomes the better choice.

A second comparison is with other Xray-based panels. The topics list names vless, trojan-gfw and xtls-core, so Remnawave is positioned around the same protocol set its peers cover. The difference the repository supports is the stack: TypeScript and NestJS rather than Go or PHP, and a documentation site generated by Docusaurus with Scalar-rendered API reference. If you want to read or extend the panel's API in TypeScript, that stack is the reason to pick it. If you want a single static binary with no runtime dependencies, it is the reason not to.

What the repository does not give you is a feature comparison. There is no benchmark, no protocol support matrix in the README, and no statement about how many nodes the panel manages. Those claims would have to come from docs.rw, and a comparison built on marketing pages rather than on the repository is worth less than one built on configuration files.

Who should adopt it, and what to check first

Adopt Remnawave if you already operate Xray-core, you want a TypeScript control plane with an HTTP API described by Scalar, and you are comfortable with AGPL-3.0 in a network service. The release cadence, with 3.4.4 on 2026-09-12 following 3.4.3 on 2026-08-31 and 3.4.2 on 2026-08-30, suggests the project is moving, though the repository does not describe what changed between those tags.

Do not adopt it if you need installation steps in the README, if you cannot read the documentation at docs.rw, or if AGPL-3.0 is incompatible with how you distribute or host software. Do not adopt it if you want a single binary with no database and no web tier; running Xray-core directly is the smaller commitment. And do not adopt it on the strength of this repository alone, because this repository is a website generator.

Before installing, verify three things. First, that docs.rw documents the panel version you intend to run and the Xray-core version it expects, because the README does not. Second, that you have read the LICENCE file at the repository root and understand the network clause, because the panel is a network service by design. Third, that you know how to roll back a release, because the README does not document rollback and the release history shows three tags in under two weeks. If docs.rw does not answer the Xray-core version question, that is itself the answer about how much documentation exists.

Editorial conclusion

Remnawave is for operators already running Xray-core who want a TypeScript control plane and are willing to read the documentation site at docs.rw before touching a server. It is not for anyone who wants a single binary with no panel, and it is not for anyone who cannot accept AGPL-3.0. Verify first that the documentation site covers your exact Xray-core version and that you have read the licence text in the LICENCE file at the repository root.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. remnawave/panel on GitHub