# DockPanel states its RAM footprint twice with two different numbers

> An AGPL-3.0 self-hosted Linux server panel written in Rust, where the details worth reading are the root-shell install script, the RHEL gaps in its own support matrix, and a compose file in the same repository that builds a Node website rather than the panel.

**ovexro/dockpanel** — Modern server management panel built with Rust and React. Sites, databases, Docker apps, Git deploy, mail, DNS, monitoring, backups, and security — all in one panel.

- Repository: https://github.com/ovexro/dockpanel
- Website: https://dockpanel.dev
- Stars: 971 · Forks: 149
- Language: Rust
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/ovexro-dockpanel

## The memory claim is stated twice with two different numbers

The header says panel services run on about 49MB of RAM. Four paragraphs later, in the section arguing why to choose this panel, the same claim is made as under 20MB of RAM. The comparison table goes back to about 49MB, against roughly 200MB or more for HestiaCP and roughly 150MB or more for CloudPanel, with RunCloud listed as SaaS and therefore not comparable at all.

Both numbers cannot describe the same measurement, and the document does not say which one the panel's own services add up to. What else is stated is precise: 840 HTTP routes, 147 one-click Docker app templates across 14 categories, 4544 regression assertions, and binaries of about 57MB.

The compose file in the repository does not settle it either, because those limits are not for the panel. The database service is capped at 512MB of memory and 1.0 CPU, the server at 512MB and 1.0, and the client at 128MB and 0.5. Those three services are the project's website, not the Rust panel, so the numbers describe a different deployable entirely.

For a buyer comparing panels on footprint, the safe reading is that the smaller figure is unverified by anything visible here, and the larger one is repeated in two places.

## The documented install pipes a remote script into a root shell

Installation is one line:

```bash
curl -sL https://dockpanel.dev/install.sh | sudo bash
```

The script comes from the project's own website over HTTPS, and it runs as root with no checksum, signature or version pin given in the visible text. Once it finishes, the panel answers on `https://YOUR_SERVER_IP:8443`, and the first thing it asks for is an admin account.

The certificate story is handled explicitly, which is the right thing to do. Without a domain the panel serves a self-signed certificate and the browser warns once, and the stated reason is that the certificate is there so the admin password you create is encrypted on the way to the server. Point a domain at the machine and pass `PANEL_DOMAIN=your.domain` and you get a trusted Let's Encrypt certificate instead.

That port, 8443, is worth noting separately. It is not 443, so a reverse proxy in front of the panel is the likely production shape, and the README text available here does not walk through that arrangement.

The project also keeps COMPARISON.md, FEATURES.md, SECURITY.md, CHANGELOG.md and CONTRIBUTING.md at the root, alongside the LICENSE file for the AGPL-3.0 release, so the published surface is broader than the README.

## The RHEL family gets most optional installers, but not mail, and UFW never

The supported matrix is Ubuntu 20 and later, Debian 11 and later, CentOS 9 and later, Rocky 9 and later, AlmaLinux 9 and later, and Fedora 39 and later, on both x86_64 and ARM64. The 9-and-later floor on the RHEL side is what excludes CentOS 8 and the Rocky 8 and Alma 8 lines.

What happens on those distributions is stated rather than left to be discovered. As of v2.40.0 the optional-service installers, named as Redis, Node.js, PowerDNS, WAF and Cloudflare Tunnel, work from the panel on the RHEL family. The mail server still refuses there. And UFW refuses on any firewalld box, which the document presents as a design decision rather than a bug.

So a Rocky or AlmaLinux installation gets you the panel, the optional services and the firewall tool its distribution does not use, and it does not get you the mail stack. Since mail is one of the four pillars of the product, Postfix, Dovecot, DKIM, Roundcube and Rspamd being unavailable on a mainstream enterprise distribution is the single most consequential line in the requirements section, and it is a sentence rather than a caveat box.

The reference for the full matrix is the getting started page linked from the install section, which is where the per-distribution detail lives.

## The client waits for a healthcheck the server never declares

The compose file defines three services on a `backend` network: `db`, `server` and `client`. Exactly one of them declares a healthcheck. The database has it, `pg_isready -U dockpanel`, every 10 seconds with a 5 second timeout and 5 retries, and the server waits for that check before starting.

