# Blueprint patches a Pterodactyl panel so extensions install without editing core files

> Blueprint is the framework half of a Pterodactyl extension platform, and this repository holds the panel patch it applies: a Bash CLI, a Laravel backend, a React and TypeScript frontend and a Blade admin UI. Extensions install into that patched panel instead of overwriting it, and the upstream project runs on Node 22 or newer.

**BlueprintFramework/framework** — Powerful, fast and developer-friendly extension framework for Pterodactyl. Utilize extension APIs, inject HTML, modify stylesheets, package extensions and so much more.

- Repository: https://github.com/BlueprintFramework/framework
- Website: https://blueprint.zip
- Stars: 570 · Forks: 48
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/blueprintframework-framework

## What the framework repository actually holds

The repository name is misleading if you expect a library. The What's in here section is explicit: the framework repository hosts the Blueprint patch that you apply onto your Pterodactyl panel. It overwrites files like installing a standalone addon would, but instead of being just that, Blueprint allows your panel to be extended through extensions.

That distinction is the product. A standalone addon for Pterodactyl copies files into the panel and expects the panel to stay the same. Blueprint applies its own patch first, and extensions are then written against that patched panel, so the compatibility work happens in one place rather than in every extension.

The implementation is split across four languages, and the README is candid about the split. Blueprint's CLI is written in Bash. The backend adds onto Pterodactyl's, and is written in PHP and Laravel. The user-side frontend adds onto Pterodactyl's, and is written in React and TypeScript. The admin-side frontend adds onto Pterodactyl's, and is written in PHP, Laravel and Blade.

The tree reflects that mix. There is app/, database/, routes/, resources/, public/, storage/, scripts/, a blueprint/ directory, blueprint.sh, webpack.config.js, tailwind.config.js, tsconfig.json, a .shellcheckrc for the Bash side and a .eslintrc.js for the TypeScript side. The package.json is named pterodactyl-panel, which tells you this is a fork-shaped project that extends the panel's own frontend rather than a standalone npm package, and it requires Node 22 or newer.

The primary language is TypeScript, the licence is MIT, the default branch is main, and the last push was on 2026-09-21. The recent releases are beta-2026-08 from 2026-08-14, beta-2026-06 from 2026-06-22 and beta-2026-05 from 2026-05-30, so the versioning is date-based and explicitly beta.

## The Bash CLI is a dispatcher, and the README says it used to be a monolith

The CLI is the part a server administrator actually runs, and its structure is described in detail.

The main script is blueprint.sh. This script gets called by /usr/local/bin/blueprint whenever a user runs the blueprint command, or queries bash autocomplete. It has four duties: finishing initial installation steps and updates, such as flushing cache and running artisan commands; sourcing CLI dependencies from scripts/libraries; running the right sub-scripts for each command from scripts/commands; and placing the Blueprint command shortcut to /usr/local/bin/blueprint.

The README then admits how this arrived: they used to do everything in the main CLI script, which overcomplicated everything a lot. Everything is now mostly designated to its own area.

That admission is worth more to a reader than the feature list. It tells you the current layout is a refactoring of a working tool rather than a greenfield design, and it tells you where to look when a command misbehaves: the sub-scripts in scripts/commands rather than the entry point.

The Bash side has its own quality gate, since the repository carries a .shellcheckrc. That file is for shellcheck, the static analyser for shell scripts, and its presence in a project with a Bash CLI is a reasonable baseline.

The one thing the CLI cannot do for you is install Blueprint itself, because that requires writing to the panel and running artisan commands. The README points at a separate installation guide hosted at blueprint.zip/guides/admin/install, and that guide is where the actual install steps live rather than in this repository.

## Extensions come from a registry, and the panel is patched around them

The ecosystem around the framework is what makes the patch worthwhile. Blueprint hosts a landing site and documentation at blueprint.zip, and a browse page where you find your next extension, and the README describes a growing ecosystem of extensions, from ones covering game features such as Minecraft and Hytale, to useful quality-of-life admin tools. The framework's own demo screenshot is in the README.

The value proposition in the introduction is aimed at developers on one side and administrators on the other. Developers create versatile, easy-to-install extensions, and system administrators can install them within minutes, usually even seconds, without having to custom-code compatibility across multiple panel modifications.

The platform is spread across multiple repositories, each with its own purpose. BlueprintFramework/docker is the image for running Blueprint and Pterodactyl with Docker. BlueprintFramework/templates is a repository with initialization templates for extension development. BlueprintFramework/web is the open-source source of documentation, landing website and API.

That last repository matters more than it sounds. The documentation site, the landing page and the API being in one open-source repository means the extension registry, the docs and the framework are versioned together in a way an administrator can read rather than only use. It also means the docs are inspectable: when the patch changes, the docs change with it in the same repository family.

The templates repository is the other half of the developer story. Initialisation templates are how an extension gets a scaffold, and the mention of a package manager in the repository topics suggests that distribution is the intended route rather than manual installation of each extension.

## A React 16 frontend with hot loader is dated, and that has consequences

The dependency list in package.json is where a careful reader should slow down, because it describes a frontend stack that predates current React by several major versions.

The React version is 16.14.0, with react-dom aliased to npm:@hot-loader/react-dom, and both @hot-loader/react-dom and react-hot-loader are present at 16.14.0 and 4.12.21. React Router is at 5.1.2, styled-components at 5.2.1, Tailwind at 3.4.17, and i18next at 21.8.9 with react-i18next at 11.2.1. Form handling is Formik at 2.2.6, state management is easy-peasy at 4.0.1, and charting is Chart.js at 3.8.0 with react-chartjs-2. There is sockette for the websocket, xterm for the terminal, qrcode.react for QR codes, codemirror at 5.57.0, and reaptcha for the captcha.

