# ProxyPanel: a Laravel panel for selling proxy subscriptions

> ProxyPanel is a PHP and Laravel 10 web application that manages several proxy protocols behind one user-facing panel, with multi-payment handling, account management, product models and admin notifications. It ships the protocol servers as separate components and the panel as the control plane.

**ProxyPanel/ProxyPanel** — A web application managing multiple proxy protocols, including features like multi-payment systems, account management, admin notifications, and product models.

- Repository: https://github.com/ProxyPanel/ProxyPanel
- Website: https://proxypanel.ddo.jp
- Stars: 541 · Forks: 169
- Language: PHP
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/proxypanel-proxypanel

## What ProxyPanel is, and what it is not

The repository description calls ProxyPanel a web application managing multiple proxy protocols, including features like multi-payment systems, account management, admin notifications and product models.

That phrasing sets the boundary correctly. ProxyPanel is the control plane for a proxy service: users, subscriptions, plans, orders, payments and the notifications that go out when something changes. The protocols themselves are separate components.

The README lists the supported protocols as Shadowsocks, ShadowsocksR, ShadowsocksRR, V2Ray, Trojan, VNET and Hysteria2. The topic tags add the ones the description leaves implicit, including VLESS, and the tags also carry sspanel and v2board, which are the community panel projects this one follows in lineage.

So the architecture is the familiar one for this category of software. A protocol server runs on a node and does the actual proxying. The panel is the website a customer logs into to buy a plan, and the server nodes fetch their configuration from it. ProxyPanel is the second half.

That distinction matters when you evaluate the project, because the operational requirements in the README are the panel's requirements, not the nodes'. Memory is listed as 1G+ and disk as 10G+, which is the size of a small web application with a database, not the size of a bandwidth node.

There is a demo deployment at proxypanel.ddo.jp, and the README states it runs the dev and latest code for demonstration purposes, with test credentials given for the account test@test.com and password 123456. A live demo with published credentials is worth treating as exactly what it says it is, since it is the development branch rather than a stable release.

The primary language is PHP, the licence is GPL-3.0, the default branch is master, and the recent releases are V3.2.0 from 2026-10-19, V3.1.0 from 2026-10-03 and V3.0.0 from 2023-11-27. The last push was on 2026-10-19.

## The requirement set, and what Laravel 10 implies

The Requirements section is specific, which is useful when you are sizing a machine.

The project is based on Laravel 10 Framework and therefore requires all Laravel 10 dependencies. That means PHP 8.1+ with a list of extensions: Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer, XML and Redis. Composer 2.2.0+ is required as well.

The database can be any one of several engines, which is an unusual amount of choice for a Laravel panel. MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10.0+, SQLite 3.8.8+ or SQL Server 2017+ are all listed, each with a link to that project's version policy. Redis is listed separately and is not optional in the list, which the environment file confirms.

The .env.example shows why. The cache driver, the queue connection and the session driver are all set to redis.

```bash
BROADCAST_DRIVER=reverb
CACHE_DRIVER=redis
FILESYSTEM_DISK=local
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
SESSION_LIFETIME=120
```

So the panel stores its state in Redis for three separate purposes. That is the same infrastructure the Laravel Reverb broadcasting server needs, and the environment file also carries the Reverb configuration, including REVERB_APP_ID, REVERB_APP_KEY, REVERB_APP_SECRET and REVERB_SCHEME.

The session lifetime of 120 is a two-hour session, which is a reasonable default for a panel that hands out connection details.

The environment file also reveals the shape of the application better than the README does. There is a block of IP lookup credentials for four different providers, which is what a panel needs to display a customer's resolved location, and the lookup provider keys can be set individually. There is a contact Telegram link, and two variables for self-hosted probe servers, one for domestic and one for foreign.

The proxy servers are not in the panel, but the panel still needs to reach them to fetch node configuration and to report status. That is what the probe server variables are for, and it is a reminder that a panel deployment is a multi-host arrangement even though only one machine runs the PHP.

## The Reverb path configuration and the single-source rule

One part of the environment file is worth reading carefully, because it documents a deployment decision that is easy to get wrong.

The comment on REVERB_PATH explains that it is the single source of truth for sub-path deployment. Leaving it empty means Reverb runs directly on its own port or subdomain, which is the recommended arrangement. When you do need to mount it under a sub-path, you write only the canonical form, a leading slash with no trailing slash, for example REVERB_PATH=/casting, and let nginx forward that prefix unchanged. After changing it you run php artisan optimize and then php artisan reverb:check to verify.

The file is explicit that the derived values VITE_REVERB_PATH and REVERB_SERVER_PATH are interpolated from REVERB_PATH and must not be edited separately.

