tanstack-start-dashboard: an admin dashboard starter on TanStack Start

What a starter kit is really buying you

tanstack-start-dashboard is an open source admin dashboard starter built with TanStack Start, shadcn/ui, TypeScript and Tailwind CSS, and the README describes the result as a production-ready dashboard UI with charts, tables, forms and a feature-based folder structure, aimed at SaaS apps, internal tools and admin panels.

That framing is worth taking apart, because the value of a starter is not the demo screens. It is the decisions that have already been made. In this repository, those decisions are visible in the stack table: React Query for data fetching with route loaders, TanStack Table for tabular data, TanStack Form with Zod for forms, file-based type-safe routing with an auto-generated route tree, and Zustand for client state.

Those are not arbitrary choices. TanStack Query, Table, Form and Router are four separate libraries from one author, and the starter shows them working together rather than in isolation. A table that fetches through a route loader and paginates through URL search parameters is a pattern that is easy to describe and easy to get subtly wrong, and seeing it done once is worth more than the components themselves.

The project is MIT licensed, written in TypeScript, and the repository is not archived. There is a live demo linked from the README through a short URL, and the cover image in the README is a screenshot of the dashboard itself.

TanStack Start 1.x on Vite 7, deployed through Nitro

The stack table is the shortest way to understand the project, because each entry is a decision with consequences.

TanStack Start 1.x is the framework, and the badge in the README pins it at the 1.x line. The language is TypeScript and the build tool is Vite 7. Deployment goes through Nitro, which the README lists as covering Vercel, Cloudflare and Node.js, and the features list makes the same point as deploy anywhere with Vercel, Cloudflare and Node.js via Nitro presets.

That last row is the one that changes how you host the thing. A Nitro preset means the build output is a server bundle that runs on more than one runtime, so the same application can go to an edge platform or to a plain Node process without a rewrite. The package scripts show the Node side of it, with start pointing at node .output/server/index.mjs.

Styling is Tailwind CSS v4 and components are shadcn-ui, with the components.json file in the repository root being the shadcn configuration. The dependency list shows the modern shadcn package, @shadcn/react, alongside @base-ui/react, and a long list of @fontsource variable font packages covering everything from Inter and DM Sans to JetBrains Mono and Playfair Display, which is the kind of detail that shows the author cared about the typography as much as the layout.

For linting and formatting the project uses OxLint and Oxfmt rather than the ESLint and Prettier defaults, and there are separate scripts for lint, lint:fix, format and format:check. Using the Oxc tools is a small decision with a real effect on a large project, because the lint and format steps are the ones that run on every save.

Tables: route loaders, client cache and URL state

The data pages are the part of the starter that a backend engineer will use most, and the README describes their architecture in unusual detail for a template.

The product list page is described as TanStack Table plus React Query, with a route loader prefetch and a client cache, and URL search params for search, filter and pagination. The users page is described as the same architecture. The point of putting search, filter and pagination in the URL is that the state becomes shareable and survives a refresh, which is the behaviour users expect from a table and which most hand-rolled implementations get wrong.

The second half of the pattern is the client cache. The route loader prefetches on the server, the client cache serves the data on navigation, and the two are reconciled by React Query, so navigating back to a page you visited a moment ago does not refetch.

The React Query demo page exists to show the pattern in isolation. It is a Pokemon API demo demonstrating the route loader together with useSuspenseQuery and the client-side cache, and it is the page to read if you want to understand the mechanism before adapting it to your own data.

For writes, the create product form uses TanStack Form with Zod and useMutation, with cache invalidation on success, so that the list behind the form updates when the mutation lands rather than needing a manual refresh.

Forms as a set of patterns rather than one example

Most starters ship a single form and call it a form system. This one ships a forms page with four distinct patterns, which is a better template for the kind of screen an admin panel accumulates.

The README lists basic, multi-step, sheet and dialog, and advanced form patterns, all built with TanStack Form and Zod. TanStack Form is a headless form library, so the visual layer comes from shadcn components, and Zod provides the schema that drives both validation and the generated types.

The multi-step case is the one worth understanding. A wizard needs the same field state spread across several screens, validation per step rather than at the end, and the ability to go back without losing what has been entered. A headless form library with a schema is a reasonable way to build that, because the step boundaries become a rendering decision rather than a data model decision.

The sheet and dialog pattern is the second one, and it is the pattern most admin products get wrong. A form in a side sheet is not a form in a page, because the page behind it stays live, the focus trap changes, and the user can lose state by closing it. Having a working version of that in a starter saves a day of fiddling.

The parts that go beyond a CRUD template

Several features of the starter exist to show how a specific interaction is done well, and those are the parts most likely to survive into your product.

The Kanban board uses drag and drop with dnd-kit and Zustand, with column sorting and task cards carrying priority badges. The README also lists @dnd-kit/sortable, @dnd-kit/modifiers and @dnd-kit/utilities in the dependency list, so the starter uses the sortable machinery rather than a bare drag handle, which is what makes reordering within a column work.

The chat interface is a messaging UI with a conversation list, message bubbles, quick replies and file attachments. The pages table describes it as having an auto-reply demo, which is a clear signal that the message transport is stubbed and needs replacing.

The notification centre is a bell icon with a badge, a popover preview and a dedicated full page with tabs, which is the standard three-surface pattern for notifications and is rarely built consistently from scratch. The command palette uses kbar for quick navigation with the Cmd+K shortcut. The infobar component is smaller but shows a habit worth copying: a single component for tips, status messages and contextual information that can appear on any page.

Theming is a first-class feature rather than an afterthought, with multi-theme support, more than ten themes and easy switching, and the stack table names tweakcn as the tool.

Running it locally and the shape of the repository

The project uses bun, and the lock file in the repository is bun.lock, so that is the package manager to expect. The scripts in the package manifest are short:

  "scripts": {
    "dev": "vite dev",
    "build": "vite build",
    "start": "node .output/server/index.mjs",
    "lint": "oxlint",
    "lint:fix": "oxlint --fix",
    "format": "oxfmt --write .",
    "format:check": "oxfmt --check ."
  },

The build produces the Nitro output, and the start script runs the server bundle from .output, which is the same artefact that gets deployed.

The repository root is deliberately small: a .gitignore, the oxlint and oxfmt configuration files, the LICENSE, the README, bun.lock, components.json for shadcn, env.example.txt, package.json, the public directory, src, tsconfig.json and vite.config.ts. There is no separate config folder, no monorepo and no server directory, which tells you the starter is a single application rather than a workspace.

The package itself is marked private with version 1.0.0, and the repository publishes no GitHub releases, so forking it is the intended path rather than installing a version. The last push was on 2026-08-07.

Editorial conclusion

Use this starter if you are building a SaaS admin panel or an internal tool and want the layout, table, form and navigation patterns already wired together with a real data fetching approach. Do not adopt it expecting a finished product, because the pages ship with demo data and the chat and Pokemon examples are demos rather than integrations, and plan on replacing the mock layer before you show anything to users. Before you start, confirm you want a TanStack Start stack rather than the Next.js shadcn-dashboard template the README points to, check that your deployment target has a Nitro preset, and note that the repository publishes no GitHub releases, with the last push on 2026-08-07.

Frequently asked questions

Official sources

1. Issues
2. Kiranism/tanstack-start-dashboard on GitHub
3. License: MIT
4. Project website
5. README