Shadcn Dashboard ships a mock worker and calls the result production-ready

The manifest is marked private, so the install flow only works from a clone

The package manifest names the project shadcn-dashboard-free, gives it version 1.0.0, and sets private to true. That field blocks publishing, so no one can install this template by package name, and the documented install step only makes sense against a checkout:

npm install

The rest of the quick start is the standard Vite loop, starting the dev server, building, and previewing the production output, with the dev server on port 5173. Prerequisites are given as Node.js 18, 20, or 22 and npm, which is a wider range than the container pins. The build script is worth noting because it is not just a bundler call: it runs the TypeScript compiler first and only then invokes the build, so a type error stops the build rather than shipping.

The lint script is stricter still, passing an unused-disable-directive report and a maximum of zero warnings, so anything the linter considers a warning fails the run. The repository also carries the older .eslintrc.cjs configuration file name rather than a flat config file, alongside a prettier configuration and an editor directory.

The data layer is a mock worker and a random generator

This is the single most important thing to know before shipping anything built on the template. The dependency list includes a mock service worker and a random data generator, and the source tree carries an api directory described as an API service layer and handlers. There is no server, no database client and no authentication backend anywhere in the manifest.

That combination is a deliberate choice for a template: it means the dashboard renders populated charts, tables and profile views the moment you start it, with no infrastructure to stand up, and the numbers differ on every reload because they are generated rather than fetched. The same list also carries a data table library, a charting library, a rich text editor for the blog app, a command palette package, an OTP input, a day picker, a carousel, a drawer library, toast notifications and a resizable panel set, which is what makes the template feel finished rather than scaffolded.

What none of that is, is a working application. The authentication pages, including login, register, forgot password, one-time-password verification, reset password and two-factor verification, are layouts. They will validate and navigate, and they will not authenticate anyone until you write the server side yourself.

Two animation packages are installed side by side

The runtime dependency list holds two animation packages rather than one. One is the older framer-motion name at a 12.38 floor and the other is the current motion package at a 12.42 floor, both on the same major version. That pairing is worth resolving before you build on it, because two packages of the same animation runtime on one version line means two copies of the library in the bundle, and a component animated by one will not share context or state with a component animated by the other.

The primitive layer is similarly doubled. The README says the template is built with shadcn/ui and with Base UI, and the manifest carries the Base UI React package alongside a set of headless component packages that shadcn components are normally assembled from. React 19 is pinned on both the client and DOM packages, and routing is handled by a single version 7 router entry.

Two smaller choices round out the list. There is a syntax highlighter and an icon set component, and one build-time transform, the SVG to React component plugin, is the only dependency in the whole list pinned to an exact version with no range operator while everything else uses a floor.

The build-time SVG transform sits in the runtime dependency list

Among roughly forty ranged runtime dependencies, exactly one is pinned to an exact version, and it is a Rollup plugin that converts SVG files into React components at build time. It sits in the dependencies array rather than in devDependencies, so every deployment, including production installs, carries a build-time transform that never runs at runtime.

That is the kind of packaging habit that is invisible until someone audits the manifest, and it is not the only loose end in the file. The name of the package carries the word free, the version sits at 1.0.0, and private is set, so there is no registry artefact at all and the version number describes nothing that can be installed by name.

The development dependencies, which are cut off in the repository listing, do at least keep type packages separate: definitions for the random generator, lodash, node and react are all declared there. That is the arrangement the dependency array does not follow.

Two deployment targets, and the container one ends at nginx

The repository carries configuration for two hosts. There is a Netlify configuration file at the top level, and there is a three-stage container definition that ends by copying the built output into an nginx image:

FROM nginx:alpine AS runner

COPY --from=builder /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

The earlier stages install dependencies with a clean install from the lock file in a Node 22 slim image, then build in a second image of the same name and copy the node modules forward. The runner copies a custom nginx configuration into the default site file, which means routing behaviour lives in that file rather than in the application. Since this is a single-page application with a client-side router, whether deep links resolve depends entirely on whether that configuration includes a fallback to the entry document, and the contents of the file are not shown.

Note also that the container runs on Node 22 while the documented prerequisites permit 18 and 20, so a working local version is not evidence that the image is what you tested.

The folder tree stops at context and the pitch is written three times

The structure section of the README publishes part of the tree. It shows a public directory for static assets, and a src directory containing the root component, the entry point, an api directory for the service layer and handlers, an assets directory for local SVGs and images, a components directory, and a context directory. The listing ends there, so the parts of the source tree a user actually navigates, including the pages, the apps and the theme context, are not in the published map even though the feature list names all of them.

The product description is repeated three times in different registers. An opening paragraph describes a modern responsive admin dashboard template with a dashboard, three apps, authentication pages, form layouts, data tables, a profile page and a component library. An Overview section later restates almost the same sentence with the same list. The closing block states it once more, adding that it is free and open source and designed to help developers ship admin panels faster. Each version adds a phrase and none adds a fact.

There is also a sibling project for the Next.js version, hosted as a separate repository, and a hosted demo of the React version.

The README's proof points belong to a different company

The section headed as backing states that the project is backed by WrapPixel, and then supplies three numbers that have nothing to do with this repository. It claims over fifteen years of experience building production-grade templates, products used by more than six hundred thousand developers and agencies, and a consistent rating of four point nine out of five. Every one of those figures describes the sponsor's commercial catalogue, not this template, and none can be checked from the code.

The phrasing gives the game away in one place, where fifteen years is written as a floor and a plus sign at the same time, which is a copywriting habit rather than a measurement. It is worth separating this from the licensing section, which is more concrete and also worth reading carefully. The code is MIT, and the section states that the free items may be used for personal as well as commercial purposes, with one condition attached: attribution, by copying a link and pasting it into the footer of your application.

Those are two different asks. MIT already permits commercial use and already requires the copyright notice to travel with copies. A footer link is a branding request on top of the licence terms, not a restriction the licence imposes, and a reader who treats the footer requirement as a licensing condition is overreading it.

Editorial conclusion

Use it as a component and layout starting point, which is what it is good at, and expect to replace its entire data layer before it serves real users. Read the dependency list before you start: a mock service worker, a random data generator and a hand-written api directory are the whole backend, and the template is marked private so the install flow only applies to a clone. Two decisions deserve a second look, since two animation packages and two primitive libraries are installed at once and the build-time SVG transform sits in runtime dependencies. If you deploy the container, check the nginx configuration for a single-page fallback before you rely on client-side routing, and if you publish the result, follow the license rather than the branding ask in the README, which asks for a footer link on top of terms that already permit commercial use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. shadcndashboard/shadcndashboard on GitHub