# quasar-admin: a free Quasar admin template with a business attached

> quasar-admin is a free Quasar and Vue 3 admin template with Material 3 Expressive styling, five colour themes and screens for a dashboard, CRM, mail, auth and pricing. It is MIT licensed and installable with npm install, and its own tooling generates and checks design tokens, subsets icons and validates single file components.

**pratik227/quasar-admin** — Free Quasar Admin Template based on Vue.js and used Quasar Framework. 

- Repository: https://github.com/pratik227/quasar-admin
- Website: https://next-quasar-admin.netlify.app/
- Stars: 864 · Forks: 324
- Language: Vue
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/pratik227-quasar-admin

## A free template that is also a shop window

The README starts with an About us section rather than with the project, and the reason becomes clear two paragraphs later: the repository below is the free template, it ships the same design system as the premium ones, and it doubles as a preview of how the author builds.

So this repository is one half of a commercial operation. The Quasar Admin Templates organisation sells three premium templates, and the free one is the sample. The table in the README lists them with customer counts and prices: Quasar Prime at 81 customers with a launch price of $249 against a struck-through $549, Quasar Admin Premium at 16 customers for $69 one-time, described as also available for TypeScript with the Composition API and script setup, and Quasar Minimalist at 12 customers for $49. The author also offers consulting, and the contact is an email address in the README.

None of that is a problem for an engineer, and it is worth reading in one specific way. The free template is the one that carries the MIT licence, and the README states the licence plainly at the bottom. A template you can take, modify and ship under MIT, with a design system that the paid versions share, is a genuinely useful starting point, and the fact that it is also a demonstration of the author's commercial work is a matter of the author's business rather than a limitation of the code.

The technical facts are these: it is a Vue project using the Quasar framework, the primary language is Vue, the default branch is v1, the site is next-quasar-admin.netlify.app, the last push was on 2026-10-12, and the repository publishes no GitHub releases.

## Screens, Material 3 Expressive and five colour themes

The UI section is a list of screenshots, and the list is the specification of what the template covers.

There is a Dashboard and a CRM Dashboard, a Mail screen built as a list-detail layout, a Login, a Sign Up, an About Us page, two Lock Screen variants and a Pricing page. That is a coherent set of the pages an admin product needs on day one, and the two lock screens and the pricing page are the kind of detail that separates a template from a demo.

The visual system is Material 3 Expressive, with five built-in colour themes, and light and dark that follows the operating system. The five themes are how a product lets a customer pick a brand colour without forking the stylesheet, and the OS-following light and dark mode is a single preference rather than a toggle the app has to persist and reconcile.

The screenshots live in src/assets/ as image files, which is a small but useful detail for anyone extending the template, since it tells you where the design assets are kept and how they are referenced.

Configuration is handled the Quasar way, with the README pointing at the documentation for configuring the quasar.config file, and the repository has quasar.config.js at the top level next to postcss.config.js and index.html.

## A current dependency set, and a small one

The dependency list in package.json is short enough to read in full, which is unusual and welcome in a template.

The framework side is quasar at ^2.33.0 with vue at ^3.5.40, vue-router at ^5.2.0 and pinia at ^4.0.2 for state. The @quasar/extras package at ^2.0.2 carries the icon and font assets, and two Quasar add-ons are included, @quasar/quasar-ui-qcalendar at ^5.3.0 for a calendar and quasar-ui-qhierarchy at ^1.0.19 for a tree view. Data visualisation is echarts at ^6.1.0 with vue-echarts at ^8.0.1 as the wrapper, and vuedraggable at ^4.1.0 for list reordering.

The development dependencies are four: @quasar/app-vite at ^3.9.0, which is the build tool, @material/material-color-utilities at ^0.4.0, autoprefixer at ^10.5.4 and postcss at ^8.5.24.

That last one is the interesting entry. The Material color utilities package is a colour science library, and its presence next to a token generation script tells you the theme system is computed rather than hand-written, which is what makes five built-in colour themes feasible without five sets of hand-tuned values. The dependency is there to do the work of deriving a palette from a seed colour, and the scripts in the next section are the part that uses it.

The Vue Router major version is worth a glance too. Vue Router 5 with Vue 3.5 is the current pairing, and a template that pins current versions is easier to build on than one pinned to an older generation.

## Two different statements about which Node you need

The requirements section of the README says Node.js >= 22.12, with Node 24 and 26 also supported, and says it is required by @quasar/app-vite v3.

The package.json states it more precisely in the engines field:

```json
"engines": {
  "node": ">= 26 || ^24 || ^22.12"
}
```

Those are not the same statement. The README reads as an open-ended lower bound of 22.12, while the engines field is a version range that allows 26, allows 24 within the major, and allows 22.12 and later within the 22 line. The practical effect of the engines field is that a version manager will refuse to install under something like Node 25 or an old Node 20, which is stricter than the README suggests and is the kind of detail that produces a confusing first failure if you only read the prose.

The build tool requirement explains the floor. @quasar/app-vite v3 is what drives both the dev server and the production build, and the Quasar CLI scripts in the manifest are just quasar dev and quasar build, so the toolchain requirement is inherited from that package rather than chosen by the template author.

The rest of the metadata is unremarkable: the package is named Quasar Admin with the version 0.0.1, the type is module, the package is private, and the licence file is LICENSE.md. A template marked private is normal, because a template is not published to a registry, it is copied.

The repository also has an .npmrc, a jsconfig.json rather than a tsconfig.json, which fits a JavaScript project, and a netlify.toml, which is the deployment configuration for the hosted demo site.

