MineAdmin is a Hyperf and Vue admin skeleton with a plugin market

An admin panel sold as a starting point, not a product

MineAdmin is described as a ready to use back office management system, suited to quickly building website admin panels, operations platforms, permission centres, internal management systems, CMS, CRM, OA and ERP style business applications.

The framing is deliberate. The documentation says it already contains the capabilities a company admin commonly needs, organisation, users, permissions, menus, logs, attachments and an app marketplace, and that you can use it directly to run the business or build on top of it to add your own modules, spending more time on the business itself.

So the value proposition is time to first screen. A team that needs an internal tool with login, roles, menu permissions and audit logs would otherwise spend weeks on that scaffolding. Here it is already there, in a stack the README describes as a separated front and back end architecture with adaptive multi terminal support, and the project description highlights two features that make it more than a scaffold: back end CRUD generation, and front end low code configuration expressed as JSON.

The technology choices are visible in the acknowledgements and in the dependencies. The back end is PHP on the Hyperf framework with Swoole, the front end is Vue with Vite and Element Plus, and the topics list includes swoole and swow alongside hyperf and vue. The project is distributed under Apache 2.0, and the default branch is 3.2, which is the current major line.

The audience is a team that speaks PHP and Vue, that has decided to build an internal application, and that would like the boring half of the work finished. The demo is at demo.mineadmin.com with the account admin and the password 123456, and the documentation asks you to use the demo environment for trying things and not to add unrelated data to it.

Four permission layers, and the fourth is the interesting one

The accounts and permissions section is the heart of the system, and it is worth reading closely because the fourth layer goes beyond the usual three.

User management covers adding, editing, deleting, disabling, initialising the password and assigning roles. Role management assigns menu permissions and button permissions per role, controlling which parts of the interface a person can reach and which actions they can take. Menu management maintains the backend menus, the routes, the button permissions, external links, iframe pages, ordering, caching and hidden state. Login authentication provides the admin login, token validation, permission validation and a way to fetch the current user.

Then there is data permission, which can be set per position or per user so that different members only see the data inside their own scope. That is a different kind of control from the first three, which are all about the interface. Menu and button permissions decide what a person can click; data permissions decide what they can see once they are inside. A system that has the first kind and not the second leaks data through a list view, which is why the data scope is the part to evaluate.

The organisation section supports that layer. Department management maintains the hierarchy of companies, institutions and teams. Position management maintains positions under a department and assigns users to them. Leader management lets a department have a responsible owner, which supports tracking of management responsibility. And there is a personnel view that shows the users associated with a department, so you can see the distribution of people across the structure.

The audit section closes the loop. There is a login log recording login time, IP, browser, status and a message, an operation log recording key operations with the request method, the route visited, the business name and the time, and a permission audit that combines roles, menus, buttons and data permissions to help locate where a user's access came from.

Attachments, a data centre, and an app marketplace

Two subsystems turn the admin panel into something you could build a product on.

The first is the application extension layer. The app marketplace lets you browse apps, plugins and front end components and download, install or uninstall them as needed. Local applications lets you see what is installed and upload a local app package. And plugin extension is described as the way to package an independent business capability as a plugin, which reduces the number of changes to the main system.

That is a real architectural commitment rather than a feature list, because a plugin that can add a menu, a permission set and a data model is a plugin that needs a stable extension contract, and the frontend half of that contract is the JSON configuration the project description highlights. A marketplace also implies a trust model, and the presence of a MINE_PLUGIN_UPLOAD_ENABLED flag in the environment example suggests the upload path is something you switch on deliberately rather than something that is always open.

The second is the data and file layer. Attachment management gives a single place for uploaded files and images. File upload provides the backend upload entry point and records who uploaded what. And the data centre is described as a unified management entry point for later business data, file resources and extension modules, which reads as the future home for a domain model that does not exist yet.

The background experience section is what an administrator actually touches all day. There is a workbench with data dashboards, analysis pages and report pages as examples of an admin home page, and a personal centre for profile details and password changes. Multi language is built in with Simplified Chinese, Traditional Chinese and English resources. Themes and layout cover light, dark, follow the system, a theme colour, and classic, split and mixed layouts. And the common interaction set is the list of things every admin has rebuilt at some point: tabs, breadcrumbs, fullscreen, search, notifications, quick entries, a watermark and a back to top button.

Installing is one composer command, and the environment is specific

The quick start is short. MineAdmin uses migration files to complete the installation and the seed data, so there is no manual SQL import, and the only prerequisite stated is that Composer is installed locally:

composer create-project mineadmin/mineadmin --keep-vcs

The environment requirements are then listed, and they are worth reading before you start because they are more specific than a typical PHP application. You need PHP 8.1 or newer, Swoole 5.0 or newer with the Short Name setting turned off, Redis 4.0 or newer, and one of MySQL 5.7, PostgreSQL 10 or SQL Server. Git 2.x is also required.

The Swoole requirement is the one that surprises people, because Swoole is not a typical PHP extension that you install and forget. It is a coroutine based network engine, and the Short Name setting in particular is a known source of trouble with some extensions and frameworks, so the documentation calls it out explicitly rather than leaving it to be discovered.

The database choice is genuinely open, which is unusual for an admin scaffold, and it is the sort of thing that comes from the Hyperf ecosystem rather than from the template itself.