That is a small but telling piece of documentation. It names the exact failure mode, which is a deployment where the path is configured in two places and the two disagree, and it names the command that catches it. The comment also explains why the canonical form matters, since nginx has to forward the prefix unmodified and a trailing slash or a missing leading slash changes what the server sees.

The session cookie behaviour is documented the same way. The comment states that the session cookie is only allowed over HTTPS, that leaving the line out defaults to true, and that an HTTP site must set it explicitly to false, with a warning that writing an empty value means false and will not fall back to the default.

That last detail is a genuinely useful trap to have documented. An empty value in an environment file is falsy in PHP, so a well-meaning operator who clears the line to get the default instead disables secure cookies entirely. The comment says so.

The same file also documents the API token expiry behaviour, where a SANCTUM_TOKEN_EXPIRATION value in minutes applies only to newly issued tokens and does not invalidate tokens already handed out, with a note that clients needing long sessions should raise it or re-authenticate using the expire_in value from the login response.

## Repository layout, installation scripts and the front end build

The tree is a standard Laravel application with a few additions that tell you about the project.

There is app/, bootstrap/, config/, database/, public/, resources/, routes/, storage/ and tests/, alongside the artisan console, composer.json, phpunit.xml and vite.config.js. The files specific to this project are install.sh at the root, plus update.sh and update-quick.sh, and a scripts/ directory.

The presence of install.sh, update.sh and update-quick.sh suggests the panel is deployed by running scripts rather than by a package manager workflow. Two update scripts rather than one implies a distinction between a routine update and a faster one, which is a common pattern for panels that need to pull server components or run database migrations as part of the upgrade. The README does not document what these scripts do, so their exact behaviour is something you would need to read before running them on a live install.

The front end is Blade templates compiled by Vite, and the package.json shows how that works.

```json
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "format": "npx prettier --write resources/views/**/*.blade.php"
  }
```

The format script runs Prettier over the Blade views with a dedicated plugin, @shufo/prettier-plugin-blade, which is why that plugin is in the dev dependencies. There is also a .prettierrc at the root, so the formatting rules are shared with the rest of the project.

The rest of the dev dependencies are the Laravel broadcasting and real-time stack, with laravel-echo on the server side of the pairing and pusher-js on the client, laravel-vite-plugin for the Vite integration, axios for HTTP, and Vite itself.

The pusher-js pairing with the Reverb driver in the environment file is the interesting combination. Laravel Reverb is Laravel's own WebSocket server, and pusher-js is the client library for the Pusher protocol that Reverb speaks. So the panel can use a self-hosted broadcast server without depending on the hosted Pusher service.

The .env.example sets BROADCAST_DRIVER=reverb, and the file also carries a commented REVERB_SERVER_PORT with a note that the Reverb backend defaults to 8080 and the front end to 443 or 80 depending on REVERB_SCHEME.

## Multi-payment, product models and admin notifications

The feature list in the repository description names four things, and they are the parts of a panel that differentiate one from another.

Multi-payment systems matter because the customers of a proxy service are spread across payment providers, and a panel that supports only one either excludes customers or loses conversion. The description names this as a headline feature rather than an afterthought, which tells you it was a requirement rather than an extra.

Account management is the part that has to be right. A panel holds subscription credentials and the details of how a customer connects, and the accounts are the link between a payment and a working subscription. The .env.example shows the client side of that with a Sanctum token expiry setting, so the panel issues API tokens to clients and can expire them.

Product models is the plan system, which is where a reseller's business logic lives. A panel that supports plans, pricing periods, traffic allowances and device limits is a product catalogue with an administration interface, and it is what turns a subscription service into something you can sell several kinds of subscription through.

Admin notifications cover the operational side, so the person running the service hears about the events that need a human: a failed node, a subscription expiring, an unusual spike in traffic, a payment that needs review.

The release notes in the repository metadata give a sense of where the work has been going. V3.0.0 was the Laravel 10 release on 2023-11-27. V3.1.0 is labelled as security hardening and stability, dated 2026-10-03. V3.2.0, dated 2026-10-19, is labelled in Chinese as VNET alignment, traffic aggregation and an audit chain.

Those two labels describe what a multi-protocol panel has to solve. Traffic aggregation means the panel has to combine usage figures from several node types into one number the customer sees, and an audit chain means the panel records what happened in a way that can be reviewed later, which is what you need when money and access are involved.

The project also maintains a wiki at proxypanel.gitbook.io, with the update log and the Chinese and English versions, a Telegram channel, and an Upcoming board for planned work. Translation is handled through Crowdin, and the README asks for translators to help translate the project into other languages.

## Where ProxyPanel is the wrong choice

