Ape-Volo-Admin: a .NET 8 and Vue 3 admin system with data permissions

What the project is and where the front end lives

Ape-Volo-Admin is a permission management and administration system solution for enterprise scenarios, meant to let you build the common admin capabilities of users, roles, menus, interface permissions and data permissions quickly and then extend them.

The stack is .NET 8, SqlSugar, Vue 3, Element Plus and Vite, and the README says it works out of the box while leaving room to extend, and that it suits most .NET and C# projects.

The three claims it makes for itself are worth separating. The general capabilities are complete, with authentication and authorisation, audit logging, caching, task scheduling, rate limiting, data permissions and internationalisation. The architecture is layered and modular, with an interface layer, a business layer and an infrastructure layer, so that each can be extended or replaced. And the integration is low-touch, with the core capabilities provided in a general way and as little hard binding to business code as possible.

The front end is a separate repository, `ape-volo-web`, and the backend is this one. Both are published on GitHub and on Gitee, and the README lists the two URLs for each.

There is a live demo at a separate subdomain, with the credentials apevolo and 123456 published in the README, and the project site is at apevolo.com.

The project is Apache-2.0 licensed, the primary language in the metadata is C#, the default branch is master, and the last push was on 2026-04-15. The releases are V3.5.2 from 2026-04-14, V3.5.1 from 2026-02-06 and V3.4.1 from 2025-05-03.

Twelve projects, and what each one is for

The module table is the clearest description of the architecture, and it is worth reading as a map of the layers.

The interface layer is the Web API and controller layer, providing the entry points for the REST API, authentication and authorisation, rate limiting and auditing. The business layer is where the business services are implemented, with the orchestration, the domain logic and the application services. The general basics are the utility and extension libraries, with common helper classes, extension methods and file and image processing. The core capabilities hold the core components, which is where the AOP interception, the system configuration and the App services live.

Then the data entities, the entity mapping layer with the database entity mapping and the base entity definitions. The event bus, with event publishing and subscription and an integration point for message middleware. The business contracts, which are the business service interfaces and the outward facing contract definitions. The infrastructure extension layer, with dependency injection, authentication and authorisation extensions and middleware. The repository and unit of work layer, with the data access encapsulation, transactions and the repository extensions. The shared models, holding the request DTOs, the query parameters and the validators. The job and scheduler layer, for scheduled tasks and the task service implementation. And the view model layer, for the UI and presentation objects and the front end interaction model.

The repository root reflects the same structure as a solution file and twelve project directories, from `Ape.Volo.Api` through `Ape.Volo.Business`, `Ape.Volo.Common`, `Ape.Volo.Core`, `Ape.Volo.Entity`, `Ape.Volo.EventBus`, `Ape.Volo.IBusiness`, `Ape.Volo.Infrastructure`, `Ape.Volo.Repository`, `Ape.Volo.SharedModel`, `Ape.Volo.TaskService` and `Ape.Volo.ViewModel`.

The `I` in `IBusiness` is a marker for the interfaces assembly, which is a common .NET convention and one that the layer names make visible.

The feature list, and the part that is actually unusual

The features list is long, and most of it is standard. It is worth picking out the ones that tell you what kind of project this is.

The programming model is fully async and await, the code is organised as repository plus service plus interface into a RESTful style API, and the ORM is SqlSugar in CodeFirst mode with a `BaseService` wrapping the basic database operations.

Caching appears three times. It supports both Redis and `DistributedCache`, and it extends SqlSugar with a second-level cache. The logging is Serilog, with sinks for the database, the console, files and Elasticsearch. Scheduling is Quartz.NET wrapped into a scheduler centre.

The two interceptors are the part worth reading twice. A cache interceptor handles caching of business method results, and a transaction interceptor gives business method database operations automatic transaction handling. That is an aspect-oriented approach, and the repository topics list aop, which confirms it.

And then there is the authorisation work, which is the reason to use this project rather than write one. Custom authentication is implemented by overriding the ASP.NET Core `AuthorizationHandler` to implement custom rules. Data permissions come in five scopes: all, self, my department, my department and below, and custom. Multi-tenancy supports both ID isolation and database isolation. Data capabilities include read and write separation, multiple databases and table sharding.

The database list is unusual in its breadth, supporting MySql, SqlServer, Sqlite, Oracle, PostgreSQL, and the Chinese engines Dameng, Shentong and GaussDB, and the message queue support is RabbitMQ and RedisMQ.

The remaining features are the ones an admin system needs and rarely gets right: a unified exception filter and an audit filter recording system exceptions and interface requests, centralised configuration reading and management of `appsettings.json`, CORS with interface rate limiting, and data dictionaries, custom settings and internationalisation.

Running it, which needs nothing but the SDK

The quick start is short, and its most useful feature is that it needs no database server to try.

The environment is the.NET SDK at 8.x, and the recommended IDEs are JetBrains Rider, Visual Studio or VS Code. The default run configuration is Sqlite with `DistributedCache`.

You start the backend API service from the WebAPI project in the solution, and on the first run the application creates the database tables and initialises the base data. The command line alternative, run from the repository root, is:

dotnet restore
dotnet run --project .\Ape.Volo.Api\Ape.Volo.Api.csproj

That first-run behaviour is the single most useful thing about the setup. A CodeFirst ORM plus automatic seeding means a new developer can have a working system with a login, roles and menus in the time it takes to restore packages, with no MySQL to install and no migration to run by hand.

The tradeoff is that the Sqlite default is a development convenience, not a production configuration, and the same code has to be pointed at one of the other supported databases before it is used for anything real.

The repository also carries a `Dockerfile`-related `.dockerignore` and the solution file `Ape.Volo.Admin.sln`, so the build is a standard Visual Studio solution rather than a custom one.

The licence section, which has a condition in it

The licence section is short, and not all of it is the usual boilerplate.

The project asks you to strictly follow the Apache 2.0 licence and to keep the original work statement. Then it says that if you need to remove the copyright information you must first obtain authorisation, and that unauthorised removal of the copyright information will be pursued through legal process.

So this is Apache 2.0 with an added condition, and the metadata records the licence as Apache-2.0 without noting the addition. For an organisation with a legal review step, that difference is the whole point of the review, and the README is explicit about it, which is better than a licence that contradicts the documentation.

The practical reading for an adopter is that you can use the code, modify it and ship it, provided the attribution stays, and that stripping the notice is a licensing question rather than a formatting preference.

There is also a Go version of the project, in a separate repository, `ape-volo-admin-go`. The README is careful about what it is, describing it as an incidental product of the author's interest in the language, a replica implementation based on the functionality and interface design of the.NET version in this repository, with the.NET version as the main line and the reference when the two differ.

Where Ape-Volo-Admin is the wrong choice

The first wrong case is a team that wants a lightweight starting point. The twelve projects, the `BaseService` base class, the interceptor style and the code-first seeding are opinions, and the ones you disagree with are the ones you have to unpick.

The second is a team that has standardised on Entity Framework Core. The data layer is SqlSugar, and it is not a swap that a project can make in an afternoon, because the repository layer, the unit of work and the second-level cache all speak SqlSugar.

The third is a team that has standardised on a different front end. Vue 3, Element Plus and Vite are the choices, and the shared model and view model projects are shaped around them.

The fourth is an organisation whose licence review will stop at the Apache 2.0 badge. The README's extra condition about retaining the copyright statement and seeking authorisation before removing it has to be read, and if the answer is that the notice must go, this is not the codebase to start from.

The fifth is a project that needs a data permission model with more than five scopes. The built-in options are all, self, my department, my department and below, and custom. A real organisation's rules are usually a tree, and the custom option is where that work lands.

For a team that wants the full set of admin plumbing with the wiring already done, and that is happy with the choices in the repository, this is a substantial amount of work handed over rather than built.

Editorial conclusion

Ape-Volo-Admin suits a .NET team that needs the unglamorous parts of an admin system, which are user, role, menu, interface and data permissions, and that wants them assembled in a layered structure it can extend. It does not suit a team that wants a minimal starting point, because the twelve projects, the ORM conventions and the interceptor style are opinions rather than defaults, and it does not suit a team that expects a permissive licence without conditions, because the Apache 2.0 grant in the README comes with an explicit requirement to keep the original work statement and a stated intention to pursue unauthorised removal of copyright information. Before adopting it, read the licence section rather than the badge, and check the data permission model against your own rules, since the built-in scopes are all, self, my department, my department and below, and custom.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xianhc/ape-volo-admin on GitHub