Xboard: A Laravel-Based V2board Fork for Proxy Service Panels

What Xboard Actually Is and Who Runs It

Xboard is a service panel, not a proxy protocol implementation. It is the control plane: accounts, plans, subscriptions, an admin interface and a user-facing portal. The repository describes it as "a modern panel system built on Laravel 11" and as a secondary development of V2board that supports new protocols and new features. That framing matters. If you are looking for a client or a server core, this is not it. If you are running a subscription business and need the billing, provisioning and account layer, this is the layer you replace.

The intended audience is existing V2board operators. The README ships three separate migration guides, from v2board dev, from v2board 1.7.4 and from v2board 1.7.3. That is a strong signal about who the maintainer expects to arrive. A fresh deployment is possible, but the documentation is organised around moving an existing installation rather than starting from nothing.

The Laravel 11 and Octane Architecture Behind the Panel

The stack is split into three parts that deploy separately or together. The backend is Laravel with Octane, and the Dockerfile builds from phpswoole/swoole:php8.2-alpine, which means Octane runs on Swoole rather than on the default PHP-FPM worker model. The admin panel is React with Shadcn UI and TailwindCSS. The user frontend is Vue3 with TypeScript and NaiveUI. Redis is used for caching and queues, and the environment file sets CACHE_DRIVER=redis and QUEUE_CONNECTION=redis by default.

The Dockerfile reveals more of the runtime than the README does. It installs Caddy and Supervisor, and it sets ENABLE_WEB, ENABLE_HORIZON, ENABLE_REDIS, ENABLE_WS_SERVER and ENABLE_CADDY to true. So a single container is expected to serve HTTP through Caddy, run Horizon for queue workers, and run a WebSocket server under Supervisor. That is a lot of process supervision inside one image, and it explains the README note that aaPanel installations must restart the Octane daemon process after configuration changes.

One inconsistency is worth flagging. The README's feature list says "Built with Laravel 12 + Octane", while the introduction and the tech stack section both say Laravel 11. The Dockerfile targets PHP 8.2. Treat the version claim as unresolved until you check composer.json in the branch you deploy.

Installing Xboard with the Compose Quick Start

The README's quick start clones a dedicated compose branch, not master, and runs the installer as a one-off container before starting the stack. The installer takes three environment variables: ENABLE_SQLITE, ENABLE_REDIS and ADMIN_ACCOUNT.

git clone -b compose --depth 1 https://github.com/cedar2025/Xboard && \
cd Xboard && \
docker compose run -it --rm \
    -e ENABLE_SQLITE=true \
    -e ENABLE_REDIS=true \
    -e [email protected] \
    xboard php artisan xboard:install && \
docker compose up -d

The first command pulls the compose branch. The second runs the xboard:install Artisan command in a temporary container with SQLite and Redis enabled and an admin account address supplied. The final command starts the stack in the background. According to the README, the panel is then reachable at http://SERVER_IP:7001, and it warns to save the admin credentials shown during installation. The image exposes port 7001, which matches.

For a non-Docker deployment, the repository also carries compose.1panel.sample.yaml, compose.host.sample.yaml, compose.split.sample.yaml and compose.sample.yaml, plus deployment guides for 1Panel, aaPanel, aaPanel with Docker, and plain Docker Compose. The README marks aaPanel plus Docker as recommended. The .env.example shows the manual route: MySQL on 127.0.0.1:3306 with database xboard, Redis on 6379, and INSTALLED=false as a reinstallation guard. Note that the sample .env ships a populated APP_KEY, which you should not reuse.

Upgrade and Migration Are Documented as Different Operations

The README puts an upgrade notice near the top and it is unusually blunt: the version involves significant changes, you should follow the upgrade documentation strictly, and you should back up your database first. It then adds that upgrading and migration are different processes and should not be confused. That distinction is the most important operational detail in the file. An upgrade moves your existing Xboard installation forward. A migration moves a V2board installation onto Xboard. Running the wrong one against a production database is the failure mode the notice is trying to prevent.

The repository includes an update.sh script at the top level, and .env.example carries ENABLE_AUTO_BACKUP_AND_UPDATE, GOOGLE_CLOUD_KEY_FILE and GOOGLE_CLOUD_STORAGE_BUCKET, so there is an automated backup-and-update path wired to Google Cloud Storage. It is off by default. The README does not document rollback, so plan your own database snapshot before you run either an upgrade or a migration.

Where Xboard Is the Wrong Choice

The maintenance notice is the first constraint. The README states the project is "currently under light maintenance" and lists what that means: critical bugs and security issues get fixed, important pull requests get reviewed and merged, and compatibility updates are provided. It then says new feature development may be limited. If your roadmap depends on the panel gaining capabilities on a schedule, that sentence is the answer.

The second constraint is scope. Xboard is a panel. It does not implement the proxy protocols themselves, and the README's protocol claim is a statement about what the panel supports, not about a data plane you get for free. The disclaimer reinforces the position: the project is described as "for learning and communication purposes only", with users responsible for consequences. That is not a support commitment.

The third constraint is operational surface. Swoole, Octane, Horizon, Redis, Caddy and a WebSocket server all run inside the shipped image under Supervisor. The README notes that changing the admin path requires a restart of the whole Compose stack, and that aaPanel installs need the Octane daemon restarted. On a single small host this is manageable. On a host where you already run other PHP services, the bundled Caddy and Supervisor configuration will compete with what is there, and the split Compose sample exists precisely because the all-in-one layout does not fit every environment.

Xboard Against V2board, and Against Staying Put

The honest alternative is the upstream project. Xboard is a secondary development of V2board, and the migration guides exist because the two share a lineage. Staying on V2board means you keep whatever operational familiarity and third-party integrations you already have, and you avoid a database migration whose failure mode is a broken production panel. It also means you do not get the Laravel 11 and Octane runtime, the React admin interface, or the Vue3 and TypeScript frontend that the README lists as the redesign.

The difference in approach is architectural rather than cosmetic. V2board's panel runs on the conventional PHP request model. Xboard runs Octane on Swoole, keeps state in long-lived workers, and pushes cache and queues through Redis by default. That changes how you debug it: a stale worker holds stale code until the process restarts, which is why the README insists on restarting after an admin path change. If your team's mental model is "edit a file, reload the page", the Octane model will surprise you at least once.

A second alternative is not migrating at all and running a fresh Xboard install beside the old panel, then moving accounts over deliberately. The README does not describe that path, but the installer supports a clean install with its own database, so the option exists without documentation.

Licence and What the MIT Terms Leave Open

Xboard is MIT licensed, and the LICENSE file sits at the repository root. MIT permits commercial use, modification, redistribution and private use, provided the copyright notice and permission notice travel with the software. It carries no copyleft obligation, so you can keep your own modifications closed. The practical consequence for a panel like this is that the licence does not constrain how you operate it, and it does not oblige the maintainer to support you either. The disclaimer in the README is separate from the licence and is where the maintainer places responsibility on the operator. This is a description of the terms, not legal advice; read LICENSE and the disclaimer yourself before a commercial deployment.

Editorial conclusion

Adopt Xboard if you already run V2board and want the documented migration path to a Laravel 11 and Octane codebase with a React admin panel and a Vue3 user frontend. Do not adopt it if you need new feature development on a predictable schedule: the README states the project is under light maintenance and that new feature development may be limited. Before committing, read the upgrade notice in the README, take a database backup, and confirm which of the four Compose sample files matches your deployment, since the README treats upgrading and migration as two different operations.

Frequently asked questions

Official sources

1. cedar2025/Xboard on GitHub
2. Issues
3. License: MIT
4. README