The Nuxt UI dashboard template is a starter with a sidebar, a palette and a real dependency set

What you get on the first page

The template is described as a Nuxt dashboard template made with Nuxt UI, and the feature list in the README is specific about what that means.

You get multiple pages, a collapsible sidebar, keyboard shortcuts, light and dark mode, and a command palette, powered by Nuxt UI. There is a live demo at dashboard-template.nuxt.dev, and the documentation is the Nuxt UI getting started page rather than something the template maintains itself, which tells you the template is a thin layer over the component library rather than a fork of it.

That distinction matters more than it sounds. A template that reimplemented the components would drift from the library as it evolves. A template that composes them inherits every fix the library makes, and the only thing to maintain is the composition.

The Vue equivalent exists as a separate repository, nuxt-ui-templates/dashboard-vue, and the README points at it for anyone who needs the Vue version rather than the Nuxt one. That is a small detail, but it tells you the template is one member of a family rather than a one-off.

The primary language is Vue, the licence is MIT, and the default branch is `main`. The last push to the repository was on 2026-10-15 and it is not archived, so the template is still being worked on, though there are no GitHub releases, so the version history is in the commits and in the lock file rather than in tags.

Getting started is one command, and the lock file is pnpm

The quick start is the create-nuxt scaffolding with a template flag.

npm create nuxt@latest -- -t ui/dashboard

So the template is registered in the Nuxt starter catalogue and the `-t ui/dashboard` argument selects it. That means a new user does not clone a repository and fight with a package.json, they answer a couple of questions and get a working project.

If you do have the repository, the setup is pnpm.

pnpm install

And the package manager is pinned in the manifest at `[email protected]`, with a `pnpm-lock.yaml` and a `pnpm-workspace.yaml` at the root. The pinning is a small thing that saves a real annoyance, because an unpinned package manager version is how a lock file stops being honoured.

The rest of the scripts are the standard Nuxt set, with `nuxt build`, `nuxt dev`, `nuxt preview` and `nuxt typecheck`, plus `eslint .` for linting. There is a `postinstall` script that runs `nuxt prepare`, which is the step that generates the type stubs for the auto-imported components, and that is why the postinstall hook exists rather than being an oversight.

The development server runs on `http://localhost:3000`, and `pnpm preview` serves the production build locally, which is the step worth doing before you deploy, because it catches the difference between a dev server and a built application.

There is also a `server/` directory at the root, which is the Nuxt server directory, and an `app/` directory for the application code. The `.env.example` file contains a single variable, `NUXT_PUBLIC_SITE_URL`, described as the public URL used for the OG image when running `nuxt generate`.

The dependency list tells you what an admin surface needs

The dependencies are the most informative part of the manifest, because they show what the template decided a dashboard needs rather than what a landing page needs.

`@nuxt/ui` at 4.11.3 is the component library, and `nuxt` at 4.6.1 with `vue` at 3.5.43 is the framework stack. `tailwindcss` at 4.3.3 is the styling layer, and `eslint-plugin-better-tailwindcss` is in the dev dependencies, which is a plugin that enforces class ordering conventions. That plugin is a small signal about the project's priorities: a template meant to be shared wants its markup to be consistent, because every consumer will read the source.

The data layer is where a dashboard differs from a marketing page. `@tanstack/table-core` at 8.21.3 is the headless table library, which means the template gives you the table's sorting, filtering and pagination model without imposing a table's appearance. `@unovis/ts` and `@unovis/vue` at 1.7.1 are the charting components. `@vueuse/core` and `@vueuse/nuxt` at 14.4.0 are the composable utilities. `@internationalized/date` at 3.12.4 and `date-fns` at 4.4.0 are the date handling, with the internationalized package being the one that handles locales and time zones properly rather than by string format.

Two dependencies are worth a second look. `scule` at 1.3.0 is a string utility library, one of the small helpers that sit alongside the table, chart and date packages.

And `zod` at 4.6.5 is the schema library, which points at the type story. The template has a `server/` directory and the `typecheck` script runs `nuxt typecheck`, with `vue-tsc` in the dev dependencies. A dashboard that displays data from an API needs a runtime validator as well as a compile time type, and zod filling that role in the dependency list is a deliberate choice rather than a leftover.

Keyboard shortcuts and the command palette are the difference from a starter

Most Nuxt starters give you a layout and a page. This one gives you the parts of an admin interface that are tedious to build and that people expect to be there.

The collapsible sidebar is the obvious one, and the interesting part is not that it collapses but that it is a layout decision baked into the template rather than a component you have to wire into every page. The keyboard shortcuts and the command palette are the pair that matter more, because they are what a real admin surface uses to move between views without the mouse, and building one requires global state, a keymap, a search index and a rendering layer for the results.

A command palette in particular is one of those features that looks like a small addition and is a substantial one. It needs a registry of actions, which in a dashboard means every route, every command and every quick action has to be discoverable and typed, and the template has to have made those decisions consistently for you.

Light and dark mode is the third item on the list, and in a Nuxt UI application it is a system level concern rather than a per component one, since the library handles the theme tokens and the template just has to wire the toggle and respect the user's preference.

The combination of these four, sidebar, shortcuts, palette and theme, is what separates a dashboard template from a marketing page template. If your application is an internal tool for operators, that is exactly the surface you need and exactly the surface that is boring to build.

The `app/` directory at the root of the repository is where those pages live, and the `public/` directory holds the static assets, including the light and dark screenshots the README embeds.

Renovate, ESLint and the deployment route

The remaining tooling is worth a look because it decides how the template behaves a year after you adopt it.

There is a `renovate.json` at the root and a Renovate GitHub app installation link, and the README says to install the app on your repository and you are good to go. For a template that is deliberately full of dependencies, a bot that keeps them current is a large part of why the template stays usable, because a dashboard built on an abandoned table library is a rewrite.

The linting stack is ESLint 10 with `@nuxt/eslint` at 1.17.0 and `vue-tsc` at 3.3.13 for the type checking, and TypeScript at 6.0.3. There is an `eslint.config.mjs` at the root, which is the flat config format, and an `.editorconfig` for the non-linted files.

The deployment route is Vercel, with a Deploy with Vercel button in the README that clones the template repository and configures the project for you. There is a `nuxt.config.ts` at the root, which is where you would change the runtime configuration, and the README points at the Nuxt deployment documentation for the details of hosting it elsewhere.

The licence is MIT, with the text in the LICENSE file at the root, which for a template is exactly the right choice, since the entire point is that you fork it and own the result.

The last push was on 2026-10-15, so the template is actively maintained against the current Nuxt and Nuxt UI versions. The versions in the manifest, Nuxt 4.6.1 and Nuxt UI 4.11.3, are recent enough that you are not inheriting a template that lags the ecosystem, and if you do adopt it, the Renovate setup means it will not start lagging.

Editorial conclusion

Adopt the Nuxt UI dashboard template if you are starting a Nuxt application that needs an admin interface and you want the layout, navigation and chart plumbing already working. Do not adopt it if you have an existing design system, because the template brings its own Tailwind theme, its own icon set and its own layout decisions that you would be undoing. Verify first that the Nuxt and Nuxt UI versions in the template match the ones you intend to use, that the command palette and the keyboard shortcuts do not collide with shortcuts your own pages need, and that the table and chart libraries it pulls in are the ones you want to build on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nuxt-ui-templates/dashboard on GitHub
4. Project website
5. README