# Kiranism/next-shadcn-dashboard-starter: a working admin dashboard, not a mockup > The MIT-licensed Next.js 16 starter from Kiranism ships real tables, forms, Clerk auth and billing, plus a cleanup script that strips what you do not want. Here is what it actually contains and where it stops being the right base. **Kiranism/next-shadcn-dashboard-starter** — Free, open source, AI-friendly admin dashboard template built with Next.js 16, shadcn/ui, Tailwind CSS, and TypeScript. Production-ready tables, forms, auth, and billing. MIT licensed. - Repository: https://github.com/Kiranism/next-shadcn-dashboard-starter - Website: https://dub.sh/shadcn-dashboard - Stars: 7,093 · Forks: 1,607 - Language: TypeScript - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/kiranism-next-shadcn-dashboard-starter ## What next-shadcn-dashboard-starter is for Most dashboard templates are screenshots that compile. The README makes a direct claim about the difference: "Every feature is a working, production-ready implementation, not static demo UI." Tables search, filter, sort and paginate against real data flow. Forms validate with Zod and mutate with cache invalidation. Auth, organizations and billing run end to end through Clerk. The intended audience is narrow and stated plainly: SaaS admin dashboards, internal tools and operations panels, analytics dashboards, client project admin panels, and a starting point for new Next.js shadcn projects. If you are building a marketing site with one login form, this is the wrong shape. The template is opinionated about tenancy (Clerk Organizations), about billing (Clerk Billing for B2B), and about the data layer (TanStack React Query). Those three choices decide whether it saves you a week or costs you one. ## How the data layer actually flows The README names the pattern explicitly: server prefetch, then HydrationBoundary, then useSuspenseQuery on the client. That is the official TanStack Query SSR recipe, and it is the detail that separates this from templates that fetch in useEffect and call it done. The server renders with data already in the cache, the boundary hands that cache to the client, and the client component suspends on the same query key rather than refetching on mount. URL state is handled by nuqs rather than local component state, so search, filtering, sorting and pagination survive a refresh and can be shared as a link. Forms use TanStack Form with Zod schemas, and the README mentions multi-step and dialog/sheet variants as first-class patterns, with real create and update mutations that invalidate the cache on success. The folder structure is feature-based, with an API layer per feature, which is what makes the cleanup script possible: features are removable because they are self-contained. One consequence worth naming. Because the pattern is the standard one, the code is copyable into a production codebase, but it is also the code you would have written yourself. If your team already has a preferred data-fetching convention, this template will fight it. ## Installing it and rendering the first real table The repository ships a bun.lock and a bunfig.toml, and the package scripts call bun in lint:fix, so bun is the expected package manager. The README points at a hosted demo, and the Dockerfile installs bun explicitly with npm install -g bun before running bun install --no-save --frozen-lockfile. A local start therefore looks like this: ```bash bun install bun dev ``` Environment variables are templated in env.example.txt at the repository root. Clerk keys are the ones the Dockerfile passes as build arguments, so copy the example file to .env.local and fill in the publishable key before the app will authenticate anyone: ```bash cp env.example.txt .env.local # set NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY from your Clerk dashboard bun dev ``` The README gives the Docker path too, and the Dockerfile is a three-stage build. The builder stage passes NEXT_PUBLIC_CLERK_SIGN_IN_URL=/auth/sign-in and NEXT_PUBLIC_CLERK_SIGN_UP_URL=/auth/sign-up as defaults, and the runner stage sets PORT=3000 and HOSTNAME="0.0.0.0" while copying the standalone output. If you build the image without passing a Clerk publishable key as a build argument, the auth routes will not have a key to work with. ```bash docker build -t shadcn-dashboard . docker run -p 3000:3000 shadcn-dashboard ``` The README also documents a cleanup script, exposed as the cleanup npm script running node scripts/cleanup.js, which it says strips any feature you do not need "in under a minute." Run it before you start renaming things, not after. ## The v2.0.0 component migration and what it costs The two releases were published on the same day, 2026-07-18, and they are a fork in the road rather than a sequence. v1.0.0 is labelled "Final Radix UI release (Next.js 16, shadcn/ui on Radix)." v2.0.0 is "shadcn/ui on Base UI (Next.js 16, Tailwind CSS v4)." That means the current main branch sits on Base UI primitives, and any component-level code you have written against Radix-based shadcn/ui will need review when you move to v2. The README lists the stack as shadcn/ui "on Base UI primitives," and package.json carries @base-ui/react alongside @shadcn/react and @shadcn/helpers. This is a real migration cost, not a cosmetic version bump, and the existence of a preserved v1.0.0 tag is the project's acknowledgement of that. If you are starting fresh, take v2.0.0. If you have an existing Radix-based codebase you were planning to merge into this template, budget time for the primitive swap, or start from the v1.0.0 tag and accept that it is described as final. ## Where this template is the wrong tool The identity and billing layers are Clerk, and the README is candid about the relationship: the project carries a "Sponsored by Clerk" badge and links to Clerk through a referral URL. That is not a hidden problem, but it is a dependency you should price in. If your organisation uses Auth.js, Supabase Auth, Cognito or a homegrown session system, you are not adopting a template, you are replacing its auth layer, and the RBAC navigation, organization switching and B2B billing all sit on top of Clerk. The README does not document an alternative provider, and no rollback path away from Clerk is described. There is also no database in the stack. The README lists the data-fetching library, the validation library and the state library, but no ORM, no migrations, no schema. The tables and forms are wired to an API layer that you supply. That is a deliberate boundary, and it is why the template stays small, but it means "production-ready tables" describes the client behaviour, not persistence. Finally, the repository root contains AGENTS.md, CLAUDE.md, a .agents directory and a .claude directory, and the description calls the project "AI-friendly." If your team has opinions about committing agent configuration to the main branch, that is a decision you inherit. ## How it compares with a TanStack Start dashboard The README links to a separate repository for a TanStack Start version of the dashboard. That is the most relevant alternative, and the difference is architectural rather than cosmetic. This project is a Next.js 16 application: the App Router, server components, parallel routes for per-section loading and error states, and a Dockerfile that copies .next/standalone. The TanStack Start version moves the routing and server-function layer to TanStack's own stack. If your team is already committed to Next.js, the choice is straightforward and this template is the one that matches your deployment target. If you are choosing a framework now and you already use TanStack Query and TanStack Table heavily, the Start variant keeps more of the same vocabulary in one ecosystem. Neither is a drop-in for the other, so pick before you write feature code, not after. The other comparison worth making is against the project it is named after in search results, Arhamkhnz/next-shadcn-admin-dashboard. Both are shadcn admin dashboards, and the distinguishing facts here are the Clerk organizations and billing integration, the nuqs URL state, and the cleanup script. If you do not need multi-tenant billing, that difference largely evaporates. ## Maintenance, licence and upgrade cost The last push to the repository was on 2026-09-11, and the repository is not archived. Releases are infrequent and large: v1.0.0 and v2.0.0 both landed on 2026-07-18, and before that there is nothing in the release list. Expect the interesting changes to arrive as tagged migrations rather than a steady drip, which is easier to plan around but means you should read release notes before pulling. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it is compatible with closed-source products. It is not legal advice, and if you are redistributing the template as part of a product, read the LICENSE file at the repository root rather than a summary. Upgrade cost is dominated by two things: the Base UI migration described above, and the pinned dependency set. package.json pins next to 16.2.12 and react to 19.2.4 exactly, not with a caret, so a Next.js minor release does not arrive on its own. The Dockerfile sets NEXT_TELEMETRY_DISABLED=1 and builds with BUILD_STANDALONE=true, so if you deploy the container you are also maintaining that build configuration as the framework changes. ## Conclusion Adopt it if you are building a SaaS or internal admin panel on Next.js 16 and want Clerk for auth, organizations and billing, because the tables, forms and cache invalidation are already wired the way TanStack Query's SSR pattern prescribes. Do not adopt it if you need a different identity provider, a database layer, or you are staying on the Radix-based component stack. Verify first that your Node version matches the Dockerfile's 22-slim base, that you have Clerk keys for NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY, and that you actually want the feature set the cleanup script will remove. ## FAQ ### How do I install next-shadcn-dashboard-starter locally? The repository ships a bun.lock and bunfig.toml, so install with bun install and start the dev server with bun dev. Copy env.example.txt to .env.local and set the Clerk publishable key before the auth routes will work. ### Does next-shadcn-dashboard-starter include a database or ORM? No. The README lists the data-fetching, validation and state libraries but no ORM, migrations or schema. The tables and forms are wired to an API layer that you provide, so persistence is your responsibility. ### Can I use next-shadcn-dashboard-starter with an auth provider other than Clerk? The README does not document an alternative provider. RBAC navigation, organization switching and B2B billing are built on Clerk, so swapping it means replacing those layers yourself. ### What changed between v1.0.0 and v2.0.0 of next-shadcn-dashboard-starter? v1.0.0 is labelled the final Radix UI release, and v2.0.0 moves shadcn/ui onto Base UI primitives while staying on Next.js 16. Both releases were published on 2026-07-18. ## Sources - [Kiranism/next-shadcn-dashboard-starter on GitHub](https://github.com/Kiranism/next-shadcn-dashboard-starter) - [License: MIT](https://github.com/Kiranism/next-shadcn-dashboard-starter/blob/main/LICENSE) - [Project website](https://dub.sh/shadcn-dashboard) - [README](https://github.com/Kiranism/next-shadcn-dashboard-starter/blob/main/README.md) - [Releases](https://github.com/Kiranism/next-shadcn-dashboard-starter/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kiranism-next-shadcn-dashboard-starter