For a first look without installing anything, the online demo is the fastest route, and the documentation site at doc.mineadmin.com carries the fuller installation, configuration, deployment and development instructions. The project also asks you to read and agree to a declaration, the disclaimer, before using it, and the disclaimer text in the repository states that the software must not be used to develop software and applications that violate the applicable national policies, and that any legal responsibility arising from use is with the user rather than with the project.

The compose file is a Swoole service, not a PHP one

The docker-compose.yml in the repository root is short and shows what the running system needs. It declares a project name, two named volumes for Redis and MySQL data, and three services.

Redis runs on redis:7.2-alpine with the appendonly flag set, a memory limit of 1G, a healthcheck using redis-cli ping, and a ten second interval. MySQL runs on mysql:5.7 with utf8mb4 as the server character set and utf8mb4_unicode_ci as the collation, and the default authentication plugin set to mysql_native_password, which is what the application expects from the 5.7 line.

The application service is not a plain PHP image. It is hyperf/hyperf:8.1-alpine-v3.18-swoole, with the repository mounted at /www as the working directory, and port 9501 published. The command sets the timezone and then holds the container open with a tail on /dev/null, which is the shape of a development compose file where you exec into the container and run the server yourself.

The port number is worth noting because it is the one the environment file also uses, with APP_URL set to http://127.0.0.1:9501.

The Dockerfile follows the same base image and adds the application configuration. It writes an ini override with upload_max_filesize and post_max_size at 128M, a memory_limit of 1G and the date.timezone, links the timezone file, clears the package cache and the temporary directory, and installs a set of Alpine packages including the PHP development extensions. It also compiles the xlswriter PECL extension, which is the spreadsheet writer, and it carries a label with the maintainer as MineManage Developers, a version of 1.0 and the MIT licence, and the application name MineManage.

The environment file shows what is optional and what is not

The .env.example in the repository is short, and each line tells you something about the design.

At the top are the application settings: APP_NAME set to MineAdmin, APP_ENV as dev, APP_DEBUG false even in the example, and two Swagger switches, SWAGGER_ENABLED and SWAGGER_AUTO_GENERATE, both false. So the API documentation is opt in, and separately, regenerating it automatically is opt in again.

Then MINE_PLUGIN_UPLOAD_ENABLED, which is the switch that governs whether local application packages can be uploaded, and which is off in the example. That is the market plugin path being deliberately closed by default.

The database block is MySQL with the host mysql, which matches the compose service name, port 3306, the database mineadmin, the user and password both root, the utf8mb4 charset and the utf8mb4_unicode_ci collation, and an empty table prefix. The Redis block points at the redis service on 6379 with no auth and database zero.

Then APP_URL, and the two secrets. JWT_SECRET holds a long base64 value in the example, and MINE_ACCESS_TOKEN is set to (null) with the comment that it should be your own token. Those two lines are the ones to change before anything else, and the example JWT_SECRET is a published value, so copying it into a real deployment means anybody can sign tokens for it.

The rest of the repository shows the shape of the project. There is an app directory for the application code, config, databases for the migrations and seeds, a plugin directory for the extension mechanism, storage, bin, tests with a phpunit.xml.dist, a phpstan.neon.dist for static analysis, a .php-cs-fixer.php for style, and a .phpstorm.meta.php for IDE support. There is a .devcontainer directory, a Dockerfile, a docker-compose.yml, a deploy.test.yml, and a .coderabbit.yaml for automated code review.

Release rhythm, and the branch that carries the current line

The repository is not archived, and the last push was on 2026-09-15. The release history shows v3.2.0 on 2026-07-20, preceded by v3.2.0-alpha.1 on 2026-06-09 and v3.2.0-alpha.2 on 2026-06-12.

Two alphas and a final within six weeks is a normal pre release cadence for a framework level version, and the fact that the default branch is 3.2 tells you the current development line matches the current release line rather than sitting ahead of it. The documentation site is the place where the full changelog lives.

The licence is Apache 2.0, in the LICENSE file at the root. For a commercial team that is the simplest possible answer, and it is worth noting that the Dockerfile label says MIT, which is a different licence name, so the LICENSE file rather than a container label is what governs.

Two operational details deserve attention. First, the requirement of Swoole with Short Name disabled means your hosting platform has to be able to run a Swoole extension with that setting, which rules out a lot of cheap shared PHP hosting and pushes you towards a container, a VM or a platform with Swoole support. Second, the project explicitly asks users to read and agree to the declaration before use, and the repository includes a disclaimer about what the software must not be used for. That is an unusual thing to find in an open source admin scaffold, and it is worth taking seriously when you evaluate who is allowed to run it inside your organisation.

The final judgement is that MineAdmin is a well scoped starting point for PHP teams, with the permission model and the audit trail already thought through, and the cost is a specific runtime stack, a set of opinions about how an admin panel should be built, and a plugin architecture you will live with.

Editorial conclusion

MineAdmin is worth adopting if you are building an internal admin, an operations platform or a CRM and you would rather start from a working permission model than from a blank project, because the organisation, role, menu, data scope, audit and attachment layers are already coherent. It is the wrong choice if your team does not want a Swoole based PHP stack, if you need a licence that is unambiguously Apache 2 with no additional terms, or if you intend to build a highly specific workflow that the CRUD generator will not cover. Before you install it, read the disclaimer the project asks you to accept, plan the JWT_SECRET and MINE_ACCESS_TOKEN values in your.env rather than copying the example ones, and note that the current release is v3.2.0 from 2026-07-20 while the last push was on 2026-09-15.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mineadmin/MineAdmin on GitHub
3. Project website
4. README
5. Releases