SoybeanAdmin review: a Vue 3 admin template built around file-based routing

The problem SoybeanAdmin solves, and who it is actually for

Every Vue back office starts with the same two weeks of work: layout shell, sidebar, breadcrumbs, tab bar, theme switching, login flow, permission guards, 404 and 500 pages, and a route table that someone has to keep in sync with a folder of views. SoybeanAdmin ships that layer already assembled on Vue 3, Vite, TypeScript, Pinia, NaiveUI and UnoCSS, under the MIT licence. The README calls it a template, and that word matters. You are meant to clone it and delete what you do not need, not add it to a project you already have.

The intended reader is a front-end team that has already chosen Vue 3 and NaiveUI and wants the surrounding conventions decided for them. The project also publishes AntDesignVue and ElementPlus variants in separate repositories, plus a legacy branch, so the choice of component library is not locked to this repository. If your team has not settled on NaiveUI, that decision comes before this one.

It is a poor fit for anyone who wants a component library rather than an application shell. There is no npm package you install into an existing app; the repository is the starting point, and the monorepo layout is part of the deal.

How the routing, permissions and mock data actually fit together

The mechanism that separates SoybeanAdmin from a hand-rolled template is its file routing. The README states that it automatically generates route imports, declarations and types, and points to a companion project, Elegant Router, for the details. In practice that means the filesystem under the views directory is the source of truth, and the generated route table is an artifact you do not hand-edit. The repository exposes this through a script, gen-route, wired to the sa CLI. The trade-off is real: you gain consistency and lose the ability to keep routes in a file you control by hand, and a generated artifact that drifts from the folder structure becomes a debugging problem rather than a typo.

Permissions are handled in two modes at once. The README says the template supports both front-end static routes and back-end dynamic routes, so a backend can return the route list for a user and the client can also hold a fixed set. That covers the two common deployment shapes, but it also means the permission logic has two paths through it, and a team should decide early which one is authoritative rather than letting both run.

Data during development comes from an online mock scheme based on ApiFox, according to the README. That is a deliberate choice with a cost: your mock definitions live in a hosted service rather than in the repository, so contributors need access to it, and offline work is limited. Replacing it with your own API layer is expected, but the README does not document that migration path.

Installing SoybeanAdmin and getting a first route on screen

The repository is a pnpm monorepo. The package.json declares the package manager through its workspace files, and the scripts use pnpm conventions, so pnpm is the supported entry point rather than npm or yarn. Clone the repository, then install from the root.

pnpm install

This resolves the workspace packages (the @sa/axios, @sa/hooks, @sa/utils and similar entries in the dependencies) alongside the third-party ones. If the install fails on a workspace protocol version, that is the monorepo link step rather than a missing package.

To run the development server, the package.json defines dev as a Vite run in test mode, which is the mode that pairs with the mock data scheme.

pnpm dev

Vite prints a local URL in the terminal; open it and you land on the login page of the template. Note that dev and dev:prod are separate scripts, so the mode is not something you pass as a flag on the default command.

Adding a page is where the file routing shows up. The repository provides a generator rather than a documented folder convention in the README, so use the CLI the project ships.

pnpm gen-route

The README does not spell out the prompts this command asks, so run it and read them rather than guessing at flags. After it completes, the generated route declarations and types should reflect the new page. To check that the whole project still type-checks, the typecheck script runs vue-tsc.

pnpm typecheck

That command is worth running before you commit anything, because generated route types are exactly the kind of artifact that fails silently in the editor and loudly in CI.

Where SoybeanAdmin gets in your way

The strongest limitation is the one the README states as a feature. It is a template, and the repository is a pnpm monorepo with its own build directory, its own ESLint and oxlint configuration, its own formatting config, and a set of internal @sa packages. Adopting it means adopting that structure. If your organisation already has a monorepo, a lint policy, or a build pipeline, you are now reconciling two of each.

The lint setup is opinionated in a specific way. The README ties the project to the SoybeanJS standard and lists eslint, prettier and simple-git-hooks, while the package.json also carries oxlint and oxfmt commands. Two linters and two formatters in one repository is a maintenance surface, and the README does not explain which one is authoritative for which file type.

The mock scheme is the second constraint. Because it is based on ApiFox and hosted, the README's claim that the template works out of the box depends on that service being reachable. A team behind a restrictive network, or one that wants mocks versioned next to the code, will be replacing this on day one, and the README does not document how.

Finally, mobile support is listed as a feature, described as adaptive layout. The README does not describe breakpoints or which components adapt, so treat it as a starting point to verify on real devices rather than a guarantee. Nothing here is a defect; these are the costs of inheriting someone else's conventions.

SoybeanAdmin against Geeker Admin and the RuoYi-style stack

The obvious comparison is Geeker Admin, which appears in the related searches. Both are Vue 3 admin templates in the same visual family, and both target the clone-and-build workflow rather than packaging as a library. The difference that matters here is the routing model: SoybeanAdmin generates routes from the filesystem through Elegant Router, while a template that keeps a hand-written route table gives you a single file to read when a permission bug appears. Teams that debug by reading a route table will find the generated approach indirect; teams that have suffered route tables drifting out of sync with folders will prefer it.

The other comparison people search for is the RuoYi pairing, which usually means a Java backend issuing menus and permissions. That is precisely the back-end dynamic route mode the README describes, so the two fit together conceptually. The difference is where the work sits: RuoYi-style stacks typically generate the front-end views from backend table metadata, while SoybeanAdmin expects you to write views and let the router generate the wiring. If you want the backend to author the UI, this is the wrong tool.

The related searches also show people looking for React, Go and Java versions of SoybeanAdmin. The repository does not offer those; the variants it does publish are AntDesignVue, ElementPlus and a legacy branch, all Vue.

Maintenance, versioning and what the MIT licence means in practice

The repository is not archived, and the last push was on 2026-09-07. The most recent release is v2.2.0 from 2026-05-13, with v2.1.0 in March 2026 and v2.1.1 the same day as v2.2.0. The gap between the May release and the September push suggests work continues on the main branch between tagged releases, and the repository keeps both CHANGELOG.md and CHANGELOG.zh_CN.md, so upgrade notes exist.

Upgrade cost is the part to think about before you start. Because you clone the template, you do not receive upstream changes through a package manager. Pulling in a later version means diffing your modified tree against the new one, and any file you have edited in the generated route layer is a likely conflict. Teams that fork heavily should expect to track the changelog manually rather than merge.

The licence is MIT, stated in both the README badge and the package.json. That permits commercial use and modification, and it requires the licence and copyright notice to be preserved. The README also advertises paid custom development and enterprise outsourcing services, which is separate from the licence and does not restrict what you do with the code. This is a description of what the repository states, not legal advice; have your own counsel review the LICENSE file before shipping.

Editorial conclusion

Adopt SoybeanAdmin when you are starting a new Vue 3 back office and want routing, theming, permissions and i18n conventions already settled, and when your team is comfortable reading a pnpm monorepo. Do not adopt it to modernise an existing Vue 2 admin panel, because the template assumes you are building inside its own structure rather than wrapping yours. Before committing, verify that NaiveUI is the component library you want, that you can replace the ApiFox mock scheme with your own API layer, and that the front-end static and back-end dynamic permission modes both fit how your backend issues routes.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. soybeanjs/soybean-admin on GitHub