There are three limits, and the first is about what the panel does not include.

The first is that ProxyPanel is not the proxy service. The supported protocol list tells you which servers the panel speaks to, and each of those servers is a separate piece of software with its own configuration, its own traffic accounting and its own failure modes. Deploying the panel alone gives you a shop with nothing to sell. That is a deployment in two halves, and the second half is where the traffic and the operational risk live.

The second is the licence and the data. GPL-3.0 is the most demanding of the common open source licences for a commercial deployment, and it applies to the panel software itself. Separately, the panel holds the things that matter most about your customers: their accounts, their payment records and the credentials for their subscriptions. A panel is a high-value target for exactly the reasons any account system is, and the presence of a SECURITY.md in the repository tree indicates the project treats disclosure as a process rather than an afterthought. The demo deployment with published credentials and the dev branch behind it is a reminder to run your own instance rather than pointing customers at someone else's.

The third is the version story. The last push was on 2026-10-19 and the repository is not archived, so the work is current. But the release sequence has a long gap: V3.0.0 on 2023-11-27, then nothing until V3.1.0 on 2026-10-03. Three years of no tagged release followed by two in a fortnight suggests a long private period followed by an open release push, and it means you are choosing between an old tagged version and a recent one with a short track record.

Laravel 10 is a related consideration. It is not the newest framework line, and the version policy links in the README are there precisely because the underlying database and PHP versions have their own support windows. Pinning to Laravel 10 means pinning to that window.

The honest alternative for a smaller operation is not another panel but a much simpler arrangement. A single protocol server with its own subscription link and a static page, or a server that exposes its subscription configuration directly, avoids the entire account and payment layer for the case where a handful of customers need configuration files. That fails as soon as you need plans, multiple payment methods or self-service, which is precisely where a panel earns its cost.

The other alternative is a different panel. The sspanel and v2board tags in the repository topics point at the established lineage of this category, and choosing between them is a matter of protocol coverage, payment integrations and whether you want to maintain a fork. ProxyPanel's differentiators as described are the multi-payment handling, the product model system and the protocol coverage including VNET and Hysteria2, and the V3.2.0 traffic aggregation and audit chain work is the most recent addition to that list.

## Conclusion

Adopt ProxyPanel if you already run one of the supported proxy server components and want to replace a hand-rolled subscription and payment setup with a Laravel admin panel, since the panel handles users, plans and orders rather than traffic. Do not adopt it expecting a single package to deploy the proxy servers themselves. Before you install, note that Laravel 10 requires PHP 8.1+ with Redis and a MySQL-class database, and that the panel keeps user and payment data, so its own security posture is the thing to get right.

## FAQ

### What is ProxyPanel and which proxy protocols does it support?

It is a PHP web application built on Laravel 10 that manages multiple proxy protocols in one panel, with multi-payment systems, account management, admin notifications and product models. The README lists Shadowsocks, ShadowsocksR, ShadowsocksRR, V2Ray, Trojan, VNET and Hysteria2 as supported.

### What are the system requirements for ProxyPanel?

The project is based on Laravel 10 and needs PHP 8.1+ with the Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer, XML and Redis extensions, plus Composer 2.2.0+. The database can be MariaDB 10.3+, MySQL 5.7+, PostgreSQL 10.0+, SQLite 3.8.8+ or SQL Server 2017+, and Redis is required.

### How does ProxyPanel handle sub-path deployment for its WebSocket server?

REVERB_PATH is the single source of truth. Leaving it empty runs Reverb on its own port or subdomain, which is recommended, and when you need a sub-path you write only the canonical form such as /casting, let nginx forward that prefix unchanged, then run php artisan optimize and php artisan reverb:check to verify.

### What are the recent ProxyPanel releases?

V3.2.0 on 2026-10-19 covers VNET alignment, traffic aggregation and an audit chain, V3.1.0 on 2026-10-03 covers security hardening and stability, and V3.0.0 on 2023-11-27 was the Laravel 10 release. The last push was on 2026-10-19.

### What licence is ProxyPanel released under?

ProxyPanel is an open-sourced software licensed under the GPL-3.0 license, according to the README, and the LICENSE file is at the root of the repository.

## Sources

- [License: GPL-3.0](https://github.com/ProxyPanel/ProxyPanel/blob/master/LICENSE)
- [Project website](https://proxypanel.ddo.jp)
- [ProxyPanel/ProxyPanel on GitHub](https://github.com/ProxyPanel/ProxyPanel)
- [README](https://github.com/ProxyPanel/ProxyPanel/blob/master/README.md)
- [Releases](https://github.com/ProxyPanel/ProxyPanel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/proxypanel-proxypanel