The hot loader combination is the most telling. hot-loader and react-hot-loader exist to reload components in place during development, which was a common pattern in the React 16 era and has largely been replaced by the fast refresh built into modern React tooling.

The Node requirement comes straight from the manifest:

```json
    "name": "pterodactyl-panel",
    "engines": {
        "node": ">=22"
    },
```

That sits oddly beside a React 16 dependency set, and the honest reading is that this frontend stack was inherited from the Pterodactyl panel it extends rather than chosen fresh. That matters for two reasons. If you are writing an extension with a modern React toolchain, you are mixing eras. And if you maintain the framework, you are carrying a dependency set whose upstream components have largely stopped receiving updates.

The good news is that the frontend is additive. The README says the user-side frontend adds onto Pterodactyl's, so the panel's own behaviour is preserved and the Blueprint additions sit on top, which limits how much of this stack an extension author has to touch.

## Where Blueprint is the wrong tool

Three limits, and the first is structural rather than technical.

The first is that this is a patch. The framework repository overwrites files in the panel, and while the extensions are then installed against the patched panel, the patch itself is a modification to someone else's software that has to survive every Pterodactyl upgrade. That is the cost the framework exists to reduce, not to eliminate: without it each extension would carry its own compatibility burden, with it you carry one.

The second is the beta and date-based versioning. The releases are beta-2026-08, beta-2026-06 and beta-2026-05, spread across spring and summer of 2026, and there is no stable line and no release notes describing what changed between beta builds. A panel administrator who upgrades Pterodactyl and then wants to upgrade Blueprint has to work out for themselves which patch applies and what it touches, because the versioning carries no compatibility information. The SECURITY.md file in the repository root suggests the project takes disclosure seriously, but it is a separate file from any changelog.

The third is the frontend stack age, described above. It is manageable if you treat the panel as a fixed target, and awkward if you want your extension to look and behave like a current React application.

The alternative approach is to write standalone Pterodactyl addons, which is what the framework is a replacement for. The difference in approach is that a standalone addon copies its own files into the panel and must be updated when the panel changes, while a Blueprint extension installs through a package manager against a panel that already carries the framework's patch. For an extension you write once and run on one panel, the standalone addon is less to set up. For an extension you distribute to many administrators on panels at different versions, the framework's model is the one that scales, which is the same reason the framework is sponsored by hosting companies rather than by individual administrators.

One caveat about the sponsorship. The README says Blueprint is free and open-source software, that the project plays a large part in the Pterodactyl modding community, and that it relies heavily on donations, and it is a nonprofit. A sponsor table in the README lists hosting providers. That is normal for an infrastructure project and it does not make the framework a commercial product, but it is the kind of thing a large operator should be aware of when they decide how much of their panel they want to depend on.

## Conclusion

Adopt Blueprint if you run a Pterodactyl panel and want to install extensions, themes and panel modifications from a package manager rather than by hand-editing core files, since the patch is applied once and extensions then install against it. Do not adopt it if your panel must stay byte-identical to upstream Pterodactyl, because the framework repository is explicitly a patch that overwrites files in the same way a standalone addon would, and do not adopt it without reading the update path, since a Pterodactyl upgrade is where the patch has to be reapplied. Verify first that the Node version on your build machine satisfies the >=22 requirement in package.json, that you understand what the patch overwrites before running it on a production panel, that the extension you want exists in the Blueprint registry rather than only as a standalone addon, and that the beta release cadence, currently beta-2026-08, matches what you are comfortable deploying.

## FAQ

### What is Blueprint and what problem does it solve for Pterodactyl?

Blueprint is an open source extension framework and manager for Pterodactyl. The framework repository holds the patch applied to the panel, so extensions can be installed by administrators within minutes without each extension carrying its own compatibility code across panel modifications.

### What languages is the Blueprint framework written in?

The CLI is written in Bash, the backend adds onto Pterodactyl's and is written in PHP and Laravel, the user-side frontend is written in React and TypeScript, and the admin-side frontend is written in PHP, Laravel and Blade.

### How do I install Blueprint on a Pterodactyl panel?

The README refers to the installation guide hosted at blueprint.zip/guides/admin/install rather than giving the steps in the repository, because installation writes to the panel and runs artisan commands. There is also a Docker image repository, BlueprintFramework/docker, for running Blueprint and Pterodactyl with Docker.

### What does the blueprint CLI script actually do?

The blueprint.sh script is called by /usr/local/bin/blueprint when a user runs the blueprint command or queries bash autocomplete. It finishes installation and update steps such as flushing cache and running artisan commands, sources dependencies from scripts/libraries, runs the sub-scripts in scripts/commands, and installs the command shortcut.

### What are the other repositories in the Blueprint platform?

Three are named in the README: BlueprintFramework/docker for the image running Blueprint and Pterodactyl with Docker, BlueprintFramework/templates for initialisation templates for extension development, and BlueprintFramework/web for the documentation, landing website and API.

### What Node version does the Blueprint frontend require?

The package.json declares the package pterodactyl-panel with engines node >=22. The frontend dependencies are older, with React at 16.14.0 and hot loader packages included, since the frontend extends the panel's existing stack rather than replacing it.

## Sources

- [BlueprintFramework/framework on GitHub](https://github.com/BlueprintFramework/framework)
- [License: MIT](https://github.com/BlueprintFramework/framework/blob/main/LICENSE)
- [Project website](https://blueprint.zip)
- [README](https://github.com/BlueprintFramework/framework/blob/main/README.md)
- [Releases](https://github.com/BlueprintFramework/framework/releases)

---

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