mrkeyoor.com_
Sat 17 Oct 13:34 UTC
Self-Hostedevaluationupdated 16 Oct 2026

SpiderPanel review

SpiderPanel manages Xray proxy accounts, subscription links and Telegram sales from a web dashboard. Its interface defaults to Persian and includes an English toggle, with English documentation in the README. It joins account limits and expiry to receipt approval and subscription delivery so operators can handle fewer steps by hand.

+69stars / 7d
Verdict

Our run of SpiderPanel installed 35 packages in 363 seconds and passed its build in 1 second, but no tests ran because the repository had no test target. Try it if you already sell Xray subscriptions through Telegram and can verify receipt approval, client imports and expiry yourself. Resolve the missing license and configure direct-launch credentials before adopting it for paying customers.

We ran it

Lab card: what happened when we ran SpiderPanelScreenshot of SpiderPanel (spider-panel-omega.vercel.app)
Install✓ · 363s35 packages · 38 MB
Build✓ · 1s
Testsn/ano test script
Known vulns0(pip-audit)
Repo28 files~21,051 lines of source · 8.5 MB · 0 CI workflows · Dockerfile

Answers from our run

Does SpiderPanel build from source?

Dependencies installed in 363 seconds (35 packages), and the build succeeded in 1 seconds. We cloned commit e20c384 into a clean Debian container with 3 CPUs and no project-specific setup.

Does SpiderPanel have tests you can run?

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

Does SpiderPanel have known vulnerabilities in its dependencies?

pip-audit found none in the dependency tree at the time of our run.

Who should not use SpiderPanel?

Sellers who require automatic payment verification: the README's purchase flow asks an administrator to approve uploaded receipts.

What are the alternatives to SpiderPanel?

Marzban, 3x-ui, wg-easy. Our run of SpiderPanel installed 35 packages in 363 seconds and passed its build in 1 second, but no tests ran because the repository had no test target.

Setup3/5363-second install succeeds; credentials, domain and storage need care
Docs3/5English and Persian guides; local example omits credential settings
Community3/5October 13 push; subscription and connectivity reports remain open
Maturity2/5No test target or CI workflows; no detected license or release

Who it’s for

Xray operators who already sell access through Telegram and want receipt approval connected to account creation and renewal.
Self-hosters comfortable managing public domains, HTTPS and persistent application data on a Linux VPS or Railway.
Operators who need subscription pages and QR delivery alongside node checks and IP/SNI scanning tools.

Who it’s NOT for

Sellers who require automatic payment verification: the README's purchase flow asks an administrator to approve uploaded receipts.
Operators deploying on disposable storage: the README says losing persisted Web Proxy keys and per-user secrets invalidates existing links.
Developers who expect the local launch example to choose safe credentials: main.py falls back to admin and a fixed secret unless configured, while the VPS installer generates credentials.
Organizations that require an explicit open-source license: GitHub detects none, and the inspected repository tree contains no LICENSE file.
Teams moving paying customers without client checks: open issues 3 and 10 report subscription-import timeouts and generated configurations failing to ping on a mobile network.

Setup reality

Our October 14, 2026 sandbox run of e20c384 installed 35 packages in 363 seconds, using 38 MB on disk. The build succeeded in 1 second. Tests were skipped because no test script or target existed, and pip-audit reported 0 known vulnerabilities.

Telegram sales need a bot token, numeric administrator IDs and plan/payment settings. Public subscriptions need a real hostname and HTTPS. Set ADMIN_PASSWORD and SECRET_KEY for a direct launch: the application otherwise uses fixed defaults, while the VPS installer generates credentials. Preserve DATA_DIR, and share SPIDER_TWP_SIGNING_KEY across replicas.

The panel fixes its internal port at 8080 and ignores a provider's PORT value. Our sandbox used Python 3.12; the Dockerfile uses Python 3.13 and builds MTProxy, so the successful sandbox build does not verify that container path. Persistent storage is necessary to retain Web Proxy links across deployments.

Telegram sales are the reason to choose SpiderPanel

Approve a payment receipt in Telegram, and SpiderPanel can deliver the customer's proxy subscription and QR code. That is its clearest selling point. The panel joins Xray account administration to the work of selling access: plans have their own price, traffic allowance and expiry. If you currently copy account details between a proxy dashboard and Telegram conversations, this is a plausible replacement for that routine.

Our checkout contained 28 files and roughly 21,051 lines of source, so the small file count hides a substantial application. FastAPI handles accounts, subscription pages, node management and scanners. The interface defaults to Persian, with an English language toggle, and the README includes English documentation. English-speaking operators can assess it without translating the instructions, though they should try the interface before committing their support workflow to it.

What happened when we ran it

Our sandbox installed SpiderPanel commit e20c384 in 363 seconds, adding 35 packages and using 38 MB on disk. The build succeeded in 1 second. We ran it on October 14, 2026, in an unprivileged Debian container with 3 CPUs, 8 GB of RAM and no secrets, using the ghcr.io/astral-sh/uv:python3.12-bookworm image. Installation and build both completed successfully.

Pip-audit reported 0 known vulnerabilities. Tests were skipped because the repository had no test script or target, and the scan found no tests directory or CI workflow files. A Dockerfile was present. The checkout occupied 8.5 MB before installation. These measurements establish that the dependency and build steps worked in that environment. They do not establish working subscriptions, successful Telegram delivery, proxy throughput or reliable account expiration.

Direct launches need credentials the VPS installer generates

The authentication code at e20c384 reads ADMIN_PASSWORD and falls back to admin when it is absent. SECRET_KEY also has a fixed fallback. The VPS installer generates credentials, so that criticism belongs specifically to an unconfigured direct launch, including the README's local Uvicorn example. Set both values before making that route public. A stored password hash can override the initial password on subsequent starts.

The 0-known-vulnerability audit result does not assess those application defaults. SpiderPanel's own security notes call for HTTPS and restricted administrator access. Its Dockerfile uses Python 3.13 and builds Telegram's MTProxy binary, whereas our sandbox used Python 3.12. The successful sandbox build therefore leaves the documented container deployment unverified. Treat the installer, local Python route and Docker image as different deployment paths when deciding what evidence you still need.

Subscription links depend on a stable public domain and storage

SpiderPanel listens on port 8080 and deliberately ignores a provider-supplied PORT value. Railway or your reverse proxy must route traffic accordingly. The deployment and Web Proxy documentation explains how the public hostname feeds subscription links and the built-in Telegram Web Proxy. That proxy shares the panel's public HTTPS and WebSocket endpoint, so exposing a dashboard successfully is only part of configuring usable customer links.

The 38 MB installed environment excludes the operational problem of preserving customer state. DATA_DIR defaults to /data, where the application stores its state and the fallback Web Proxy signing key. The README warns that ephemeral storage invalidates existing Web Proxy links, and replicas must share SPIDER_TWP_SIGNING_KEY. That rules out a disposable deployment with no persistent volume. Back up the state and check that an existing customer's link survives a restart before accepting payments.

Receipt approval remains manual, and imports have an open report

The Sell Bot asks customers to upload a receipt for administrator approval. It can associate accounts with numeric Telegram IDs, update existing accounts and separate activation from message delivery. Those are useful provisions for an operator handling renewals. They don't turn the documented purchase flow into automatic payment verification. Someone still has to decide whether a receipt deserves approval, and customers still need help when a delivered configuration fails.

Our 363-second installation cannot answer those delivery questions. Issue 3's subscription-import report includes connection timeouts followed by invalid subscription content. Issue 10's connectivity report says generated configurations do not ping on the reporter's mobile network. Both remain open. Neither establishes a universal defect or its cause, but they justify checking a real client on the network your customers use before moving existing accounts.

Recent pushes show activity; licensing remains unclear

The repository's last push was October 13, 2026. GitHub listed 1,941 stars and 3 open issues and PRs; the fetched discussion list identified all three open items as issues, with updates on October 11. One concerns forking rather than proxy behavior. The latest-release endpoint returned no published release. Taken together, the push and discussion dates show recent activity, while the missing release leaves operators without a published release to select.

Our scan found 0 CI workflow files, which limits the visible automated checks supporting that activity. GitHub also reported no detected license, and the inspected tree contained no LICENSE file. Organizations requiring an explicit open-source license should resolve that before adoption. A public repository and a successful build are insufficient grounds to assume the project's licensing terms. Pinning e20c384 preserves the reviewed snapshot, but it doesn't resolve either concern.

Choose a narrower panel if Telegram sales add no value

Marzban is a direct alternative for Xray user administration. 3x-ui suits operators choosing around protocol and inbound controls, while wg-easy fits a simpler WireGuard VPN requirement. SpiderPanel earns a trial when receipt approval and subscription delivery are work you actually do. Before transferring paying customers, approve a sample order, import its subscription on the intended network, and confirm that expiry removes the account as expected.

Alternatives

ProjectWhat it isPick it when
MarzbanAn Xray-based panel for proxy user and subscription management.pick this instead when Xray account administration matters more than the documented Telegram receipt workflow.
3x-ui gh↗A multi-user proxy panel with controls for multiple protocols and inbounds.pick this instead when protocol and inbound administration are your main selection criteria.
wg-easy gh↗A web administration interface for a WireGuard VPN.pick this instead when you need a personal or team WireGuard VPN without Xray subscription sales.

Sources

  1. SpiderPanel README and English deployment documentation
  2. SpiderPanel authentication, fixed port and persistence source
  3. SpiderPanel VPS installer credential generation
  4. SpiderPanel Dockerfile
  5. SpiderPanel Persian default and English interface toggle
  6. Issue 3: subscription import timeouts and invalid content
  7. Issue 10: generated configuration connectivity report
  8. SpiderPanel repository metadata and license status

More self-hosted reviews

playport · edge-smart-doh · Comma · ProsperoEden · zulu · node_exporter · the whole board →