AcePanel: a Go server operations panel you can stop after deployment

What AcePanel solves, and who it is aimed at

Managing a Linux server by hand means remembering where each service keeps its config, which systemd unit owns it, and what the last person changed. AcePanel is a web control panel that puts those operations behind one interface: site deployment, service management, scheduled tasks. The README describes it as a general-purpose operations panel rather than a hosting-only tool, and lists both quick deployment of small sites and customised deployment of complex applications as target uses.

The stated audience is the operator who wants that convenience without inheriting a large footprint. The README's first advantage is low resource use: Go, a small install package, a single file that runs, and no impact on system performance. The second is low destructiveness, phrased as reducing extra modifications to the system and making fewer changes than comparable products. Those two claims together define who this is for. Someone who wants a panel but resents panels that rewrite the host's package sources, drop their own nginx build in place of the distribution's, and leave debris behind after uninstall.

The project is not new. The README carries a migration note for users moving from an earlier product, 耗子面板 2.x, to AcePanel 3.0, which means there is an installed base with existing configuration. The repository is at v3.3.4, released on 2026-08-28, with v3.3.3 and v3.3.2 earlier that month. The last push to main was on 2026-08-28, so the project is still being worked on as of that date.

How the panel is put together: Go binary, Chi router, SQLite, Docker client

The repository layout is a conventional Go service: cmd/ for entry points, internal/ for application code, pkg/ for reusable packages, web/ for the frontend, storage/ for persistent state, and a config.example.yml at the root. The module path in go.mod is github.com/acepanel/panel/v3, so the current line is a v3 module, which is why the migration note from 2.x exists.

The HTTP layer is go-chi/chi with go-chi/httplog for request logging, and libtnb/chix wraps it. Sessions come from libtnb/sessions with libtnb/gormstore, and persistence is libtnb/sqlite on top of GORM, with go-gormigrate handling schema migrations. That is a single-file database rather than an external MySQL or PostgreSQL requirement, which matches the single-binary claim. Both go-sql-driver/mysql and lib/pq appear in the dependency list, so the panel can also talk to MySQL and PostgreSQL, most likely for the sites and applications it manages rather than for its own storage.

Several dependencies say what the panel actually does. github.com/moby/moby/client and the containerd errdefs package indicate Docker integration. coreos/go-systemd and creack/pty indicate systemd unit control and terminal sessions in the browser. cilium/ebpf is unusual for a control panel; it suggests kernel-level metrics or connection observation. go-webauthn/webauthn and dchest/captcha cover authentication, mholt/acmez handles ACME certificate issuance, and the libdns family (Cloudflare, Alibaba, Tencent Cloud, Huawei Cloud, Porkbun, NameSilo, ClouDNS, West.cn, Gcore) covers DNS-01 challenges across providers. libtnb/cron and libtnb/logrotate handle scheduled jobs and log rotation. The presence of expr-lang/expr points to user-supplied expressions somewhere in configuration or rules.

None of this is documented in the README. The README gives a feature list and an install command; the architecture above is inferred from go.mod and the top-level directory listing, which is the honest source for it.

Installing AcePanel and reaching the panel for the first time

The README supports amd64 and arm64 on what it calls clean mainstream systems, and points to the install documentation at acepanel.github.io/quickstart/install for the exact list. That page, not the README, is where you check whether your distribution qualifies. The README's install path is a single helper script:

bash <(curl -sSLm 10 https://dl.acepanel.net/helper.sh)

The curl flags matter: -sSL follows redirects silently, and -m 10 caps the download at ten seconds. The script is piped into bash, so read it before running it on a production host if your policy requires that. The README does not document a package-manager alternative, a Docker image, or an offline installer for the panel itself, so the helper script is the only install route the README gives.

After installation, the panel is a running process that you reach over HTTP and log into with the credentials the installer produces. The README does not state the default port or the credential output format, so treat the install documentation and the installer's own terminal output as the source for both. Once inside, the practical first task is the one the README frames as the panel's purpose: deploy a small site or register an existing service so the panel can manage it.

The offline mode is the feature worth understanding before you build a workflow around the panel. The README states that after deployment you can stop the panel process entirely and existing services are unaffected. That is a different operating model from panels that insert themselves into every request path. It means the panel is a provisioning and management tool, not a runtime dependency, and you can shut it down between maintenance windows.

Where AcePanel's design gets in the way

The README's own framing creates the first limitation. Low destructiveness means the panel deliberately does less to the system than a panel that takes full ownership of nginx, PHP and the database. The consequence is that when something breaks, the panel may not be the component that knows why. If you adopt AcePanel expecting it to be the single source of truth for every service on the box, the design goal works against you.

The second limitation is documentation depth. The README is a marketing page: eight advantages, an install command, a migration link, and sponsor logos. It does not document rollback, uninstall, backup of the panel's own SQLite state, port configuration, or how to recover access if the panel process fails to start. The repository does contain config.example.yml, which is where configuration keys would be read from, but the README does not explain it. Anyone evaluating this for a fleet should read that file and the install documentation directly rather than relying on the README.

The third is platform scope. Support is limited to amd64 and arm64 on the systems listed in the install documentation, and the README explicitly says clean systems. A host with a hand-built nginx, a custom PHP compile, or years of accumulated configuration is not the environment this was designed for. The migration note from 耗子面板 2.x suggests the maintainers have thought about upgrades within their own lineage, but nothing in the README addresses importing an arbitrary existing server into AcePanel's management.

Finally, the README's claim that the panel has run stably in the maintainers' production environments is a statement about their environments. It is not a description of yours, and it is not something a reader can verify from the repository.

AcePanel against a conventional LAMP control panel

The obvious alternative is a traditional hosting control panel of the kind that installs its own web server, its own PHP builds, and its own database, then manages everything through that stack. The difference in approach is ownership. A traditional panel replaces or shadows the distribution's packages so that it can guarantee a consistent environment across every host it touches. AcePanel's README takes the opposite position: minimise modifications, and let the panel be stoppable without affecting running services.

That trade-off is real in both directions. The conventional panel gives you a predictable stack and a support community that has seen your exact configuration. AcePanel gives you a host that still looks like a normal Linux server, at the cost of the panel having less control over what it manages and, based on the README alone, less documentation about edge cases.

A second alternative is skipping the panel entirely and using configuration management or plain systemd units. That is more work per service and no web interface, but it has no install script, no panel process to secure, and no SQLite file to back up. If your server count is small and your services rarely change, a panel mainly adds an attack surface. AcePanel's offline mode softens that argument but does not remove it, since the panel still has to be installed and still has a web login.

The honest comparison point is not features. It is how much you want the panel to own. AcePanel is built for people who want the panel to own as little as possible.

Maintenance, licence, and what upgrades cost you

AcePanel is BSD-3-Clause. That is a permissive licence: you can modify and redistribute it, including in modified form, provided the copyright notice and licence text are retained and you do not use the project's name to endorse derivative work. The README states the panel itself will not introduce paid or licensed features and will stay free, and describes it as fully open source with freedom to modify and build on it under the licence terms. That statement is a project promise, not a licence term, and the two are different things. This is not legal advice; read LICENSE and, if you plan to redistribute, get your own review.

Upgrade cost is where the release history is informative. Three releases shipped in August 2026: v3.3.2 on 2026-08-15, v3.3.3 on 2026-08-19, and v3.3.4 on 2026-08-28. That cadence means a self-hosted deployment will drift from upstream quickly unless you upgrade deliberately. The repository includes .goreleaser.yaml and renovate.json, so releases are produced by GoReleaser and dependencies are updated by Renovate, which is consistent with the observed frequency.

The upgrade mechanism itself is not described in the README. There is no documented upgrade command, no documented rollback, and no statement about whether the SQLite schema migrates automatically. go-gormigrate is in the dependency list, which implies migrations run as part of startup, but the README does not say so. Before upgrading a production host, back up the storage/ directory and config.example.yml's counterpart on your system, and check the release notes for the version you are moving to.

Editorial conclusion

AcePanel fits operators who want a self-hosted control panel on a clean amd64 or arm64 host and who care about how much the panel touches the underlying system. It is a poor fit if you need a documented migration path back to a bare server, or if you run a distribution outside the list in the install documentation, because the install page is the only place that list lives. Before committing, read the install documentation for your distribution, confirm the helper script URL, and decide in advance whether you want the panel process running permanently or only during provisioning.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes