React Admin Panel Template

Admin panels often start as small internal tools. Support needs to look up a user, so someone adds a protected page. Over time, that page may gain subscription controls and other writes to production without a corresponding permission model or deployment boundary.

Picking a react admin panel template includes deciding where that boundary sits and how much of it the template enforces in code.

Three ways to get an admin, and what each costs

Auto-CRUD generator

Hand-built

First screen

Minutes: generate the app and rebrand it

Minutes: point it at a schema and it renders

Days, per screen

Custom logic

Ordinary React and Hono code in your repo

Escape hatches, overrides, then a rewrite

Whatever you want, you wrote it

Auth boundary

Shared session, then a role looked up in a staff table the customer has no row in

Usually a flag on the customer's own user record

Depends on the authentication and authorization design

Deploy target

Its own Vite build, so it can sit behind a VPN or allowlist

A route inside your public app

Your choice

In five years

Source you own, no upstream to track

A dependency whose opinions you inherited

Exactly what you maintained

Browse all packs

An auto-CRUD generator is usually faster for the first screen. If your admin covers five tables and serves two trusted people, that may be enough. This template is aimed at admin tools that need custom business logic, broader staff access, or a separate deployment boundary.

The authorization and deployment boundary

apps/admin is its own application in the monorepo with its own Vite build, next to the public frontend and the Hono backend. That separation has three practical effects:

• Its own authorization, on a shared session. getAdminApp() is new Hono().use(withAuthUser).use(withAdmin), so a request carries the same session cookie a customer would, and then withAdmin looks the user up and throws a 403 unless they are staff. The session is shared. The authorization is not, and it is a lookup rather than a flag.
• Its own role vocabulary, in its own table. Platform roles are super_admin and admin, and they live in an Admin table that has nothing to do with the organization roles your tenants use. Being manage:all inside a tenant does not grant access here. Managing other admins is restricted to super_admin.
• Its own deploy. Because it builds separately, you can put it behind a VPN, an IP allowlist, or a private hostname without touching the public frontend or its CDN config.

The first admin needs a bootstrap path. This template resolves it through an environment variable:

// features/admin/helpers/super-admin.ts
export const resolveAdminAccess = async ({
  userId,
  email,
}: {
  userId: string;
  email?: string | null;
}): Promise<AdminRole | null> => {
  if (isSuperAdminEmail(email)) return AdminRole.SUPER_ADMIN;

  const row = await getAdminQuery({ email, userId });
  return row?.role ?? null;
};

SUPER_ADMIN_EMAIL is a comma-separated environment variable, and the addresses in it are super admins whether or not they have a row in the admin table. Nothing is auto-inserted. A fresh database has an owner because the environment says so, and revoking that access requires changing the environment and deploying again.

An integration test verifies this behavior. admin.access-matrix.integration.test.ts runs five cases against real routes: a signed-in non-admin gets a 403, an admin is admitted and reports ADMIN, a bootstrap super admin is admitted and reports SUPER_ADMIN with no database row, a plain admin is blocked from the super_admin-only surface, and a super admin can list it. If a change loosens the middleware, that file fails.

It shares the typed SDK with everything else, so an endpoint added for an admin screen is typed on the client the same way a customer endpoint is.

What the included screens support

One useful way to judge an admin panel is to map its screens to the support and operations questions it can answer:

Those are queries against your own data, written as ordinary feature modules. Adding a widget means adding a Hono route and a card rather than using a plugin extension API. That gives you room to support questions the included screens do not cover.

What it deliberately does not have

There is no audit log UI. If you need "who changed this record and when" for compliance, you must add it. Audit scope and retention requirements vary by company, so the template does not prescribe a generic implementation.

This gap matters because an admin panel contains write endpoints pointed at production. The authorization boundary decides who can reach them. An audit log records what they changed.

How far to take the boundary

Admin panels can sit at different points on the same isolation axis. Small internal tools often begin inside the main application, while tools with stricter access requirements may justify a separate build, session, or network.

When evaluating an admin template, check how a request proves it is allowed and which tests fail if that protection is removed. Screens can be changed as requirements grow, but the access boundary affects every admin route.

The admin app is below, running, alongside the files it installs.