AdminKit is a Bootstrap 5 admin template you compile with Webpack yourself

What you get in the free version: 15 pages, one plugin, one colour scheme

The scope is stated plainly in the project's own comparison table. The free repository carries 15 demo pages, 1 plugin and 1 colour scheme. Everything else in that table, including 45+ demo pages, 10+ plugins, 3 colour schemes, dark mode, compact sidebar, calendar, advanced forms, drag and drop, toast notifications and WYSIWYG editors, sits in the separate AdminKit PRO product sold on the vendor's site.

That split matters for how you evaluate the repository. This is not a component library you import and compose, and it is not a theme with a settings file. It is a starting codebase. The npm package is published as `@adminkit/core` at version 3.5.0, and its `files` array contains only `dist`, so consuming it through npm gives you compiled CSS and JavaScript, not the Sass sources or the page markup.

The claimed browser surface is also explicit. The README states the themes work in Chrome, Firefox, Safari, Opera and Edge, and the `browserslist` field narrows that into a concrete policy: Edge last version, and the last two versions of Firefox, Chrome, Safari and iOS Safari, with `not Explorer <= 11` as a hard exclusion.

No jQuery, but also no framework, so the JS is yours to own

AdminKit makes a point of running without jQuery, and the README extends that claim to the third-party libraries it bundles. Look at the runtime dependency list and the claim holds up: `@popperjs/core` 2.11.8, `chart.js` 2.9.4, `feather-icons` 4.29.2, `flatpickr` 4.6.13, `jsvectormap` 1.7.0, `simplebar` 5.3.9 and `bootstrap` 5.3.8. None of them pulls in a jQuery dependency.

The absence of jQuery is a design decision, not just a dependency deletion. It means every interactive behaviour in the template, dropdowns, sidebar toggles, modals, table interactions, is implemented in vanilla JavaScript in `src/js/`, split into a `modules/` directory alongside an `app.js` entry point. For a team that wants to bind its own view logic, that is a feature: nothing is hiding behind a global `$`.

The other side is that there is no component API to extend. If your application is a React or Vue codebase, AdminKit gives you markup, compiled CSS and some standalone scripts, and the integration work lands on you. The README's claim that the code follows Bootstrap's guidelines helps, but it does not turn an HTML template into a component you can mount.

The build chain: four npm scripts, one Webpack config, dist is the published artifact

Everything in the repository is designed around a Webpack config at the root. The `package.json` scripts are short and specific:

"build": "cross-env NODE_ENV=production webpack --config webpack.config.js --progress",
"watch": "webpack --config webpack.config.js --watch --progress",
"start": "webpack serve --config webpack.config.js --progress",
"prepublishOnly": "cross-env NODE_ENV=production webpack --progress --config webpack.config.js"

`npm start` runs `webpack serve`, which starts webpack-dev-server on http://localhost:8080 and rebuilds on change. `npm run build` compiles, optimizes and minifies into `dist/`. The same production command runs automatically through `prepublishOnly` before the package is published, which is why the npm tarball contains `dist` and nothing else.

A first run is two commands after cloning:

git clone https://github.com/adminkit/adminkit.git
npm install
npm start

Node.js is a prerequisite the README calls out explicitly, and the presence of `.nvmrc` at the repository root suggests a pinned version is intended, although the README does not state which one. The build also runs Babel (`@babel/preset-env`, `babel-loader`) and PostCSS with autoprefixer, so the toolchain is a normal 2020s asset pipeline rather than a minimal script runner.

The Sass layer is numbered for load order, which is the template's real contract

The `src/scss/` directory is organised into numbered folders: `1-variables/`, `2-mixins/`, `3-components/`, `4-utilities/`, `5-vendor/`, with `app.scss` at the top as the entry point. Those numbers are a load order convention, which means your custom theme overrides belong in `1-variables/` rather than in a new stylesheet loaded after everything else.

This is the mechanism that makes the template customisable without being an expert in it. Change the Sass variables and the components recompile against them; the numbered structure stops the cascade from depending on where you happened to insert your file.

The compiled output is just two files, `dist/css/app.css` and `dist/js/app.js`. Both are also served over a CDN from unpkg, and the README links them with an explicit `latest` tag:

<link rel="stylesheet" href="https://unpkg.com/@adminkit/core@latest/dist/css/app.css">
<script src="https://unpkg.com/@adminkit/core@latest/dist/js/app.js"></script>

Pinning `@latest` in a CDN link means your production page can change underneath you without a commit. That is a small but real difference from the versioned install script approach, and worth remembering if you copy these lines into a product.

Pinned versions that date the stack, and where the template stops

The dependency list is worth reading closely, because exact pins in a template age visibly. `chart.js` is pinned at 2.9.4 on the 2.x line, and `flatpickr` is pinned at 4.6.13. Both are stable choices for a dashboard demo, but a team that needs current chart features or the newer date picker API will have to upgrade and re-verify the page templates rather than bump a caret range.

Bootstrap is pinned at 5.3.8, and `@babel/polyfill` is listed as a runtime dependency at 7.12.1. Small inconsistencies like that are normal in a template and are exactly what you find out when you read the lockfile rather than the feature list.

Release cadence tells its own story. v3.5.0 shipped on 2026-08-01, the previous tags are v3.4.0 from 2023-06-08 and v3.3.0 from 2022-08-10, and the last push was on 2026-09-13. The repository is not archived, but the gap between v3.3.0 and v3.4.0 was one year, so a version number in this project is not a reliable signal of how often you will receive fixes.

Where AdminKit is the wrong choice

The clearest wrong-tool case is a team with an existing component architecture. AdminKit ships static HTML, Sass and standalone JavaScript, and its own page set is 15 demos. Wiring it into an application that already owns routing, state and rendering is integration work that the README does not help with, because there is no documented API surface, only files.

The second case is a hard offline or air-gapped deployment that cannot use unpkg and does not want a Node toolchain. The CDN links are offered as the easy path, and the alternative is checking the source into your own repository and owning the build.

The third is licensing expectations around scale. The repository is MIT, which is permissive, but the README is explicit that the free version stops at 15 demo pages, one plugin and one colour scheme. If your evaluation is based on the demo site, check which of those pages fall outside the free set before you plan around them.

Editorial conclusion

Use AdminKit when your team wants a plain HTML and Sass admin shell it can fork and restyle, and the Node build chain is acceptable, then verify two things before committing: run `npm install` and `npm run build` on your own Node version to confirm the Webpack toolchain still resolves, and check whether the pinned `chart.js` 2.9.4 and `flatpickr` 4.6.13 meet your chart and date-picker needs,. If you need a component library that plugs into an existing React application, or you want the extra pages and plugins listed for the paid PRO variant, this repository is the wrong starting point.

Frequently asked questions

Official sources

1. adminkit/adminkit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases