RVG Gateway: A FastAPI Multi-Protocol Proxy Panel for Railway

What RVG Gateway actually solves, and for whom

Running a proxy endpoint for a handful of people usually means editing a server config file, restarting a daemon, and tracking who used how much traffic in a spreadsheet. RVG Gateway replaces that with a FastAPI application that holds the protocol relays and a web dashboard in the same process. The README describes it as a "multi-protocol proxy management panel" and says it was "originally built around a simple VLESS-over-WebSocket relay" before growing authentication, quota tracking and a management UI.

The audience is narrow and specific: a single operator who deploys on Railway, wants VLESS, Trojan, Shadowsocks and MTProto from one service, and prefers clicking through a dashboard to hand-editing JSON. The project structure supports that reading. main.py is the FastAPI entrypoint, central.py holds orchestration, pages.py serves dashboard routes, and the protocol directory contains the per-protocol relays. There is no separate worker, no external database service, and no admin CLI mentioned anywhere in the README.

If you are provisioning proxy access for a team you do not trust, or you need per-user billing and audit trails, this is the wrong shape. The README's feature list mentions per-link quotas and enable/disable switches, not roles, permissions or an audit log.

The relay path from client to protocol router

The README's architecture diagram shows clients such as v2rayNG and NekoBox connecting to the FastAPI server, which passes the connection to a protocol router. From there the traffic splits three ways: WebSocket goes to the VLESS and Trojan relay, raw TCP goes to the Shadowsocks relay, and MTProto is handled by the mtg binary, which the README pins at version 2.1.7. The same FastAPI process also serves the admin dashboard at /dashboard and, per the diagram, the Telegram bot automation.

State lives in what the diagram labels an "In-Memory Link & Quota Store". That is the single most consequential design decision in the project. Links and their traffic counters are held by the running process, so a redeploy, a crash, or a Railway restart resets them. The README does not document any persistence layer, backup, or export of the link store. Note that redis>=5.0.1 appears in requirements.txt, so a Redis client is available to the codebase, but the README's architecture diagram does not show Redis in the data path and no environment variable for a Redis URL is listed. Treat the in-memory store as the documented behaviour.

The README also lists transport variants: xHTTP, gRPC and HTTPUpgrade, plus TLS fingerprint spoofing set to Chrome and relay buffers of 512KB with TCP_NODELAY and SO_KEEPALIVE. Those are configuration details rather than features you can verify from the README alone; the repository has no benchmark or tuning document.

Installing RVG Gateway locally and opening the dashboard

The README gives a local development path that does not require Railway. It assumes Python 3.11 or newer, which the badge at the top of the README states. Clone your fork, create a virtual environment, install the pinned dependencies, and start the server:

git clone https://github.com/<your-username>/RVG.git
cd RVG
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python main.py

On Windows the README gives venv\Scripts\activate as the activation command instead. After python main.py the README says the dashboard is available at http://localhost:8000/dashboard. Open that URL in a browser; you should see the traffic overview, live connections, link manager and QR export panels the README lists under Dashboard Preview.

For the Railway route, the README's steps are: fork the repository, create a new Railway project and deploy from the GitHub repo, then enable a public domain under Settings, Networking, Generate Domain. That step sets RAILWAY_PUBLIC_DOMAIN automatically. The dashboard then lives at https://your-app.up.railway.app/dashboard. The README's final instruction is to copy the default VLESS link and import it into a client such as v2rayNG, NekoBox or Streisand.

Three environment variables are documented. PORT defaults to 8000, SECRET_KEY defaults to a randomly generated value, and RAILWAY_PUBLIC_DOMAIN defaults to localhost and is set for you on Railway. Nothing else is listed, so any other secrets the code may read are undocumented.

Where the in-memory link store bites you

The failure mode is easy to state. Every link you create in the dashboard, and every megabyte counted against its quota, exists only in the running process. Railway restarts containers on deploys and on platform events. When that happens, the README gives no procedure for restoring links, and no environment variable points at durable storage. The README does not document rollback, export, or import of the link store.

That makes RVG Gateway a poor fit for anything with an availability expectation. If a client's VLESS link stops working after a redeploy because the UUID is gone, you are recreating links and redistributing them by hand. The README's per-link quota feature, which is one of the main reasons to pick a panel over a bare config file, is exactly the feature that loses its state.

There is a second boundary. MTProto depends on the mtg binary at version 2.1.7. The README does not explain how that binary is obtained or updated in the container, so treat MTProto support as dependent on a component outside the Python codebase. The same caution applies to the Telegram automation scripts, botgeneratedomin.py and bottokentcpproxy.py, which the README lists in the project structure and describes as domain suggestion via a Cloudflare Worker and automated TCP proxy dispatch. No configuration for those bots appears in the environment variable table.

How RVG differs from Xray-core plus a panel

The common alternative is Xray-core or sing-box as the proxy engine, paired with a separate web panel and a database. In that arrangement the engine is a mature, independently versioned binary, the panel is a separate service, and user state lives in a database that survives restarts. The trade-off is operational: two or three moving parts, a database to back up, and a configuration format to learn.

RVG collapses all of that into one FastAPI process. The relay code sits in the protocol directory next to the dashboard routes, so there is one deploy target and one language to read. For an operator who wants to understand the whole stack in an afternoon, that is a real advantage, and the README's one-click Railway flow reflects it. The cost is that you inherit the engine's maturity level and its state model. Xray-core has years of protocol edge cases handled; RVG's relays are whatever the repository contains. And where a panel-plus-database setup persists users, RVG's documented store does not.

A second, lighter alternative is running Xray or sing-box alone with a hand-written config and no panel at all. You lose quotas and QR export, but you also lose the restart problem, because the config file is the state.

Licence, maintenance and what an upgrade costs

The repository has no standard open source licence identifier. GitHub reports the licence as NOASSERTION, and the README's badge links to a LICENSE file labelled Custom. That means you need to read LICENSE before you deploy this for anyone other than yourself, because the terms are not the ones you would assume from MIT or Apache-2.0. This is not legal advice; it is a reason to open the file. A SECURITY.md is present at the top level, though the README does not summarize its contents.

The last push to the default branch was on 2026-09-13, four days before this writing, so the repository is not archived and is being touched recently. There are no retrieved releases, so there is no tagged version to pin and no release notes to read for upgrade guidance. Dependencies are pinned exactly in requirements.txt (fastapi==0.104.1, uvicorn[standard]==0.24.0, httpx==0.25.1, websockets==12.0), with floor constraints on uvloop, httptools, cryptography, psutil and redis. Exact pins make local installs reproducible but mean security updates arrive only when someone edits the file.

Upgrade cost is dominated by the state model rather than the code. There is no migration tooling in the repository layout, and updater.py is described only as self-update logic, with no explanation of what it updates or how it behaves on failure. On Railway, an upgrade is a redeploy, and a redeploy clears the in-memory store.

Editorial conclusion

Adopt RVG Gateway if you want a small, readable FastAPI service that turns a Railway container into a VLESS, Trojan, Shadowsocks and MTProto endpoint with a quota dashboard, and you accept that links and quotas live in memory and vanish on restart. Do not adopt it if you need a hardened multi-tenant product, a standard permissive licence, or a documented migration path, since the README does not describe rollback and the LICENSE is marked Custom. Before you commit, open LICENSE and SECURITY.md, then restart the deployed service once and check whether the default VLESS link still resolves.

Frequently asked questions

Official sources

1. arvin341az-glitch/RVG on GitHub
2. Issues
3. README