## Three commands, and no global install needed

The install instructions are three commands:

```bash
npm install
```

```bash
npm run dev
```

```bash
npm run build
```

The first installs the dependencies, the second starts the development server with hot code reloading and error reporting, and the third builds for production.

The README makes a point that matters more than it sounds: the dev and build npm scripts work without a global install. The scripts call quasar dev and quasar build, and quasar is resolved from the local node_modules because @quasar/app-vite is a local dependency. That is the difference between a template that works immediately after a clone and one that needs a global tool installed first.

If you prefer to drive the CLI yourself, the README says to install the optional global CLI as well:

```bash
npm install -g @quasar/cli
```

and links the Quasar CLI documentation. The word optional matters, because a global CLI and a local one can disagree about which version of the build tool is in use, and the local one is the one the project pins.

There is also a postinstall hook in the manifest, quasar prepare --silent, which is Quasar's own step for generating the type and asset files the project needs, and the --silent flag keeps it from printing during npm install.

## The tooling is the most interesting part of the repository

The scripts beyond dev and build are what separate this template from a skin, and they are all in package.json.

There is tokens:generate, which runs node tools/generate_m3_tokens.mjs, and tokens:check, which runs the same script with the --check flag. The first writes the design token files, and the second verifies that the committed tokens match what the generator produces, which is a way of keeping a generated file honest in version control. The tools/ directory also holds generate_m3_tokens.mjs, check_tokens.mjs and check_sfc.mjs, and the tool that checks single file components is a separate script from the one that checks tokens.

Then there is fonts:subset and fonts:check, both of which run python3 tools/subset_fontawesome.py, the second with --check. That script subsets the FontAwesome icon font, which keeps only the icons the project actually uses instead of shipping a whole icon set, and running it with --check turns it into a verification step. It is also the only place in the project where Python appears, in a JavaScript codebase, and the choice of a plain script over a JavaScript implementation suggests it is a self-contained utility.

The check script ties the three together: npm run check runs check:sfc, then tokens:check, then fonts:check. So a single command validates the single file components, the design tokens and the icon subset.

And then there is the test script, which is echo "No test specified" && exit 0. It is the default text npm puts in a new package.json, left in place, and it exits successfully. That is the honest state of the project: there is a tests/ directory in the repository listing, but the npm test script does not run it, so the check script above is the entire automated verification available to a user of this template.

## Where the free template stops

It is worth being clear about what the README covers and what it does not.

There is no description of a data layer, no API client, no authentication implementation and no routing map, only the screens and the styling. The Login and Sign Up pages are screens, and the README does not describe what happens when you submit them. The pinia and vue-router dependencies are there, so the structure for state and routing is in the code, but the wiring for a particular product is what you would write.

The deployment story is one file. netlify.toml is the Netlify configuration for the demo site, and hosting the app somewhere else is a configuration exercise that the README leaves to you.

Then there are the small things that signal the project's shape. The default branch is v1 rather than main, which suggests the branches correspond to template versions. There are no GitHub releases, so there is no changelog to read for a version upgrade, although the repository does have a docs/ directory. The .mcp.json file at the top level is a configuration for AI assistants, which tells you the author expects people to work on this template with an assistant and has prepared the repository for it.

Taken as a whole, this is a well-kept design system with a worked example, released under a permissive licence, with the checks that a design system needs and the tests that a product would need. For an engineer starting an admin interface, that is the right balance, provided you know that the product parts are yours to write.

## Conclusion

Adopt quasar-admin if you want a Quasar and Vue 3 admin interface to start from, because the design work is done, the dependency set is small and current, and the MIT licence lets you build a product on it without buying anything. Do not adopt it expecting a finished application, because there is no test suite, the test script in package.json prints that no test is specified and exits successfully, and the README does not describe a data layer, an authentication flow or a deployment story beyond a Netlify configuration. Before you build on it, read the engines field rather than the README's requirement line, because the two are not the same, and run the check script after every change, since the token, single file component and icon subset checks are the guardrails this project actually has.

## FAQ

### What is quasar-admin and what licence is it under?

It is a free Quasar admin template based on Vue.js and the Quasar framework, and it is MIT licensed, with the licence file in the repository root. The README states that it ships the same design system as the author's paid templates and doubles as a preview of how they build.

### What do I need to run quasar-admin locally?

Node.js, then npm install, npm run dev for the development server and npm run build for a production build. The README states Node.js >= 22.12 with Node 24 and 26 also supported, while the engines field in package.json spells out the range as >= 26 || ^24 || ^22.12.

### Does quasar-admin have tests?

The test script in package.json is echo "No test specified" followed by exit 0, the default placeholder. What the project does provide is npm run check, which runs the single file component check, the design token check and the FontAwesome subset check in turn.

### Which Quasar and Vue versions does quasar-admin use?

quasar at ^2.33.0 with vue at ^3.5.40, vue-router at ^5.2.0 and pinia at ^4.0.2, plus echarts with vue-echarts for charts, the Quasar calendar and hierarchy add-ons, and @quasar/app-vite ^3.9.0 as the build tool.

## Sources

- [Issues](https://github.com/pratik227/quasar-admin/issues)
- [License: MIT](https://github.com/pratik227/quasar-admin/blob/v1/LICENSE)
- [pratik227/quasar-admin on GitHub](https://github.com/pratik227/quasar-admin)
- [Project website](https://next-quasar-admin.netlify.app/)
- [README](https://github.com/pratik227/quasar-admin/blob/v1/README.md)

---

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