# Jexpanel adds billing and polish on top of Pterodactyl

> Jexpanel, formerly Jexactyl, is a game server management panel built on Pterodactyl with Stripe and PayPal billing added, a Laravel and React front end, and a Docker image that builds the assets in one stage and the PHP runtime in another. It is a panel for hosting studios that want to charge players, and a fork of a fork for everyone else.

**Jexactyl/Jexactyl** — Jexactyl is a fast, advanced and customisable game management panel and billing system in one.

- Repository: https://github.com/Jexactyl/Jexactyl
- Website: https://jexpanel.com
- Stars: 545 · Forks: 219
- Language: PHP
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jexactyl-jexactyl

## It is Pterodactyl, plus the parts a paid host needs

The README is direct about the lineage: Jexpanel is a modern game server management panel built on Pterodactyl Panel, offering enhanced security, advanced customization and integrated billing with Stripe and PayPal right out of the box. The project was renamed, and the title line now reads Jexpanel, formerly Jexactyl, while the repository, the composer package identity and the database user in the example configuration still carry the older name. That is not a cosmetic detail for an operator: the .env.example still sets DB_USERNAME to jexactyl and the mail from name to Jexactyl, so a deployment based on the documented defaults will carry both names in its configuration. The audience is a hosting provider or a community that wants the standard game panel plus the commercial layer, not someone building a panel from scratch.

## The stack and the release cadence

The feature list names the stack directly: PHP, Laravel, TypeScript, React and Docker, described as a clean, user-friendly administrative interface, advanced authentication and security setups, and a project that is fully open-source and community-driven. The repository layout backs that up with an app/ directory for the Laravel application, routes/, config/, database/ and bootstrap/ for the framework side, resources/ for the frontend source, and a public/ directory for built assets. The tooling is visible in the top level too, with phpstan.neon for static analysis, phpunit.xml for the PHP test suite, .php-cs-fixer.dist.php for formatting, eslint and prettier configuration, tailwind.config.js and vite.config.ts for the asset build. The release history shows steady work: v4.0.5 on 2026-07-28, v4.0.6 on 2026-07-30 and v4.0.7 on 2026-08-18, with the last push on 2026-08-18 and the default branch set to develop.

## The frontend is a Vite and React app with an editor built in

The frontend package is a private workspace package named @jexactyl/jexactyl at version 4.0.0dev, using pnpm 9.0.6 as its package manager and requiring Node 16.13 or newer, and the scripts cover the usual loop: vite build for a production build, vite for development, vitest run for tests, vitest run --coverage for coverage, eslint for linting, tsc --noEmit for type checking, and a test:ui script that opens the Vitest interface. The dependency list is dominated by CodeMirror. Twenty separate @codemirror packages are present, covering languages including C++, CSS, HTML, Java, JavaScript, JSON, Markdown, PHP, Python, Rust, SQL and XML, plus the lint, search, autocomplete, commands and state packages that make up an editor. This is a configuration file editor in a game panel, and the breadth of the language list suggests the panel is expected to hold user-supplied server configuration for many different game stacks, not just its own.

## The Docker build is two stages and one discarded toolchain

The Containerfile shows how the project ships. Stage zero uses node:22-alpine to build the frontend assets with corepack, pnpm install and pnpm build, and the comment says that stage is discarded since Node is not needed in the final image. Stage one is php:8.4-fpm-alpine, and it copies the built assets across from the first stage with COPY --from=0 /app/public/build ./public/build. The runtime layer installs a wide set of system packages in one apk add, covering ca-certificates, dcron, curl, git, supervisor, tar, unzip, nginx, image and XML libraries, certbot with its nginx module and the mysql client, and then configures and installs the PHP extensions bcmath, gd, pdo_mysql and zip. Composer is fetched from its own installer, .env.example is copied to .env, and the bootstrap and storage directories are created and made writable before composer install runs with --no-dev and an optimized autoloader. The .env file is removed afterwards, and the resulting image ships a production distribution of Pterodactyl, as the comment on the first stage says.

## Scheduling, TLS renewal and the nginx configuration

The last part of the image build handles the operational details. The default php-fpm.conf is removed, and two cron entries are written: one running artisan schedule:run every minute with output discarded, and one renewing certbot certificates with the nginx plugin at 23 minutes past midnight each day. The nginx configuration is patched to disable the SSL session cache with a sed substitution, and the runtime directories for php and nginx are created. The project's own nginx virtual host is copied in from .github/docker/default.conf, which tells you the reverse proxy configuration ships with the repository rather than being something you assemble. Taken together, this is a fairly complete operational story: an app container that serves the panel over nginx and php-fpm, runs scheduled console commands, and renews its own certificate, with a separate service still needed for the game servers and the database.

## The environment defaults tell you what it expects

