mrkeyoor.com_
Sat 03 Oct 07:17 UTC
Self-Hostedevaluationupdated 03 Oct 2026

vodiwalker_panel review

Vodiwalker Panel is a Persian-language web panel for creating and managing proxy connections, subscriptions, administrators, and a Telegram control bot. The repository does not provide English documentation, so non-Persian readers must work from the Python source or translate the short README.

Verdict

Our Vodiwalker Panel run installed 63 packages and built in 45 seconds, but pip-audit found 17 known vulnerabilities and there was no test target. That is enough for code evaluation, not enough for an internet-facing proxy control plane. Persian-speaking experts may find the compact feature set useful, but everyone else should choose a panel with a license, written deployment documentation, versioned releases, and automated tests.

We ran it

Lab card: what happened when we ran vodiwalker_panelScreenshot of vodiwalker_panel (github.com/Vodiwalker/vodiwalker_panel)
Install✓ · 36s63 packages · 88 MB
Build✓ · 9s
Testsn/ano test script
Known vulns17(pip-audit)
Repo19 files~19,761 lines of source · 1.5 MB · 0 CI workflows

Answers from our run

Does vodiwalker_panel build from source?

Dependencies installed in 36 seconds (63 packages), and the build succeeded in 9 seconds. We cloned commit c547e73 into a clean Debian container with 3 CPUs and no project-specific setup.

Does vodiwalker_panel have tests you can run?

Not through a standard command: the project exposes no test script or target that our harness could run.

Does vodiwalker_panel have known vulnerabilities in its dependencies?

pip-audit flagged 17 known advisories in the dependency tree at the time of our run.

Who should not use vodiwalker_panel?

Organizations that require a clear software license: the repository has no declared license or LICENSE file.

What are the alternatives to vodiwalker_panel?

3X-UI, Marzban, Hiddify Manager. Our Vodiwalker Panel run installed 63 packages and built in 45 seconds, but pip-audit found 17 known vulnerabilities and there was no test target.

Setup2/5Builds quickly, but written installation guidance is missing
Docs1/5Short Persian README sends setup questions to a video
Community2/51,096 stars, but the visible issue reports contain no detail
Maturity1/5No release, license, CI, or test target; audit found 17 advisories

Who it’s for

Persian-speaking operators who understand VLESS, VMess, Trojan, WebSocket, XHTTP, and raw TCP proxy deployment.
Railway users prepared to supply persistent storage, public host settings, and separate TCP exposure.
Small operators who want a web dashboard and Telegram bot over one local state file.
Reviewers willing to audit a 19-file Python service before placing it on the internet.

Who it’s NOT for

Organizations that require a clear software license: the repository has no declared license or LICENSE file.
Teams with an English-only runbook: the README is Persian, points readers to a video, and gives no English installation steps.
Operators requiring a tested dependency baseline: our run found 17 known vulnerabilities, and the repository exposes no test script or target.
Buyers who need versioned releases and upgrade notes: GitHub returned no latest release, while the source contains several different version labels.
Anyone expecting docker build . to work without adjustment: the container recipe is named Dockerfile.txt, not Dockerfile.

Setup reality

Our fresh Debian sandbox installed commit c547e73 in 36 seconds, adding 63 Python packages and 88 MB. The build succeeded in 9 seconds. There was no test script or target, so tests were skipped; pip-audit reported 17 known vulnerabilities.

The sample environment needs an admin username and password, secret, public URL, storage path, TCP host and port, plus Telegram credentials if you enable the bot. State lives under the configured data directory.

The HTTP service defaults to port 8000, while raw VLESS TCP uses a separate listener that the source defaults to 6543. Dockerfile.txt needs renaming or an explicit -f argument, and the README does not explain the deployment path in text.

The panel manages proxy access through a Persian interface

Vodiwalker Panel combines a FastAPI web dashboard, subscription links, connection tracking, administrator accounts, and a Telegram bot. Its source names VLESS over WebSocket, raw TCP, and several XHTTP modes, along with VMess and Trojan routes. Operators can create users, limit traffic and connection counts, group subscriptions, inspect live connections, and issue QR codes from one service.

The audience is narrower than that feature list suggests. The README is 15 short lines of Persian promotion and links to a Telegram channel and an external tutorial video. There are no written install commands, architecture notes, upgrade steps, or English pages. The interface text and many source comments are also Persian. A non-Persian operator would be translating both the runbook and the administrative UI while handling live proxy credentials.

One process holds the web panel, relays, and Telegram control

The application stores links, subscriptions, sessions, administrators, and daily statistics in local state. A Telegram bot exposes creation flows, configuration lists, online users, usage reports, backup actions, and a mini app. The web side has role permissions and scoped administrators. This is a lot of operational authority in one Python service and one persisted data directory.

Versioning inside the repository is inconsistent. The first comment in main.py says 15.0.0, env.example calls the product Professional 17, and the FastAPI application reports 27.3.0. GitHub had no release object on October 2, 2026. Without a tag and changelog tied to the deployed code, an operator cannot use the displayed version to reconstruct an installation with confidence.

What happened when we ran it

Our sandbox installed commit c547e73 in 36 seconds. Pip added 63 packages and used 88 MB on disk. The build step completed in 9 seconds on 3 CPUs with 8 GB of RAM, Python 3.12, Debian, no secrets, and no elevated privileges. That proves the checked-out Python code could be installed and built in the environment we used.

There was no test script or target, so the pipeline skipped tests. The repository has 19 files and about 19,761 lines of source, with no tests directory and 0 CI workflow files. Pip-audit reported 17 known vulnerabilities. The supplied measurement does not name their packages or severities, so claiming a particular exploit path would go beyond the evidence.

Deployment needs more configuration than the README supplies

The sample environment asks for owner credentials, a secret, a persistent data path, a public base URL, public TCP settings, and optional Telegram bot details. The service can create a secret file when no secret is supplied, and it writes application state beside that file. Back up that directory, restrict access to it, and set the owner password before public exposure.

HTTP defaults to port 8000. Raw VLESS TCP uses a separate listener whose source default is 6543, so a platform that only exposes the web port will not carry that traffic. The repository includes a valid-looking Python container recipe, but its filename is Dockerfile.txt. Docker will not select it through the usual default command unless you rename it or pass the file explicitly.

Security controls exist, but there is no automated proof

The source includes hashed passwords, session cookies, failed-login throttling, permission checks, administrator scoping, and Telegram admin validation. Those are useful controls. They are also the kind of controls that need regression tests because a missed dependency on one route can expose owner actions, subscription data, or live connection details.

Our run found 17 known dependency vulnerabilities and no callable test suite. The source grants sessions a 365-day lifetime, according to its SESSION_TTL calculation, which raises the cost of a stolen session token. These facts do not prove the panel has been breached. They do mean an operator should commission a focused authentication and route audit before treating the application as a safe public control plane.

Activity is recent, while release discipline is absent

GitHub showed 1,096 stars, 4 combined open issues and pull requests, and a last push on October 1, 2026. Recent commits touched the Telegram bot, XHTTP code, and connection handling. The two visible open issues were both titled 1, each had a body of No, and neither contained a usable defect report. Stars here say more about attention than support quality.

No license is declared in the repository, so do not assume that public source grants permission to copy, modify, or redistribute it. The missing release, missing CI, absent test target, and 17 audit findings all point the same way: treat Vodiwalker Panel as code to inspect, not an appliance to expose after a 45-second build. The operational alternatives are larger, but their documentation and release trails give you more to verify.

Alternatives

ProjectWhat it isPick it when
3X-UI gh↗A multi-user Xray panel covering a wider set of proxy protocols.pick this instead when broad protocol support and a larger public operator community matter.
MarzbanA web interface for managing Xray users, subscriptions, and nodes.pick this instead when you want documented Xray administration and a more established release process.
Hiddify ManagerA multi-user anti-filtering panel with many protocols and a Telegram proxy.pick this instead when guided installation and broader client-facing features outweigh a smaller codebase.

What people are saying

  1. [velocity-scout] Vodiwalker/vodiwalker_panel

Sources

  1. Vodiwalker Panel README
  2. Vodiwalker Panel main application
  3. Vodiwalker Panel environment example
  4. Vodiwalker Panel commit history
  5. Vodiwalker Panel issue 3

More self-hosted reviews

lunel · srs · FluxDown · life-recorder · bank-sampah · 3x-ui_runonflux · the whole board →