AdminForth: An MIT TypeScript Admin Panel Framework Built Around a CLI
Create Agentic admin panels faster on TypeScript and Vue.js with AdminForth Framework. Setup main CRUD pages within minutes, extend as you need
At a glance
- What is it?
- AdminForth scaffolds CRUD back-office pages on top of an existing Postgres, MySQL, Mongo, SQLite or Clickhouse database, then lets you replace individual parts with Vue components. The interesting part is the workflow, not the feature list.
- Who is it for?
- Adopt AdminForth if you already have a database with its own migrations and want CRUD screens for it without writing them, and if your team writes Vue 3 and TypeScript. Do not adopt it if you need the tool to own your schema, since the documented existing-database path deliberately does not generate Prisma schema or migrations.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem AdminForth Solves Is the First Day, Not the Hundredth
Most admin panel projects fail at the same point: the first day. You have a database, you have tables, and you need filter, create, edit and remove screens for them. Writing that by hand is repetitive, and the frameworks that promise to remove the repetition usually demand that you restructure your data first. AdminForth takes the opposite position. The README's stated workflow is to run `npx adminforth create-app` with your database URL, then import tables with `npx adminforth resource`, and get a functional UI over data you already have. The audience is a TypeScript and Vue team that owns an application database and wants a back office beside it, not a new application. The README describes the project as agent-first and links an AI badge, but the concrete mechanism it documents is the CLI and the resource generator, so that is what an evaluation should be based on.
How the CLI Turns Existing Tables Into Resource Files
The data flow described in the README is linear. The CLI creates a project, the resource command reads your database and writes AdminForth resource files, and the running app serves CRUD pages from those files. Everything after that is replacement: `npx adminforth component` is the documented way to define Vue components that change specific parts of the admin, and the README lists the injection points as data cells, fields, something above the table, the header, the sidebar, and a fully custom page with charts. Express APIs can be defined and called from those components and pages. That layering is the actual architecture: generated defaults first, targeted Vue overrides second, custom endpoints third. It is a reasonable shape because the generated resource file is a file you own and can edit, not a runtime abstraction you have to fight. The trade-off is that the framework's surface area grows with every override, and the README does not describe how resource files behave when the underlying table changes after generation.
Two Setup Paths, and Only One of Them Touches Your Schema
The README separates setup into an existing database path and a new database path, and the distinction matters more than it first appears. For an existing database you pass `--db "postgresql://user:password@localhost:5432/dbname"`, or enter the URL when the CLI asks `Please specify the database URL to use`. The README is explicit that in this mode AdminForth connects to your database but does not create Prisma schema or migrations for it, and that the generated project README contains the SQL or schema notes needed to add the required `adminuser` table with your own migration tool. That `adminuser` table is a real constraint on the existing-database path: you must apply that change yourself before the panel works. For a new database you omit `--db` or accept the default `sqlite://.db.sqlite`, then run `pnpm makemigration --name init && pnpm migrate:local` and `pnpm dev`. Only this second path scaffolds Prisma files and migration scripts. Choose the path based on who owns your schema, not on which command is shorter.
The dev-demo Workflow Is for Changing AdminForth, Not for Using It
The README marks a section explicitly for AdminForth developers, and it is worth reading even if you never intend to modify the framework, because it reveals how the project is maintained. The dev-demo imports the repository source and plugins so edits show up live, and it requires Node.js 20, Docker, pnpm and Taskfile. Migrations are split by engine: Prisma migration folders for SQLite, Postgres and MySQL, and a separate `clickhouse_migrations` folder for Clickhouse. Applying them means `pnpm makemigration:sqlite -- --name init` followed by `pnpm migrate:sqlite`, with the README noting that you substitute `:sqlite`, `:mysql` or `:postgres` for your case, and `pnpm migrate:clickhouse` for Clickhouse. There is also a documented procedure for testing CLI changes: remove any global install with `pnpm uninstall -g adminforth`, then run `pnpm build` and `pnpm link` in the package directory, and afterwards invoke commands with `npx -g adminforth <command>`. This is a heavier contributor setup than a single test command, and it assumes Docker is available.
Five Databases Supported, With Clickhouse Treated Differently
The README lists Postgres, MySQL, Mongo, SQLite and Clickhouse as supported. That list is broad, but the repository layout shows the support is not uniform. Clickhouse gets its own migration folder and its own apply command rather than going through Prisma, while the other relational engines share the Prisma migration path. If your data lives in Clickhouse, expect the migration story to look different from the tutorials, and expect the resource generation step to be the part you verify earliest. The README does not describe how Mongo behaves in the resource generator or how the `adminuser` table requirement translates to a non-relational store, so treat Mongo as documented-but-unelaborated and confirm it against your own instance before designing around it. Breadth of database support is a claim about connectors, not a claim about equal behaviour across them.
Where AdminForth Is the Wrong Tool
AdminForth is the wrong choice when you want the tool to own your schema. The existing-database path is deliberately non-invasive, which means schema evolution, the `adminuser` table and any future AdminForth requirements land on your migration tooling. If your team cannot make schema changes on its own schedule, the new-database path is the only coherent option, and that means a separate SQLite-backed app rather than a panel over your production data. It is also the wrong tool if your front end is not Vue 3, because the documented extension mechanism is Vue components and the value of the framework drops sharply if you cannot use it. Finally, the plugin list in the README (audit log, file and image upload, TOTP 2FA, I18N, AI writing and image generation) is a list of names, not a description of behaviour or configuration. Do not select AdminForth for a plugin you have not read the documentation for. Version numbers in this project move quickly, with v3.17.4, v3.17.3 and v3.17.2 all released within roughly a week of each other according to the release list, so pin the version you evaluate.
Alternatives and the Real Difference in Approach
The closest general-purpose comparison is a schema-first admin generator that introspects your database and produces a running panel, as opposed to a code-first framework where you write resource files and Vue components. AdminForth sits closer to the second camp despite the CLI, because the generated resource file is meant to be edited and the customization path runs through Vue. The difference that matters in practice is what happens when you need something the generator did not anticipate. In a purely introspective tool you are often stuck at the edge of its templates. In AdminForth the documented answer is `npx adminforth component`, which replaces a named part of the UI with your own Vue code, and Express APIs you define yourself. That is more work per customization but a higher ceiling. If your back office will stay close to default CRUD, the extra machinery is overhead. If you expect to replace half the screens, it is the reason to pick this. The README's claim that AdminForth is always free and open source, with no paid versions and no cloud subscriptions, is a positioning statement worth weighing against tools that gate features behind a hosted tier.
Licence, Maintenance and What to Pin
AdminForth is MIT licensed, which permits commercial use, modification and redistribution provided the licence notice is preserved. That is a permissive arrangement, but it says nothing about the plugins, the demo application or any third-party dependency in the tree, and the README does not enumerate their licences. Check those separately if your organization has licence review. On maintenance, the release cadence visible in the repository is fast: three patch releases (v3.17.4, v3.17.3, v3.17.2) between 2026-09-04 and 2026-09-09. Fast patch cadence is a double-edged signal. It suggests active work, and it also means the surface you integrate against can shift under you during a build. Pin an exact version in your lockfile, read the release notes for the versions between your pin and any upgrade, and re-run `npx adminforth resource` after upgrading to confirm your generated files still match your tables. The cost that the README does not quantify is the cost of the `adminuser` table and any future schema requirement landing in your own migration pipeline; budget for that as ongoing work rather than a one-time setup step.
Editorial conclusion
Adopt AdminForth if you already have a database with its own migrations and want CRUD screens for it without writing them, and if your team writes Vue 3 and TypeScript. Do not adopt it if you need the tool to own your schema, since the documented existing-database path deliberately does not generate Prisma schema or migrations. Before committing, verify one thing first: that your database URL connects and that `npx adminforth resource` produces resource files for your real tables, because that step is the whole premise of the framework.
Community notes