mrkeyoor.com_
Tue 01 Sept 17:43 UTC
Self-Hostedevaluationupdated 25 Aug 2026

SpiderPanel review

SpiderPanel's README opens in Persian, but it includes full English documentation. It is a FastAPI dashboard for selling and managing VLESS subscriptions, Xray inbounds, browser-scanned addresses, and an optional Cloudflare Worker relay, with Railway acting as the suggested control-plane host.

+227stars / 7d
Verdict

Our SpiderPanel install pulled 66 packages and pip-audit found 34 known vulnerabilities, while the repository supplied no test target or CI workflow, so it is not ready for unattended production use as published. Its Railway control-plane and Cloudflare Worker design is useful for an experienced operator who will replace every default, audit the code, patch dependencies, and test quota and expiry enforcement. Everyone else should choose a more established panel and keep its management interface private.

We ran it

Lab card: what happened when we ran SpiderPanelScreenshot of SpiderPanel (github.com/amirh00sain/SpiderPanel)
Install✓ · 19s66 packages · 101 MB
Build✓ · 4s
Testsn/ano test script
Known vulns34(pip-audit)
Repo31 files~12,012 lines of source · 5.3 MB · 0 CI workflows · Dockerfile

Answers from our run

Does SpiderPanel build from source?

Dependencies installed in 19 seconds (66 packages), and the build succeeded in 4 seconds. We cloned commit a391c07 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 flagged 34 known advisories in the dependency tree at the time of our run.

Who should not use SpiderPanel?

Anyone who might expose the defaults: the README documents admin as the initial password and spider-panel-secret-key-v2 as the default session secret.

What are the alternatives to SpiderPanel?

3x-ui, Hiddify Manager, s-ui. Our SpiderPanel install pulled 66 packages and pip-audit found 34 known vulnerabilities, while the repository supplied no test target or CI workflow, so it is not ready for unattended production use as published.

Setup3/5Fast install and Railway recipe, with sensitive Worker configuration
Docs4/5Detailed bilingual setup, architecture, API, and security notes
Community2/5Recent push, but no releases, open issues, or visible triage
Maturity1/5No tests or CI, 34 advisories, defaults, and file-based state

Who it’s for

Experienced Xray operators who want users, subscriptions, quotas, and inbounds in one panel.
Persian-speaking or English-speaking self-hosters deploying a small service through Railway.
Operators who understand VLESS, Reality, TLS, Cloudflare Workers, KV, proxy sources, and credential scope.
Developers willing to audit a compact Python codebase and add their own security and behavior tests.

Who it’s NOT for

Anyone who might expose the defaults: the README documents admin as the initial password and spider-panel-secret-key-v2 as the default session secret.
Security-sensitive deployments that cannot remediate dependency findings: our pip audit reported 34 known vulnerabilities.
Teams requiring automated regression evidence: the repository has no tests directory, no CI workflow files, and no test target for our harness.
Operators unwilling to grant Cloudflare permissions: Worker deployment needs Workers Scripts and KV Storage edit access, or a global API key plus account email.
Users who cannot inspect changing upstream proxy data: auto-sync fetches a third-party country list and redeploys the Worker with the resulting map.
Organizations that require an unambiguous license file: the README says MIT, but GitHub detects no license and the repository root has no license file.
Multi-operator services needing a database-backed audit trail: the documented state lives in spider_state.json, and the dashboard uses one administrator password.

Setup reality

In our sandbox at commit a391c07, installation succeeded in 19 seconds with 66 Python packages and 101 MB on disk. The detected build succeeded in 4 seconds. No test script or target existed, so tests were skipped. pip-audit reported 34 known vulnerabilities.

Railway deployment needs a persistent data directory, a new administrator password, a random session secret, and a public domain. Reality inbounds also depend on the Xray binary. The optional Worker path adds a Cloudflare token, account details, KV, a Worker domain, proxy-map maintenance, and secrets shared between panel and Worker.

The 31-file checkout includes a Dockerfile and Compose file but no CI workflows or tests directory. Its main state is a JSON file, private keys live under data/, and public subscription routes expose each user's generated configuration. Backups, permissions, token rotation, dependency patching, and access logging are operator work.

SpiderPanel combines an Xray panel with a Worker relay

SpiderPanel manages users, inbounds, groups, subscription pages, quotas, expiry, and generated proxy configurations. Normal users connect to Reality or WebSocket inbounds associated with the panel. Users assigned to the optional Worker route connect through a Cloudflare Worker, which checks their UUID and quota in KV before forwarding traffic through a chosen proxy address. Railway hosts management and configuration delivery rather than carrying Worker-routed user traffic.

The repository is small by platform standards: our checkout had 31 files, about 12,012 source lines, and occupied 5.3 MB at commit a391c07. Much of the application lives in a 346 KB main.py, with another 118 KB in pages.py. That compact shape makes a manual audit possible, but it also concentrates authentication, user management, configuration generation, Worker control, and state changes into a few large files.