The client then declares `depends_on` for the server with `condition: service_healthy`. As published here, the server service has no healthcheck block at all. A dependency expressed as service_healthy against a service that declares no health has nothing to wait on, which is exactly the kind of mismatch that turns into a client that never starts or a compose run that complains instead of coming up.

The rest of the file is careful in ways that make the omission stand out. Secrets that the server cannot run without are declared as required, with `DB_PASSWORD` and `JWT_SECRET` written as fail-fast substitutions that abort if unset. The Stripe variables are the opposite, defaulting to empty, so the server starts with payments unconfigured. Both published ports bind to the loopback interface only, `127.0.0.1:3061` for the server and `127.0.0.1:3060` for the client, so neither is reachable from the network. The database drops all Linux capabilities and re-adds five by name. Every service caps its logs at three files of 10MB.

## This compose file builds the website, not the panel

The build contexts give it away. The server service builds from `./website/server` and runs with `NODE_ENV: production` on port 3061; the client builds from `./website/client` and serves on port 80 inside its container. The database is `postgres:16-alpine`. The connection string is assembled in the environment as `postgresql://dockpanel:${DB_PASSWORD}@db:5432/dockpanel`, which puts the password into a URL, and the environment also carries `STRIPE_SECRET_KEY` and `STRIPE_WEBHOOK_SECRET`.

None of that is the server panel. The panel is Rust, lives under `panel/`, is installed by the shell script from the previous section, and is not built by this file. What this compose file builds is the project's own web presence, which is where Stripe keys make sense, next to the marketing site, the documentation site and the discussion board.

The repository therefore ships two deployables with different stacks, different install paths and different security postures, and the one file named docker-compose.yml belongs to the second of them. Alongside it the tree has `dashboards/`, `deploy/`, `scripts/`, `tests/`, `docs/` and a `.claude/` directory, so the Rust panel, the site and the test suite all live under one root.

The comparison table's stack row, Rust and React against PHP for the three alternatives, describes the panel and the site together, which is the closest the document comes to explaining why one repository needs two stacks.

## The name collides with a WPF control and the README says so up front

A line under the title exists purely to disambiguate: this is not the WPF or WinForms DockPanel docking control, it is a self-hosted Linux server panel. The collision is real enough that a separate paragraph is needed for it, and the panel does have a website, a documentation site, a changelog and a discussions board.

The scale claims sit alongside. 840 HTTP routes is a large surface for a panel, and 4544 regression assertions is the test count behind it. The testing method is described more concretely than the numbers: before each release the panel is installed on a throwaway VPS with a real domain and a real Let's Encrypt certificate, and each journey is driven to the point where a user would get value from it. Mail is the example given, where a message is actually sent to another server and its DKIM signature checked on arrival, rather than the package being declared installed.

The stated purpose of that discipline is to find features whose setup half worked and whose payoff half had never once run, and the testing documentation is said to list what it found, including what is still broken. Publishing that list is the more useful signal here than the assertion count.

The last release tag is v2.242.1 on 2026-09-09, preceded by v2.242.0 and v2.241.0 the same day and the previous evening, and the last commit on the default branch carries the same date.

## The comparison table does the arguing, and the RHEL gaps are not in it

The panel is measured against HestiaCP, CloudPanel and RunCloud. Price is Free against Free, Free and 8 dollars a month or more. Stack is Rust and React against PHP, PHP, and PHP as a hosted service. Docker native is 147 templates against No, No and No. Git deploy is blue-green with zero downtime against No, No and Basic. Multi-server is unlimited against No, No and Yes. Reseller and white-label is Yes against reseller only, No and No. CLI and infrastructure as code is a full CLI with YAML export against Limited, No and No. ARM64 and homelab is Yes against Partial, No and No.

Read as a table, it is thorough and entirely one-sided, and the document says so itself before making its harder claim about throwaway-VPS testing. Two of the rows are the ones to interrogate. The RAM row compares a self-hosted process against two other self-hosted processes and a SaaS product, and the smallest figure quoted for the panel is the one that disagrees with itself. And the platform row, ARM64 and homelab Yes against Partial, No and No, says nothing about the RHEL family, where the mail server is unavailable and UFW is inapplicable.

That gap matters because HestiaCP and CloudPanel are the free self-hosted alternatives a reader would actually be choosing between, and neither limitation shows up anywhere in the table.

## Secrets leave the vault by design, through two named doors

Several subsystems state a security model rather than a feature name, and they are worth reading together.

The secrets manager uses AES-256-GCM encrypted vaults with version history, automatic injection into a site's `.env` file, a masked API so values are not returned in responses, and a CLI pull endpoint. The backup orchestrator encrypts with AES-256, verifies restores rather than assuming them, and adds Backblaze B2 and Google Cloud Storage alongside S3 and SFTP. Deploy gating is per image, with CVE scanning on the image before it is allowed through. Alongside those sit a WAF, passkey login over WebAuthn, Fail2Ban, SSH hardening, audit logs, and a browser terminal with session recording.

The two doors are the interesting part. Auto-injection to `.env` writes a decrypted secret to disk in the site directory, which is where a backup, a file manager or a compromised application can reach it. The CLI pull endpoint deliberately hands the value back out over the network to whatever holds the CLI. Both are reasonable for automation and both undo the protection of the vault, so the security boundary in practice is the host account, not the AES key.

The web terminal is worth a separate note for a different reason. Session recording of an SSH session inside a browser panel records whatever is typed, including credentials pasted into a shell.

## Conclusion

Two things decide whether DockPanel suits you, and neither is in the feature list. The first is platform coverage: the RHEL family gets most optional service installers but the mail server refuses there, and UFW is out of scope anywhere firewalld is in charge, so a Rocky or Alma box is a second-class mail host by design. The second is how you install it, which means a script fetched over HTTPS and run as root with no checksum or signature given. Read that script before you pipe it. Note also that the compose file in this repository is for the project website, not for the panel, so it tells you nothing about how the panel itself is deployed, and that the advertised memory figure is quoted as both about 49MB and under 20MB in the same document.

## FAQ

### What is DockPanel and what is it built with?

It is an AGPL-3.0 self-hosted Linux server panel written in Rust with a React front end, covering sites, databases, Docker apps, Git deploy, mail, DNS, monitoring, backups and security. It is not the WPF or WinForms DockPanel docking control of the same name, and the README says so explicitly.

### How do you install DockPanel on a server?

The documented command pipes the install script into a root shell: curl -sL https://dockpanel.dev/install.sh | sudo bash. The panel then answers on port 8443, serving a self-signed certificate unless you pass PANEL_DOMAIN with a domain pointed at the machine, which gets a trusted Let's Encrypt certificate instead.

### Does DockPanel support Rocky Linux, AlmaLinux and CentOS?

CentOS 9 and later, Rocky 9 and later and AlmaLinux 9 and later are on the supported list, on x86_64 and ARM64. Since v2.40.0 the optional-service installers for Redis, Node.js, PowerDNS, WAF and Cloudflare Tunnel work there, but the mail server still refuses, and UFW refuses on any firewalld box by design.

### How much memory does the DockPanel panel use?

The README gives two different figures. The header and the comparison table both say about 49MB of RAM for panel services, while the section arguing why to choose the panel says under 20MB. The comparison puts HestiaCP at roughly 200MB or more and CloudPanel at roughly 150MB or more.

### What does the docker-compose.yml in the DockPanel repository deploy?

The project website, not the panel. It builds a Node server from ./website/server and a client from ./website/client against postgres:16-alpine, publishes both on 127.0.0.1 only, requires DB_PASSWORD and JWT_SECRET, and reads optional Stripe keys. The Rust panel lives under panel/ and is installed by the shell script instead.

### How does DockPanel test its features before a release?

The panel is installed on a throwaway VPS with a real domain and a real Let's Encrypt certificate, and each journey is driven to the point where a user would get value, with mail tested by sending a message to another server and checking its DKIM signature on arrival. The documentation is said to list what this found, including what is still broken.

## Sources

- [License: AGPL-3.0](https://github.com/ovexro/dockpanel/blob/main/LICENSE)
- [ovexro/dockpanel on GitHub](https://github.com/ovexro/dockpanel)
- [Project website](https://dockpanel.dev)
- [README](https://github.com/ovexro/dockpanel/blob/main/README.md)
- [Releases](https://github.com/ovexro/dockpanel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ovexro-dockpanel