CoolAdmin, a Bootstrap 5 dashboard template that ships its own build output

A template where the build output is the product

CoolAdmin is a free, MIT-licensed Bootstrap 5 dashboard template with 35 static pages, four dashboard layouts, and vanilla JavaScript. Built HTML, CSS, and runtime libraries ship in the repository, and end users need no Node toolchain. Contributors can edit shared Pug templates and SCSS sources.

That last sentence pair is the whole design, and it is worth unpacking because it explains most of what a reader would otherwise find odd about the repository.

The top level of the repository contains the 35 HTML pages, index.html, index2.html, index3.html, index4.html, calendar.html, chart.html, form.html, table.html, invoice.html, login.html and the rest, plus css/, js/, vendor/, fonts/, images/ and media/ directories. The source lives in src/, with src/pug/ holding the templates and src/scss/ holding the styles. Both are committed.

The reason is a distribution decision. A template that requires npm install and a build step before it can be opened is a template for developers, not for the person who wants an admin panel this afternoon. Shipping the compiled output means the download is a set of files you open, and the Node toolchain is only needed if you want to change the source.

The cost is that the repository has two representations of the same thing, and keeping them in step is a discipline problem. The README handles it explicitly: edit sources, then commit their regenerated outputs together. The root *.html files, css/theme.css and css/app.css are described as generated deliverables.

There is also a published site, cooladmin.colorlib.com, a live demo at preview.colorlib.com, a ZIP download, and the author is Colorlib.

Running it, and what the contributor workflow looks like

For a user, the quick start is three commands and no build:

git clone https://github.com/puikinsh/CoolAdmin.git
cd CoolAdmin
python3 -m http.server 8000

Then you open http://localhost:8000/index.html. The README explains why a local server rather than opening the file directly: a local HTTP server avoids the browser restrictions associated with the file:// protocol, which is the same reason you cannot just double-click an HTML file that loads other files.

For a contributor, the requirements are Node 22.12 or newer and npm, and the lockfile is installed without changing dependency resolution:

npm ci
npm run dev                 # Pug + Sass watchers and Vite at localhost:3000
npm run build               # FullCalendar vendor assets, Pug HTML, Sass CSS
npm run build:vendor        # Calendar scripts/styles/license only
npm run build:pug           # Root HTML only
npm run build:sass          # Theme and app CSS only
npm test                    # Node regression tests
npm run check               # Full build plus tests

The three separate build targets are what a template project needs, because changing one layout and rebuilding all 35 pages is slow, and the granular targets let you build only what you touched.

The dev script is the interesting one, because it runs three watchers at once. The package.json shows it as concurrently with the --kill-others flag and named pug, sass and vite streams, so the three processes are labelled in the terminal output and killing one stops the others. The README adds the detail that if one development process exits, concurrently stops its siblings, which is the behaviour you want rather than a leftover Vite server holding a port.

There is also an explicit warning that Vite is a development server and vite build is not the production pipeline. The production build is the Pug and Sass compilation plus the vendor build, and the output is the committed files. A contributor who reaches for vite build would be producing something the project does not ship.

The test tooling is minimal and honest about it. The test script is node --test, the runner built into Node, and the README says there is no coverage threshold and no configured linter or formatter. The check script is a full build plus the tests.

What is in the template, and the boundaries it declares

The four dashboard layouts cover operations with index.html, sales with index2.html, marketing with index3.html, and projects with index4.html. The application pages are calendar, Leaflet maps, inbox, drag and drop kanban, sortable, filterable and paginated tables, invoices, profiles, pricing and notifications. The component examples are forms, charts, buttons, cards, modals, tabs, alerts, progress bars, switches, typography and icons, and there are auth and error pages as frontend examples.

The shared interactions are where a template earns its place. There is a Ctrl+K and Cmd+K command palette with substring search, toast notifications, six persistent accent colour presets, mobile navigation, and dashboard loading skeletons. The command palette is backed by a COMMANDS array maintained separately from the sidebar navigation, and the README says to add palette entries to that array in js/main-vanilla.js, while the sidebar comes from src/pug/partials/_nav-data.pug. Two sources of truth for navigation, kept apart on purpose, because a palette entry is a command and a nav entry is a page.

The integration boundaries section is the part to read before you commit to this template, because the README is unusually direct about the gaps. Sample forms and auth pages need a backend for real persistence, authentication, payments or email. Six accent presets ship, and the app overlay does not provide a complete dark theme, with the legacy Bootstrap dark tokens covering only part of the styles. Inter loads from rsms.me, and the map page also uses Leaflet's CDN assets and external map tiles.