The README is bilingual and unusually specific

A Persian introduction describes the panel, followed by extensive English documentation. The README covers Railway deployment, environment variables, Cloudflare permissions, traffic flow, supported configuration types, the browser scanner, API routes, project layout, and security notes. English-speaking operators are not left with a translated summary. They can follow the full setup and inspect how the panel says traffic and credentials move.

The documented interface handles up to 10 custom scanned configurations per user and lets a user select up to 3 proxy addresses. Auto-sync defaults to every 3,600 seconds and reads a third-party list described as covering 62 countries. Those numbers make the behavior concrete, but they also expose an external trust path: the panel parses changing data from GitHub and redeploys its Worker map. Pinning or reviewing that source is safer than treating it as configuration owned by the application.

What happened when we ran it

Our Python install succeeded in 19 seconds in a fresh Debian container with 3 CPUs and 8 GB of RAM. It installed 66 packages and used 101 MB on disk. The detected build completed in 4 seconds. For a 5.3 MB checkout, the installed environment is substantial but still manageable on ordinary development and CI machines.

No test script or target existed, so our harness skipped tests. The repository also had no tests directory and no GitHub Actions workflow files. pip-audit reported 34 known vulnerabilities. That is the strongest reason to pause: the application handles administrator sessions, user UUIDs, subscription links, private keys, Cloudflare credentials, quotas, and network routing, yet the published tree gives no automated regression path and carries a large advisory count.

A passing 4-second build does not offset those findings. Before any real users are added, an operator should patch or replace affected dependencies, rerun the audit, add authentication and authorization tests, and verify expiry and quota decisions at both the panel and Worker. Our run did not exercise a live Railway project, Cloudflare account, Xray process, or proxy route because the sandbox had no secrets. No claim about end-to-end traffic follows from the build result.

The defaults are unsafe outside a private trial

The Railway guide tells users to sign in with admin and change the password immediately. It also lists spider-panel-secret-key-v2 as the default session and hashing secret, with a warning to set a strong random value. These are documented defaults rather than hidden backdoors, but internet scans do not care about intent. Deploying first and fixing them later creates a window where the management panel may be predictable.

Private material extends beyond the 2 initial defaults. Reality private keys and application state are stored under the data directory. The Cloudflare token stays server-side and is removed from API responses, according to the README, but it still grants deployment and KV-editing powers. Public subscription routes return generated configurations for their identifiers. Operators need strong identifiers, restrictive file permissions, encrypted backups, token rotation, TLS, and access logs before inviting customers.

Cloudflare integration adds a second control surface

The Worker setup can verify an API credential, discover the account's Worker subdomain, create a KV namespace, deploy relay code, and copy active user records into KV. This is convenient because the panel owns the workflow from one screen. It is also privileged automation. A mistake in token scope, injected Worker template values, user synchronization, or deletion behavior can affect a separate Cloudflare account, not just the Python process.

Authentication supports either a scoped bearer token or a global API key with email. The recommended scoped token still needs Workers Scripts and KV Storage edit permissions. Worker-routed users depend on matching state in 2 places: the panel's JSON data and Cloudflare KV. Test what happens when sync fails, the token expires, KV is unavailable, quota changes race with a connection, or the Worker deploy succeeds only partially. The README explains the happy path but offers no automated suite for these failure cases.

Project health is too thin for a trust-heavy service

The repository was pushed on 2026-08-24, one day before this review, so the code is current. GitHub showed 0 open issues and pull requests, an issue-only search also returned 0, and there was no published GitHub release. For a project with 722 stars and sensitive responsibilities, an empty queue does not supply the maintenance evidence that active triage, tagged releases, and changelogs would provide.

Licensing needs cleanup too. The README ends with an MIT statement, while GitHub detects no license and the 31-file root listing contains no LICENSE file. A personal experiment may accept that ambiguity; a business should ask for a standard license file before relying on the permission grant. Combined with 34 audit findings and no tests, SpiderPanel is best treated as inspectable source for a controlled trial, not a ready-made subscription business backend.

Alternatives

ProjectWhat it isPick it when
3x-ui gh↗A multi-user Xray panel covering several protocols, quotas, and limits.pick this instead when a larger operator community and broader Xray protocol management matter more than Railway and Worker integration.
Hiddify ManagerA multi-user proxy management panel with broad protocol and deployment support.pick this instead when you need a more established panel with wider protocol coverage and installation guidance.
s-uiA web panel focused on managing sing-box services and users.pick this instead when sing-box is your chosen proxy core rather than Xray and Cloudflare Worker relays.

What people are saying

  1. [velocity-scout] amirh00sain/SpiderPanel

Sources

  1. SpiderPanel README
  2. SpiderPanel repository contents
  3. SpiderPanel Cloudflare Worker source

More self-hosted reviews

v2 · OpenShell · wigolo · Mindwtr · club-3090 · reclip · the whole board →