SSPanel-UIM: a PHP panel for running a paid proxy service

The problem SSPanel-UIM is built to solve

Running a proxy service for other people stops being a networking problem and becomes an accounting problem. You need to know who is allowed to connect, how much traffic they have consumed, when their plan expires, and how they pay you. SSPanel-UIM is a web application that holds all of that in one place. The README describes it as a "multi-purpose proxy service management system" for Shadowsocks(2022), V2Ray, Trojan and TUIC, and lists user management, node management and a financial system as the core functions. The intended operator is someone running a small commercial or semi-commercial service, not a person who just wants a client on their laptop. The system requirements point the same way: Debian 11 or newer, Nginx with HTTPS, PHP 8.2+, MariaDB 10.11+ or MySQL 8.0+, and Redis 7.0+. That is a server stack, and the README asks for it explicitly rather than treating it as optional.

How the panel, nodes and subscriptions fit together

The repository layout tells you more about the architecture than the README does. There is app/, src/, config/, db/, public/, resources/, storage/ and tests/ at the top level, plus composer.json for PHP dependencies and update.sh for upgrades. That is a conventional PHP application: public/ is the web root, config/ holds settings, db/ holds schema, and storage/ is writable state. The README adds two pieces that matter for operations. First, a universal subscription interface that distributes json, clash, sip008 and sing-box formats, which means the panel generates client configuration rather than asking users to copy node details by hand. Second, a cron system described as refactored, where one command completes all scheduled tasks. Traffic statistics and expiry checks depend on that cron running on schedule, so a panel that is up but has a dead cron will show stale usage numbers. The README also claims deep LLM integration for ticket replies and document generation, with one-click access to OpenAI, Google AI and Anthropic. That is a feature most panels of this type do not ship, and it is worth treating as an add-on rather than a reason to pick the project.

Installing SSPanel-UIM: where the instructions actually are

The README does not contain installation steps. It states that complete installation and usage documentation is at docs.sspanel.io, and the repository ships an update.sh script for later upgrades. So the honest answer to "how do I install SSPanel-UIM" is: clone the repository, then follow the documentation site, because the README gives no commands. What the README does give is the environment you must have ready before any installer will work. PHP 8.2 or newer with OPcache and JIT strongly recommended, MariaDB 10.11+ or MySQL 8.0+ with strict mode disabled, Redis 7.0+, Git and Composer, and Nginx serving over HTTPS. The strict mode note is the one people miss: the README lists disabling strict mode as a requirement, not a suggestion.

git clone https://github.com/Anankke/SSPanel-UIM.git
cd SSPanel-UIM
composer install

Those three commands follow from the repository layout and the Composer requirement in the README; they are not copied from an install guide, because the README does not provide one. After them you still need to create the database, point config/ at it, and configure Nginx to serve public/. The README documents none of that, so treat docs.sspanel.io as the source of truth and expect to spend your first hour there rather than in the repository.

./update.sh

The update script is the upgrade path the repository ships. The README does not document what it does internally, whether it backs up the database first, or how it handles schema changes, so read the script before running it against a live panel.

Strict mode, cron and the failure modes that bite

The most concrete constraint in the README is the database one. MariaDB 10.11+ or MySQL 8.0+ is required with strict mode disabled. Disabling strict mode means the database will silently coerce or truncate values that would otherwise raise errors, which is a deliberate compatibility choice and also a data-integrity trade-off. If you later re-enable strict mode, or migrate to a managed database where you cannot change the setting, queries that worked on the panel may start failing. That is a real migration hazard and the README does not discuss it. The second failure mode is the cron dependency. Traffic statistics, expiry and billing all depend on scheduled tasks; the README says the cron system was refactored so one command runs everything, but it does not say what happens when that command stops. In practice the panel stays reachable while usage data goes stale, which is worse than an outage because nobody notices. The third case where SSPanel-UIM is the wrong tool is a single-user setup. If you are the only person connecting, the billing system, payment gateways and user management are dead weight, and a plain server configuration is less to maintain.

SSPanel-UIM compared with V2board and XrayR

The related searches around this project mix two different categories of software, and the distinction matters. V2board and Xboard are alternative panels: they also manage users, nodes and subscriptions, but they are built on a different stack, so choosing between them is mostly a question of which language and ecosystem you want to operate. XrayR is not a panel at all. It is a backend node program that connects to a panel and applies the configuration the panel sends, which is why people search for it alongside SSPanel-UIM rather than instead of it. The practical difference is deployment shape. SSPanel-UIM is a PHP application you deploy on Nginx with MariaDB and Redis behind it; a Go-based panel or backend typically ships as a single binary with fewer moving parts. If your team already runs PHP and MySQL, SSPanel-UIM fits an existing operational pattern. If you want one binary and no Composer step, the PHP stack is the reason to look elsewhere, not a detail you can work around.

Maintenance cost, the update script and the MIT licence

The last push to the repository was on 2026-09-16, and the repository is not archived, so the codebase is being touched. That is not the same as a stability guarantee, and the README does not publish a release or support policy. The upgrade path is update.sh, which means your maintenance cost is tied to how often you run it and how well the script handles your database. Because the README does not describe rollback, you should verify that yourself before upgrading a live panel, ideally by testing the script against a copy of the database first. The licence is MIT, which is permissive: it allows commercial use and modification, and it comes with no warranty. Running a paid proxy service also means dealing with payment gateways such as Alipay F2F, PayPal, Stripe and Cryptomus, and those integrations carry their own terms that the MIT licence says nothing about. None of this is legal advice; read the licence file and your payment providers' agreements.

Editorial conclusion

Adopt SSPanel-UIM if you already run Debian, Nginx, MariaDB and Redis and want billing plus subscription delivery in one PHP application; skip it if you want a single static binary or a panel you can audit in an afternoon. Before committing, verify your MariaDB strict mode setting, that PHP is 8.2 or newer, and that the installation steps on docs.sspanel.io match the master branch you cloned.

Frequently asked questions

Official sources

1. Anankke/SSPanel-UIM on GitHub
2. Issues
3. License: MIT
4. README