abp-next-admin is an ABP vNext admin console on the vben5 workspace

An admin console for ABP vNext, and the audience it assumes

The project description is short. It is an administration interface for the ABP framework, based on the vue-vben-admin template, and it targets ABP vNext. That is the whole scope, and the scope is the point. ABP is a modular application framework with its own conventions for multi-tenancy, permissions, auditing, feature flags and settings, and a generic admin template that does not know about them is of limited use. abp-next-admin fills that gap by shipping the ABP specific layer, from the login and account flows to auditing screens, feature management, tenant and edition handling, and the data dictionary. The screenshots in the repository show the shape of what you get, including system logging, audit logging, security logging, data dictionary, object storage, feature management, system settings, menu management, organisation units and localisation. The audience is a .NET team with ABP on the backend, not a general purpose admin starter kit.

Twenty-seven @abp packages carry the business layer

The front end lives in apps/vben5 and is organised as a pnpm workspace with turbo, and the interesting part is the packages/@abp directory, which holds 27 business packages. They include account for accounts and third party login binding, identity for users, roles, organisation units, sessions and login logs, permissions for permission definition and granting, platform for layout, menus, the data dictionary and email or SMS, settings, auditing for audit and security logs, blob-management and oss for object storage, cache-management, features for feature management, saas for tenants and editions, notifications, openiddict for applications, scopes, grants and tokens, signalr for real time communication, tasks for background job management, text-templating, webhooks, gdpr for data export and deletion, data-protection for entity and field level access control, ai-management for workspaces, tools and agents, and wechat for the public account and enterprise WeChat. Beside them sit @core for the base, ui-kit and forward packages, effects for plugins, hooks and common UI, and icons and types. This is where the value sits, since request handling, permissions and menus are the layers every ABP front end has to write.

The vben5 workspace keeps the upstream sample apps next to the ABP one

The apps/ directory of the workspace holds several runnable UI applications. app-antd is the ABP business front end and the one in current use, with pnpm dev:app and pnpm build:app as its scripts. The rest are the upstream vben sample applications, web-antd, web-antdv-next, web-ele for Element Plus, web-naive and web-tdesign, and they are kept so that the shared ui-kit, the effects packages and the internal engineering configuration can be developed against more than one design system. The root package.json holds the pipeline scripts, dev, dev:app, build:app, lint, format, test:unit and check:type, and pnpm-workspace.yaml holds the workspace split and the dependency catalog, with turbo.json holding the pipeline configuration and vitest.config.ts the unit test configuration. internal/ holds the engineering layer, vite-config, lint-configs, tailwind-config, tsconfig and node-utils, and docs/ is a VitePress site. The practical effect is that the ABP application is one consumer of a shared library set rather than a standalone app.

One container or thirteen services, on fixed ports

The deployment choice is the largest decision in the repository. The documentation offers a monolithic service deployment for teams that do not need a microservice architecture, on the grounds that it is simpler to deploy and easier to maintain, with a startup guide in the docs directory, and a microservice deployment for teams that want more scalability and a more flexible service architecture. The docker compose file shows what the microservice layout looks like in practice. The auth server maps to 44385, the admin service to 30010, the identity service to 30015, the message service to 30020, the platform service to 30025, the localisation service to 30030, the task service to 30040, the webhook service to 30045, the workflow service to 30050, the WeChat service to 30060 and the AI service to 30070. There is also an AllInOne host on port 30000, described as a monolithic application that merges the gateway and all modules. Each service has a healthcheck that probes /healthz with wget, runs on a shared network named abp-next-admin, and maps host.docker.internal, and the repository also carries tye.yaml, a gateways directory, a deploy directory and several docker-compose override files for agile, configuration and default overrides.

Scaffolding a microservice project with the abp cli

The quick start for the microservice route is a sequence of shell commands. The hosts file needs an entry so that containers can reach the host, and on Linux the network is restarted afterwards:

/etc/init.d/network restart

Then the tooling and the template are installed globally:

dotnet tool install --global LINGYUN.Abp.Cli
dotnet new --install LINGYUN.Abp.MicroService.Templates

The cli then creates the project, and the create command takes the company and project names, the package name, an output directory, the database provider and the connection string, with a flag to keep the default ports instead of random ones:

labp create MyCompanyName.MyProjectName -pk MyPackageName -o "D:\Project" --dbms sqlserver --cs "Server=127.0.0.1;Database=MyProject;User Id=sa;Password=123456" --no-random-port

The comments explain that the default application port is 5000 and the dapr listener port is 3500, and that the flags correspond to the abp cli options. After creation you restore, run, and open the site:

cd D:\Project\host\MyPackageName.MyCompanyName.MyProjectName.HttpApi.Host
dotnet restore
dotnet run
start http://127.0.0.1:5000/

Note that the create step takes a database password on the command line, which lands in shell history, and that the generated project directory and host names are driven by the same three names you pass in.

What the backend side contains under aspnet-core

The backend is not a thin layer. Under aspnet-core there are two directories that matter. The services/ directory holds the hosts, each with its own Dockerfile, and it is where the port list and the AllInOne variant live. The modules/ directory holds the business modules, each layered in the DDD style, with Domain, Application, EntityFrameworkCore and HttpApi projects, and the modules visible in the documentation include account, covering accounts, login, the OpenIddict and IdentityServer web integration and verification codes, and identity. The repository also carries gateways/, build/, starter/, common.props, common.secrets.props, configureawait.props, Directory.Build.props, Directory.Packages.props and NuGet.Config, which is the set of files a .NET monorepo needs for central package management and shared build settings. A NuGet package, LINGYUN.Abp.Core, is published alongside, so some of the shared pieces are consumed as a package rather than only as source.

One maintainer, and a warning that is part of the documentation

The project page carries an unusual and useful note about maintenance. The author states that they are not a freelancer and do not have a great deal of time to maintain the project, and points to an email address and a QQ group for problems. That is the honest version of the bus factor, and it is better to read it before you depend on the project than to discover it later. The activity is real regardless. Releases 10.2.0, 10.4.0 and 10.6.0 were published on 2026-04-25, 2026-06-18 and 2026-09-23, the last push was on 2026-10-19, the default branch is dev, and the repository has a RELEASE.md with release notes, a.changes directory, lefthook.yml for git hooks, and a build workflow. The licence is MIT. The honest assessment is that this is a substantial and actively worked system maintained by someone with limited spare time, which is a fine arrangement for a product team that owns the code and a poor one for a team that expects a vendor to answer tickets.

Editorial conclusion

abp-next-admin is a reasonable starting point for a team whose backend is already ABP vNext and who do not want to rebuild the request, permission and menu layers, because those 27 packages are the expensive part of an ABP front end and they are already written. It is a poor fit for a team that has chosen a different admin template, and it is a real risk for anyone who needs long-term support, since the maintainer states plainly that this is not a freelance project and that time for maintenance is limited. Before adopting it, read RELEASE.md for the change history, confirm the docker compose port layout does not collide with what you already run, and try the AllInOne service first, because switching to a microservice layout later is a different deployment story from the one you start with.

Frequently asked questions

Official sources

1. colinin/abp-next-admin on GitHub
2. Issues
3. License: MIT
4. README
5. Releases