vue-material-admin is a full stack admin template for Vue and Nest

What the template is, in the author's own framing

The repository description says it all in one line: a concise, lightweight full stack admin template built on Vue 3, Vuetify, TypeScript, Nest.js, MySQL, TypeORM and Redis.

The README expands on it, and it is worth reading because it is unusually honest about the project's stage. It describes the project as an open source admin system template based on Vuetify components, developed as a Nest.js, Vue 3 and TypeScript full stack project, with the front end UI following the Material Design specification and building on top of Vuetify's base components with extensions and optimisations. The stated aim is a concise and lightweight admin solution, and the project says it is currently at a stage mainly used for learning, feature demonstration and development testing, while also being suitable as a starting template for production projects. The project will be kept updated with more features and optimisations.

That last sentence is the one to weigh. A template that says it is at the learning stage and also that it is a good production starting point is telling you both things at once, and the reader has to decide which one applies to them. In practice it means the code is well assembled but unproven in a real deployment, and the team adopting it inherits the job of making it production grade.

The repository is MIT licensed, the primary language is Vue, the homepage is a Vercel deployment, and there is an online preview linked as well. The last push was on 2026-07-21 and the repository is not archived, though the most recent tagged release is v2.2.3 from 2024-05-01, with the package.json version reading 2.4.1.

The stack, front end and server

The README has a technology stack section, and it is split into the front end and the server.

On the front end, the framework is Vue 3, state management is Pinia, and the UI is Vuetify. The badges confirm the versions: Vue 3.x, Vuetify 3.5.x and Vite 5.x.

On the server, the framework is Nest.js, the database is MySQL with TypeORM, and the cache is Redis. The Nest.js badge reads 10.x.

The package.json confirms all of it and adds a few things the README does not mention. The Vue dependency is 3.2.45, Vuetify is 3.6.7, pinia is 2.0.28 and vue-router is 4.1.6, with TypeScript pinned at 5.2.2 and Vite at 5.4.20. The build tooling is unplugin-vue-components for auto-import and vite-plugin-vuetify for the design tokens.

What stands out in the dependency list is the set of 3D and canvas libraries: @babylonjs/core at 6.33.0 with the havok physics plugin and the loaders package, three at 0.149.0 with @types/three, pixi.js at 7.3.2 with filter-displacement, graphics-extras and the ui package, ogl for WebGL, and stats-js for a frame rate counter. The screenshots in the README include a Babylon.js scene, and the repository topics list babylonjs, pixijs and threejs alongside the admin and material-design labels.

So this is an admin template that also ships a small 3D demonstration section, and the rendering libraries are first class dependencies rather than an afterthought. The chart library is apexcharts with a Vue 3 wrapper, and the mapping library is @amap/amap-jsapi-loader, the AMap JavaScript API, which is a Chinese map service and works as a single map component in a Chinese oriented admin panel.

Running it locally, and the mocked API

The local development section explains something that would otherwise confuse a new contributor: the front end runs against a mock server, not the real one.

Because the Nest.js server is already paired with the project, the local development environment uses apifoxmock to simulate all of the server's interfaces, so the .env.development file has to be configured with the API server address. If you want to develop and preview together with the server, the README points you at the Serve branch for the server start tutorial, and then tells you to change the .env.development server address to the local one.

The front end start sequence is four commands:

git clone https://github.com/armomu/vue-material-admin.git

cd vue-material-admin

pnpm install

pnpm run dev

pnpm is the package manager, and the package.json pins it at [email protected] with an integrity hash, so a team standardising on npm or yarn will have to work around that. There is a pnpm-workspace.yaml at the root, and a pnpm-lock.yaml alongside it.

The scripts in the package.json show how the build is organised. dev runs vite, build runs type-check and build-only in parallel with npm-run-all, build-only runs vite build and then node ./public/getVersion.js, and type-check runs vue-tsc with noEmit. The lint script runs eslint over .vue, .js, .jsx, .cjs, .mjs, .ts, .tsx, .cts and .mts extensions, with --fix and with .gitignore as the ignore path.

The environment files are committed at the root as .env.development and .env.production, which is convenient for a template since the values are placeholders rather than secrets, and it also means the API endpoint is visible to anyone who clones the repository.

The feature checklist, and what is not done

The README carries a TODO list with checkmarks, and reading it as a status report is more useful than reading it as a feature list.

The Vuetify component section has Card, Form, Data Table, Calendar, Menu and Tree marked done, with the rest still loading. The optimisation section has dark mode, mobile adaptation for the most part, theme colour changes, and the liquid glass effects marked done. The server section has Nest.js, MySQL with TypeORM and Redis, and RBAC permission control, all marked done.

So the honest summary is: the server side is complete enough to be a real backend with a real permission model, the component set covers the common admin widgets, and the rest of the Vuetify catalogue is still to be built.

The RBAC entry is the one that matters most for an admin template, because a panel without an access control model is a prototype rather than a starting point. With role based permission control implemented, the project has the shape of a real application.

The one piece of honesty in the README that deserves to be called out is a note near the top about the liquid glass card mode. Because the liquid glass card mode was updated and set as the default, a performance warning dialog was added to switch back to the normal mode, and most devices run below 20 frames, sometimes lower. The fix is to switch the mode in the settings panel, and the README points at the implementation, a directive at src/directives/liquidGlass.ts, and says you can modify it yourself.

That is a real caveat for anyone evaluating the template on a low powered device, and it is the kind of thing that would otherwise show up as an unexplained performance problem. The default is the experimental effect, not the conservative one, which is an unusual choice.

The 3D section and the graphics stack

The screenshot gallery in the README shows a Tesla page, a smart house page, an edit layer page and a Babylon.js page, and the topics list includes babylonjs, pixijs and threejs. It is worth giving this its own section because it is the least expected part of the project and it explains a good deal of the dependency list.

The three rendering stacks are present side by side, which suggests the project is a demonstration of several WebGL approaches rather than a single one. Babylon.js at 6.33.0 comes with the havok physics plugin and the loaders package, so it can import glTF assets and simulate rigid bodies. Three.js at 0.149.0 is the other full engine. Pixi.js at 7.3.2 is a 2D renderer, and the extra packages, filter-displacement for a displacement filter effect, graphics-extras and the ui package, extend it beyond plain sprite work. ogl is a much smaller WebGL library, and stats-js provides the frame rate overlay that pairs with the liquid glass performance discussion.

The Vue 3 ecosystem is fully wired in around these. @vitejs/plugin-vue-jsx is in the dev dependencies, so JSX components are supported alongside templates, and @vueuse/core at 14.1.0 is the composable utility collection.

The practical consequence is a bundle size question. An admin panel that a user sees for ten minutes a day does not need a 3D engine, but a template that ships three of them has a build output and a download weight that reflect the 3D section rather than the admin use case. The Vite configuration and the code splitting in the build script are where you would look to see how much of that reaches a given route, and the README does not document it.

Where vue-material-admin fits, and where it stops

The alternatives are a component library with a demo page, a full admin framework, and a from-scratch build, and the differences are mostly about what is already wired up.

Against a component library, the difference is that there is a server. Most component libraries give you a table, a form and a menu, and you build the CRUD, the authentication, the routing and the API layer yourself. Here there is a Nest.js backend with MySQL, TypeORM and Redis behind it, plus RBAC, and a role based permission model is a substantial piece of work that most teams would otherwise rebuild.

Against a full admin framework, the difference is ownership. A framework owns its own routing, its own menu conventions and its own data fetching layer, and you work inside its rules. This is a template: the structure is a starting point that you are expected to reshape, and the README frames it as a starting template for a production project.

The limits are clear and mostly in the documentation. The README is written in Chinese, with no English version offered, and the interface itself is Chinese as well. That is not a small obstacle for an international team, and it is a bigger obstacle for anyone who cannot read it, because the configuration steps, the mock API setup and the settings panel behaviour are all documented only there.

The stage is the other limit. The project says itself that it is at the learning and demonstration stage, so the feature set is what you see in the TODO list rather than a mature set, the mock API is the default development path, and the liquid glass default costs frames on modest hardware. And with the newest tagged release from May 2024 while the package.json reads 2.4.1, the release history does not line up neatly with the current source, which is worth checking before you pin a version.

What you do get is a complete, working full stack admin template with a Material Design look, a real permission model and a demonstration of modern WebGL work in the same repository, all under an MIT licence with no vendor lock in the framework layer.

Editorial conclusion

vue-material-admin suits a developer who wants an admin panel with a Material Design look, a working Nest.js backend and role based access control, rather than a set of static mock pages, since the server side is real and the RBAC piece is on the completed list. It is the wrong tool if you cannot read Chinese, because the README and the in-app documentation are Chinese only, and it is the wrong tool if you need a production system today, because the project describes itself as being at the learning, feature showcase and test stage. Before adopting it, switch the card mode away from the liquid glass default in the settings panel if you care about frame rate, and read the Serve branch instructions to run the Nest.js side alongside the frontend.

Frequently asked questions

Official sources

1. armomu/vue-material-admin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases