RespireCloud
Request a demo

Security and data safety

Control panels are a favourite target because one bug can hand over every site on a server. RespireCloud is built so that the part facing the internet has as little power as possible, and everything it does is on the record. Your data stays on your own servers. Below is what is built, what was audited, what we have not done, and how to reach us.

Eight things we want you to be able to check.

  1. Browser, CLI or API token

    Signs in with a passkey or a scoped token. Every method and path is denied unless an action allows it.

  2. respirecloudd unprivileged user

    Checks permission, plan limits and risk; validates parameters against the action's schema; writes the audit row.

  3. Bus TLS 1.3, per-server keys

    Each server can only receive its own operations. A compromised server cannot see another's.

  4. respirecloud-agent root, minimal

    Runs typed operations from module manifests only. Commands are argument lists, never shell strings.

Lessons we built in

Authentication that only checked some requests
In 2024 an open-source panel was taken over on thousands of servers because its authentication checked only some HTTP methods. RespireCloud denies every method and path unless an action allows it.
User input reaching a shell
The agent runs programs as argument lists from typed operations. There is no shell string for a parameter to escape from.
A stolen session doing damage
High-risk and critical actions need a fresh passkey or code, and you can end any signed-in device from your Security page. A browser kept signed in with a PIN needs two halves that are useless apart, so a stolen cookie gets nothing.
A bad firewall rule locking you out
Every firewall change arms a rollback timer. If you do not confirm it, the previous rules come back.

Layer by layer

The panel

  • Unprivileged web tier; root work only through typed agent operations
  • Deny by default on every method and path
  • Passkeys, Argon2id passwords, authenticator and recovery codes
  • Two-step sign-in required for administrators and resellers
  • Single sign-on with OIDC and SAML; administrators keep a local way in
  • Step-up for high-risk actions, session rotation
  • Device list with instant sign-out; scoped, revocable API tokens
  • A PIN on a trusted browser: a stolen cookie alone gets nothing, because the browser must also sign with a key that cannot leave it. A PIN never replaces a passkey or code for risky actions
  • A deny on one site, domain, mailbox, database or folder wins everywhere, for administrators too
  • Hash-chained audit log with verification
  • Sign-in alerts for a new country or impossible travel, with a "this was not me" answer
  • Every audit checkpoint can be copied off the server by syslog or signed webhook, so a rewritten log is caught against the copy
  • SAML encrypted assertions, signed requests and single logout (not built, or limited)
  • SELinux enforcing for the per-site firewall is not proven (not built, or limited)

Servers

  • Per-server keys on a TLS 1.3 bus; each server sees only its own operations
  • nftables firewall with presets and an anti-lockout rollback timer
  • CrowdSec intrusion prevention, local by default
  • File-integrity baselines and hardening checks
  • Unattended security upgrades with a service health watch
  • SSH hardening validated with sshd -t
  • Signed updates: the key is built into the program, the root agent checks a release again before it runs, and a release that does not start is replaced by the previous one and a copy of the database
  • Licence-bound downloads: releases and Store add-ons are served only to an installation with its own key and a licence in good standing
  • Rootkit scans (not built, or limited)
  • Real-time file scanning (not built, or limited)

Sites

  • Per-account Linux users, slices and PHP-FPM pools
  • open_basedir to the home; no symlinks to other owners' files
  • Snippet allow-lists checked on the panel and again on the server
  • Malware scanning (ClamAV and YARA) with quarantine
  • A web application firewall per site (Coraza and the OWASP rules): off, detect or block, with exceptions and a kill switch. It adds about 12 ms at the 95th percentile
  • Per-site rate-limit presets, security headers, a proof-of-work bot challenge and hotlink protection
  • Proven on AlmaLinux 10 and Ubuntu 26.04; a restart of the firewall service leaves sites uninspected for about 11 seconds (not built, or limited)

Mail

  • DKIM keys made on the server, ARC sealing
  • SPF, DMARC, MTA-STS and TLS-RPT published automatically
  • Login must match the sender; open relay refused
  • Outbound SMTP blocked for hosting accounts at the firewall
  • A flooding mailbox is held, never bounced; blocklist and reverse-name checks run with a score per domain
  • ClamAV for mail, chosen in the installer; it needs 4 GB and was run on two of the nine systems
  • App passwords for phones, refused by the webmail sign-in; a failed sign-in is logged with the real client address so it can be banned
  • DANE (not built, or limited)
  • The stock fail2ban Dovecot filter does not match Dovecot 2.4; a custom filter was used in the lab (not built, or limited)

DNS and certificates

  • One-click DNSSEC
  • Certificate keys generated on the node
  • ARI-scheduled renewals that never drop a working certificate
  • Secondary name servers: a zone transfer needs the transfer key and a listed address, and a secondary can be promoted
  • CT log monitoring (not built, or limited)
  • No screen yet for promoting a secondary or holding a zone for an outside primary; the actions exist (not built, or limited)

Data

  • Encrypted restic repositories, one per account and target
  • Immutable backups with S3 object lock
  • Secrets in a vault, redacted from logs and the audit trail
  • Whole-server recovery, run for real: a blank node was rebuilt from the backup and bundle in 312 seconds with every item verified
  • Point-in-time database recovery (not built, or limited)
  • Mail in transit, sessions and the licence activation do not come back (not built, or limited)

Built and lab-tested Not built, or built with a stated limit

Updates and downloads you can verify

Built

  • Releases and Store add-ons are signed. The key is built into the program, and the root agent checks a release again before it runs.
  • An older release is not accepted as an update: updates are not downgrades.
  • A release that does not start is replaced by the previous one and a copy of the database, by itself.
  • Downloads the agent makes (for example k3s and container engine binaries) are pinned by SHA-256.
  • The installer verifies the release manifest's signature, size and checksum before it installs anything.
  • Releases and Store add-ons are served only to an installation with its own key and a licence in good standing.

Not yet

  • The signed release manifest has no expiry date yet, so someone who can block updates could keep an installation on an old release unnoticed (finding 011 of the October audit).
  • Package repository keys added by the installer are not yet pinned by fingerprint (finding 010).

What has been audited, and what has not

Done

  • 4 white box code reviews in October 2026 found 15 problems. All are fixed, each with a test. Among them: a customer could create DNS zones for other tenants' names, a database dump ran as root, and one customer could take another's PostgreSQL database.
  • A security and code audit on 19 October 2026, made apart from the people who built the code: dependencies, who may call which action, the border between the panel and the root agent, secrets, the web layer, the supply chain and data integrity. It found 15 problems: 3 high, 5 medium, 5 low and 2 for information.
  • The findings of that audit are being fixed. This page will say "findings fixed" only when every one has been merged and re-checked. There is no public release yet; the rule is that none is made while a high finding is open.

Not done

  • An external penetration test has not started.
  • Backups, migrations, mail and proxy template injection, sign in rate limits and the PIN flows were covered by the October reviews, not by the 19 October audit, and need their own pass.
  • No bug bounty. Reports are welcome and answered, below.

AI and your data

What you control

  • Four kinds of data, each switched separately for each outside provider: logs, configuration, file excerpts and mail. All are off until an administrator saves them.
  • The assistant reads only what you could read yourself, and nothing it proposes runs until a person approves the plan.
  • Secrets are stripped from what is sent, on a best effort basis, and every request to a provider is logged with the provider, the model, the kind of data and its size.
  • Your own model key is always allowed and never charged by RespireSoft. A model on your own server keeps everything on the server. Air gapped mode refuses every outside provider.

RespireSoft AI

  • Calls to RespireSoft AI ask for zero retention: the route picks only models whose provider keeps nothing, and a call is refused if that could not be set.
  • Every answer is checked against pinned keys. One that does not verify is an error, with no data used and nothing billed.
  • Secret removal is pattern based, so a new shape of secret can pass. The approval step, not the filter, is the guarantee.

Data safety

See also the recovery proof, the performance numbers and the security checklist for any panel.

The Confirm it is you dialog asking for a passkey before deleting a hosting account.

Found a vulnerability?

Email info@respiresoft.com with the subject "RespireCloud security report". Please do not test against servers you do not own. Our contact and policy are in security.txt, and the technical detail is in the security model.

Report a vulnerability