The .env.example is short and specific, and it is the fastest way to picture the deployment. The application runs with APP_ENV=production, APP_DEBUG=false and APP_ENVIRONMENT_ONLY=true, which is the flag that tells Laravel to read configuration from the environment rather than from cached config files, and APP_KEY is left empty for the operator to generate. The database is MySQL on 127.0.0.1 with the database named panel and the user jexactyl, Redis is on the same host at port 6379 with QUEUE_CONNECTION set to redis, and both the cache and the session driver are set to file. Mail is SMTP with TLS encryption and a no-reply sender named Jexactyl. Two keys stand out for a game panel: HASHIDS_SALT and HASHIDS_LENGTH, with the length set to 8, which is the scheme that turns internal server identifiers into short public identifiers so that a player cannot enumerate other players' servers. The salt is left empty in the example file, and the README does not explain how it should be chosen, so an operator has to work that out from the Hashids convention rather than from the documentation. A representative slice of the file looks like this:

```bash
APP_ENV=production
APP_DEBUG=false
APP_ENVIRONMENT_ONLY=true

DB_CONNECTION=mysql
DB_USERNAME=jexactyl

QUEUE_CONNECTION=redis
CACHE_DRIVER=file
SESSION_DRIVER=file
```

Mail is SMTP with TLS encryption and a no-reply sender named Jexactyl.

## Where Jexpanel is the wrong choice

Three cases. The first is a host with no billing, where adopting a large panel fork to handle payments you do not offer is a lot of surface area for nothing, and plain Pterodactyl with the standard panel is the smaller answer. The second is a team that wants upstream fixes to arrive on their own, since a fork on a develop branch means every upstream Pterodactyl change has to be merged by hand, and a panel handling player money and logins is exactly the kind of system where an unpatched base is a liability. The third is a payment flow outside Stripe and PayPal, because those two are the only gateways the README names and no alternative provider is described. Against the alternative of writing your own billing layer against the Pterodactyl API, the difference in approach is that Jexpanel puts checkout, invoices and the player-facing billing screens inside the panel itself, sharing the same session, database and user model, which saves integration work and makes the panel the single place where a player account lives. It also means the payment logic is inside the same codebase you now maintain, which is the cost.

## Conclusion

Jexpanel is a good fit for a game hosting operation that already runs Pterodactyl and now needs payment handling, invoicing and player self-service billing without writing a payment integration from scratch, and that is prepared to maintain a fork of an upstream panel. It is a poor fit for a host that has no billing to speak of, since you would be adopting a large application to solve a problem you do not have, and it is a poor fit for anyone who wants upstream Pterodactyl features to arrive automatically. Check three things before you commit: that the .env.example defaults match your infrastructure, because DB_CONNECTION is mysql, QUEUE_CONNECTION is redis and CACHE_DRIVER and SESSION_DRIVER are file, and that the payment providers you need are the two the README names, Stripe and PayPal, since no other gateway is described; that the licence question is settled for your use, because the repository carries a LICENSE.md and the frontend package.json declares MIT while the repository licence is recorded as a custom one; and that you are prepared to track a develop branch, since the default branch is develop and the recent release tags sit on the 4.0 line.

## FAQ

### What is Jexpanel and how does it relate to Pterodactyl?

Jexpanel, formerly Jexactyl, is a game server management panel built on Pterodactyl Panel. It adds enhanced security setups, advanced customization and integrated billing with Stripe and PayPal, and is described as fully open-source and community-driven.

### What technology does Jexpanel use?

The README lists PHP, Laravel, TypeScript, React and Docker. The frontend package uses Vite for the build, Vitest for tests, and the repository carries phpstan.neon, phpunit.xml, .php-cs-fixer.dist.php, eslint and prettier configuration.

### How does the Jexpanel Docker image build work?

The first stage uses node:22-alpine to build the frontend assets and is discarded afterwards. The second stage is php:8.4-fpm-alpine and copies the built assets across from the first stage, installs system packages and PHP extensions, installs Composer dependencies with --no-dev, and configures nginx, certbot renewal and the artisan scheduler in cron.

### What does the Jexactyl .env.example expect for infrastructure?

It sets DB_CONNECTION to mysql, QUEUE_CONNECTION to redis, CACHE_DRIVER to file and SESSION_DRIVER to file, with a MySQL database named panel and the user jexactyl. It also defines HASHIDS_SALT and HASHIDS_LENGTH, set to 8, which control the public identifiers used for servers.

### Which payment providers does Jexpanel support?

The README names Stripe and PayPal as the integrated billing options available out of the box. No other payment gateway is described in the documentation.

## Sources

- [Issues](https://github.com/Jexactyl/Jexactyl/issues)
- [Jexactyl/Jexactyl on GitHub](https://github.com/Jexactyl/Jexactyl)
- [Project website](https://jexpanel.com)
- [README](https://github.com/Jexactyl/Jexactyl/blob/develop/README.md)
- [Releases](https://github.com/Jexactyl/Jexactyl/releases)

---

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