That last point has a practical consequence that is easy to miss. The template is not fully self-contained at runtime even though the libraries are vendored, because the font comes from a font service and the map from a tile server. A deployment behind a firewall or in an air-gapped environment will show a fallback font and an empty map, and a strict Content Security Policy will need those origins allowed.

The v3.5.0 release, and what the numbers actually measure

The v3.5.0 release notes are the most informative part of the README, because they show what the maintainers think is worth doing to a template and they are careful about the claims.

Two changes dominate. The first is the removal of the 208,479-byte Chart.js script request from 23 pages that had no chart canvases, so Chart.js now loads only on index.html, index2.html, index3.html, card.html and chart.html. A template is often copied into an application, and a script that every page pulls is a cost every copy inherits.

The second is the FullCalendar rebuild. FullCalendar 7.1.2 was rebuilt from its locked npm distribution with Terser, and the two scripts total 340,963 bytes raw and 95,797 bytes gzip, compared with 803,469 and 164,748 bytes previously. The README then adds the caveat that matters: these figures exclude calendar CSS and do not measure page-load time or Core Web Vitals. It is stating the size of what it shipped and explicitly refusing to claim a performance win it did not measure.

The rest of the release is maintenance that anyone maintaining a template will recognise. Directory watching was fixed for Chokidar 5, debounced saves, serialized Pug builds, and unchanged output timestamps were preserved. Detached chart instances during repeated dashboard refreshes were fixed, which is the classic symptom of a chart library that is initialised again on every refresh, and font-display: swap was added to the Poppins declarations. Six Node regression tests were added along with CI on Node 22 and 24, including committed asset consistency checks.

The validation section describes what npm run check covers: local HTML and CSS asset references, conditional chart loading, calendar distribution and version, Pug build timestamps and errors, watcher add, change and unlink recovery, and repeated dashboard refresh chart cleanup. And for v3.5.0, all 35 pages were checked in Chromium at 1440 px and 390 px with no console errors or failed requests, across the calendar Month, Week, Day and List views, chart rendering, repeated refreshes and palette keyboard control.

The dependency table, and the rules for changing it

The dependency table is a snapshot with a date on it, and the README is explicit that the versions are stable npm releases verified on October 13, 2026.

Bootstrap 5.3.8 is vendored CSS and bundled JS. Chart.js 4.5.1 is a vendored UMD bundle used on the five chart pages. FullCalendar 7.1.2 is the calendar only, taken from npm as source and minified into vendor output. Font Awesome Free 7.3.1 is vendored CSS and WOFF2 fonts, and Hamburgers 1.2.1 is vendored CSS for the mobile menu.

Then the tooling, which is a different category. Leaflet 1.9.4 is map-only CDN imports with integrity hashes, which is the opposite of the vendoring approach used for the other libraries and is a consequence of the map tiles being external anyway. Chokidar 5.0.0 watches Pug sources, concurrently 10.0.6 orchestrates the development processes, Pug 3.0.4 compiles templates, Sass 1.105.1 compiles styles, Vite 8.3.4 is the development server, and Terser 5.51.2 minifies the calendar scripts.

The upgrade procedure for the awkward dependency is spelled out, because a vendored library cannot simply be bumped. When upgrading FullCalendar you must rebuild its vendor files, update the versioned paths in src/pug/pages/calendar.pug and in the documentation, and remove the superseded vendor directory. And you must preserve license notices. The README adds that other vendored libraries are checked separately from npm outdated, which is a hint that the vendored set is versioned deliberately rather than tracked in package.json alone.

The repository structure is a Pug and SCSS project with the usual partials arrangement, and the README gives three rules that would otherwise be discovered the hard way. The _nav-data.pug file drives the sidebar and mobile navigation. The SCSS import order must be preserved, because the cascade depends on it. And the app overlay styles use the body.app selector and the --m-* design tokens, so a customisation that ignores the token names will not compose with the rest of the theme.

Editorial conclusion

CoolAdmin suits someone who wants a complete admin interface to start from today, because the pages ship as static files with the libraries vendored, so there is no toolchain to install and no build to run. It is the wrong choice for a team that expects a component library with a build pipeline, because the build output is committed alongside the sources and a contributor has to regenerate and commit both, and it is the wrong choice if you need a working dark theme or a real backend, since the README is explicit that the app overlay does not provide a complete dark theme and that the sample forms and auth pages need a backend for persistence, authentication, payments or email. Before adapting it, read the integration boundaries section, and check whether your deployment can serve the external Inter font and Leaflet CDN assets, because those are fetched at runtime.

Frequently asked questions

Official sources

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