A security checklist for a self hosted hosting panel.

A control panel is the one program that can change everything on a server, so it is the first thing an attacker looks for. These twelve checks work for any panel. After each, we say how RespireCloud answers it today, including where the answer is not complete.

1. Does the web part run as root?

If the program that faces the internet can run commands as root, one bug in it is a takeover of the server. Look for a split: a web tier with no privileges, and a small helper that does the root work.

RespireCloud: the panel runs as an unprivileged user. Root work goes to a separate agent that accepts typed, allow listed operations. It runs programs as argument lists, so there is no shell string for input to escape from.

2. How do administrators sign in?

A password alone is not enough for a panel. Look for passkeys or an authenticator app, recovery codes, and a way to end every session.

RespireCloud: passkeys, Argon2id passwords, authenticator and recovery codes. A second step is required for administrators and resellers. High risk actions ask for a fresh passkey or code. A device list ends any session at once, and a browser kept signed in with a PIN needs two halves that are useless apart.

3. Is everything denied unless allowed?

A panel that checks only some HTTP methods or paths can be walked around. The safe rule is deny by default.

RespireCloud: every method and path is denied unless an action allows it, and the host re-checks each call's permission, scope and schema as the caller.

4. Do updates arrive, and can you trust them?

An unpatched panel is the usual way in. Updates should be automatic, signed, and reversible.

RespireCloud: the panel updates itself from signed releases. The signing key is built into the program, the root agent checks a release again before it runs, an older release is not accepted as an update, and a release that does not start is replaced by the previous one together with a copy of the database. Not done yet: the signed release manifest has no expiry date, so an attacker who can block updates could keep you on an old release unnoticed. This is on the list of findings.

5. Are customers isolated from each other?

One hacked site should not reach the next. Look for a Linux user, a resource slice and a PHP pool per account.

RespireCloud: every hosting account is its own Linux user with its own systemd slice, PHP-FPM pool and quotas, in every edition. open_basedir confines PHP to the home and symlinks to other owners' files are refused.

6. Are backups encrypted, off the server, and restored?

A backup you have never restored is a hope. Look for encryption, a copy on another system, immutability, and a test restore.

RespireCloud: encrypted incremental backups, one repository per account and target, to any storage including S3 compatible stores with object lock. A whole server was rebuilt from its backup in a lab run in 312 seconds with every item verified. Not covered: mail in transit, sessions and the licence activation do not come back.

7. Is there a log nobody can quietly rewrite?

After an incident you need to know what happened. Look for a tamper evident log that is also copied somewhere else.

RespireCloud: a hash chained audit log with verification, signed checkpoints kept by the root agent, and an off server copy of every checkpoint by syslog or a signed webhook.

8. Can a firewall change lock you out?

Firewall edits are the classic way to cut your own access. Look for a rollback timer.

RespireCloud: every firewall change arms a rollback timer, and if you do not confirm, the previous rules return. CrowdSec runs locally by default.

9. Where do secrets live?

Passwords and keys in logs and config files are found by attackers and by backup tools.

RespireCloud: secrets live in an encrypted vault and are redacted from logs and the audit trail. The vault key is kept out of the repository backup, in a recovery bundle you hold.

10. Can the server be used to send spam?

A hacked account that can send mail ruins your IP reputation in a day.

RespireCloud: outbound SMTP is blocked for hosting accounts at the firewall, a login must match the sender, open relay is refused, and a flooding mailbox is held rather than bounced.

11. What can the panel reach on your network?

Features that fetch a URL for you (a proxy site, a webhook, an import) can be turned against internal services.

RespireCloud: one egress guard checks every outbound request of the panel. Honest limit: a code audit on 19 October 2026 found cases where proxy sites can still reach loopback and private services by unusual address spellings. Those are being fixed, and the security page says when they are.

12. Is there a way to report a problem?

Look for a security.txt file and a named contact.

RespireCloud: /.well-known/security.txt names the contact and the policy. Report to info@respiresoft.com with the subject "RespireCloud security report".

Questions

Is a self hosted panel less safe than a hosted one?
It is different: you hold the patches and the backups. A panel that updates itself, isolates accounts and keeps a verifiable log takes much of that work off you.
Does RespireCloud pass this checklist?
It has a built answer to each, and it states the limit where one exists. The security page lists what is built and what is not.
Has RespireCloud had a penetration test?
Not an external one. Code audits were made in October 2026, and the security page lists their findings and the state of the fixes.

Read next

Questions about your own setup?

Tell us what you run and where you are moving from. We will answer plainly.