apisix-dashboard: a web frontend for operating Apache APISIX

A console for the gateway, not a replacement for it

Apache APISIX is the gateway, and this project is the window you use to drive it. The README says the dashboard is designed to make it as easy as possible for users to operate Apache APISIX through a frontend interface. That wording puts the scope correctly: the gateway still routes traffic, still terminates TLS, still applies plugins, and the dashboard does none of that. What it does is let an operator shape routes, upstreams and plugin configuration through forms, tables and an editor instead of assembling JSON payloads by hand against the admin API. The audience is operations and platform engineers who sit in front of an APISIX deployment and need to change routing quickly without becoming request-crafting experts. The primary language is TypeScript and the licence is Apache 2.0, which is the usual footing for a component of an Apache project.

The dashboard ships only as a tag inside an APISIX release

The versioning policy is the single most important operational fact here, and the README states it in two lines. The master version of the dashboard should be used with the Apache APISIX master version, and the project will not be released independently but will use a fixed git tag for each APISIX release. So there is no dashboard version number to track in the way you would track a normal npm package or a container tag. The repository's release list shows the consequence: a NOTICE artefact dated 2025-07-09, then v3.0.1 on 2023-03-24 and v2.15.1 on 2023-03-08, so the most recent tags carrying a version number belong to the gateway line. The code itself is moving, since the last push was on 2026-10-15, but the versioning belongs to the gateway and the tag you deploy is chosen to match the gateway you deploy.

Two UI libraries and a Monaco editor in one frontend

The dependency list in the package manifest is unusual enough to be worth reading closely. The project carries `antd` at version 5 along with `@ant-design/pro-components` and a React 19 patch package, and it also carries `@mantine/core`, `@mantine/hooks`, `@mantine/modals` and `@mantine/notifications`. Two component systems in one application is a deliberate-looking choice rather than an accident of dependency management, and it means the interface is a mixture of two design languages. Beyond that, `@monaco-editor/react` and `monaco-editor` are present, which is what gives the route and plugin configuration a real code editor with syntax handling rather than a plain text field. The rest of the stack is conventional: `react` 19.1.0 with `react-dom`, `@tanstack/react-query` for server state, `@tanstack/react-router` for routing, `jotai` for local state, `react-hook-form` with `@hookform/resolvers` for forms, `zod` for validation, `axios` and `qs` for HTTP, `dayjs` for dates, `immer` for immutable updates and `i18next` with `react-i18next` for translation.

The gateway schema is refreshed by a script, not by hand

One script in the package manifest explains a lot about how the dashboard stays in step with the gateway. The `refresh:gateway-schema` script runs `node scripts/refresh-gateway-schema.mjs`, and it is listed as a first-class npm script rather than a utility buried in the tree. A schema-driven admin console has to know the shape of the objects it is editing: which fields a route accepts, which plugin options are valid, what the upstream object looks like. Rather than hardcoding that knowledge in TypeScript types that drift, the project pulls it from the gateway side. The consequence for an operator is practical. When you upgrade APISIX to a version that adds a plugin option, the dashboard needs the matching schema, and that comes from running this script against the target gateway, not from waiting for a new dashboard release. The repository also has a `vite-plugin-i18n-progress.ts` file at the top level and `@m6web/eslint-plugin-i18n` in the dev dependencies, which tells you translation coverage is checked during linting rather than left to review.

Running the frontend locally with Vite

The development commands are all defined in the package manifest, and the toolchain is Vite with TypeScript project references:

"dev": "vite",
"build": "tsc -b && vite build",
"preview": "vite preview",
"test": "vitest run src",
"e2e": "playwright test"

So a local run is Vite's dev server, a production build type-checks first and then bundles, and the unit tests are Vitest scoped to the `src` directory. End-to-end tests run through Playwright, and the repository carries a `playwright.config.ts` plus an `e2e/` directory to hold them. The schema can be refreshed with the same script the release process uses:

node scripts/refresh-gateway-schema.mjs

Lint is part of the workflow too, and it is configured to fail on warnings:

"lint": "eslint . --cache --max-warnings=0 --no-warn-ignored",
"lint:fix": "pnpm lint --fix"

A `prepare` script runs husky, and a `.husky/` directory is present, so git hooks are installed on install. The repository also carries a `.devcontainer/` directory and a `netlify.toml`, which tells you the preview deployment story is built on Netlify rather than on a container image.

Where the console is the wrong shape of tool

An admin console and a version-controlled configuration workflow are close to opposites. A console is good when a change is exploratory, one-off, and made by a person who can see the result immediately. It is bad when the route table is a shared artefact that needs review, blame and rollback, because a click in a browser leaves no diff. The dashboard's own feature set leans toward the interactive case, with the Monaco editor and the Pro Components tables. The other limit is the release coupling described earlier. Because the interface is versioned by the gateway's tag, you cannot pick a newer dashboard to get a nicer table and keep an older APISIX, and you cannot take a security fix in the frontend without taking a matching gateway tag. A third limit is that the README is thin on operational detail: it points to a development guide under `docs/en/` and a contribution guide, and it says nothing about backup, audit logging of administrative changes, or multi-tenancy.

The alternative: driving the admin API from scripts

The alternative to a dashboard is calling the APISIX admin API directly from a script, a CI job or a configuration management tool. The difference in approach is where the change is authored. A console turns each change into a UI interaction and stores it in the gateway's own state; a script turns the same change into a versioned file that can be reviewed, replayed and rolled back, and it applies at deploy time rather than at click time. The cost of the script route is that you write and maintain the request shapes yourself, which is exactly the work the dashboard's schema file, validation and Monaco editor absorb. For a team that already runs infrastructure as code, the console adds a second source of truth. For a team without that practice, the console is the difference between an operable gateway and an operable gateway only for whoever knows the API.

Editorial conclusion

Adopt apisix-dashboard when a team needs a graphical way to manage APISIX routes, services and plugins and no one on the team wants to hand-edit the admin API calls. Skip it if your gateway configuration is meant to live in version control, because a click-driven admin console and a file-based configuration workflow pull in opposite directions. Before deploying, check the gateway schema file is current by running the refresh script, and pin the dashboard to the git tag that matches your APISIX version, since the project states the master branch should be used with the APISIX master version and the two are versioned together.

Frequently asked questions

Official sources

1. apache/apisix-dashboard on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases