Least power for the part facing the internet

The web panel runs as an unprivileged user. It cannot run commands. Anything that needs root goes to a separate agent that accepts typed, allow listed operations, validates their parameters and runs programs as argument lists. There is no shell string to escape from, and an operation the agent does not know is refused.

Sessions and approvals

Sign in with passkeys, a password with a second factor or both. Actions with high or critical risk need a fresh passkey or code at the moment you run them, so a stolen session alone cannot do the damage. A browser kept signed in with a PIN is proven by a key that cannot leave it, together with a cookie that changes at every visit, so a stolen cookie gets nothing. You can end any signed in device from your Security page.

Every firewall change arms a rollback timer. If you do not confirm it, the previous rules come back, so a bad rule cannot lock you out.

A log that shows tampering

Changes are written to an audit log in which each entry includes a hash of the one before. Signed checkpoints can be copied off the server. Verifying the chain is an action of its own, and a break is reported as an incident.

Updates you can trust

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. A release that does not start is replaced by the previous one together with a copy of the database. The installer verifies the release manifest's signature, size and checksum before it installs anything.

What was audited

Four white box reviews on 10 and 11 October produced 15 findings. A security and code audit on 19 October found 15 more, three of them high. A second audit on 20 October, of everything built after the first, found 13, three of them high. None was critical. All are fixed, and the testing post has the counts by severity.

What is still open

• The signed release manifest has no expiry date yet, so someone who can block updates could keep an installation on an older release unnoticed.
• Package repository keys that the installer adds are not yet pinned by fingerprint.
• An independent external penetration test has not started.

We would rather you read this list here than learn it later. To tell us about a problem, email info@respiresoft.com with the subject RespireCloud security report.

Your data stays yours

RespireCloud is software you install. This website sets no cookies of its own besides an optional partner code, and runs no analytics. Backups are standard restic repositories that go where you choose, and a lab run rebuilt a whole server on a blank node in 312 seconds from backup, with a list of what does not come back.

What the checklist counts

RespireCloud is built from modules, and every module declares its actions in a manifest. A script reads the manifests, the panel routes, the command line and the test files, and writes one row per action. For each row it records two things. A unit test exists or not. And the newest live result: a real call on a real server, recorded as PASS or FAIL with the date, the server and the release.

Nobody edits the file by hand. If it says something, a test file or a result file says it first.

The numbers

As of this post the checklist has 1393 actions, of which 906 change something.

The 856 passing results were recorded on real test servers, not on mock objects. Dry run and chained runs are marked as such in the results, so a plan is never counted as a full run.

What the live runs found

Running real calls finds bugs that unit tests miss. In the last weeks, live runs found and fixed problems in the cloud server drivers, among them a request limit that was too small for the start up data a server needs. The bug list has 11 open entries, one of medium severity. We fix them in order, and the list is not hidden.

Audits

We ran two security and code audits in October. The first, on 19 October, found 15 findings: 3 high, 5 medium, 5 low and 2 informational. The second, on 20 October, covered everything built after the first and found 13: 3 high, 4 medium, 4 low and 2 informational. None was critical, and every finding is fixed. Four white box reviews on 10 and 11 October had earlier produced 15 findings, also fixed, each with a test.

The security page has the current state and the two findings we have not closed.

What we have not done

• 303 untested mutating actions. They are listed. Many are rare or administrative, but they are gaps.
• An external penetration test. It has not started. For a hosting panel we think an independent test is necessary, and we will say when it happens.
• Customer backups. The importers have run on archives we built, not on production backups from customers.

Why publish this

A table with gaps in it is more useful than a claim without one. If you are deciding whether to trust a panel with your servers, you can read what has been run and what has not. Read more about the design in the security model, or see the performance numbers from our load test.

Start with a second server

Do not install RespireCloud on the cPanel server. The installer looks for another panel and for web, database, mail or DNS servers that someone set up by hand, and it stops when it finds them. A new server of a supported system costs a few days of rent, and it is what lets you test first while the old one carries on.

Lower the time to live ahead of time

The time to live (TTL) of a DNS record is how long other networks keep an answer. If it is a day, a change takes up to a day to reach everyone. A few days before the move, lower the TTL on the records you will change to a few minutes, then wait at least as long as the old value. On the day, the switch spreads in minutes, and a bad switch can be undone just as fast.

Back up one account and import it

Use cPanel's own backup script to create an archive of the smallest account you have. RespireCloud's importer reads it and does three things before changing anything. It checks the archive. It reports what converts and what does not. Then it builds the account in a dry run, so you see the plan.

Only when you say so does it commit. If something is wrong, the rollback removes everything the import created. Read more on the migrations feature page.

Test on the new server before DNS points at it

Check the site on the new server by editing your own hosts file, send a test mail, open the databases and look at the cron lines the report listed. Mailbox owners will need a new password. Add a backup target and restore one file from it before you rely on it.

Switch, then watch

Change the records. While the short TTL runs out, some visitors reach the old server and some the new one, so keep both online. Mail that lands on the old server in that window can be fetched from it afterwards. When traffic on the old server is gone, keep it a little longer, then retire it.

An honest note

RespireCloud is in early access. The importers for cPanel and Plesk have run end to end on archives we built to match each format, not on a customer's production backup. Treat the first move as a rehearsal: a small account, a copy, and the old server untouched.

One bug should not hand over every site

A hosting panel sits in front of a lot of power: it writes web server configuration, creates system users and reads mail. If the code that answers web requests can also run commands as root, any bug in it can become a takeover of every site on the machine. This has happened to real panels, and it is the first lesson on our security page.

So RespireCloud splits the work. The web panel is an unprivileged process. A separate root agent accepts a short list of typed operations and refuses everything else. A request has to name an operation the agent knows, with parameters that pass its schema. There is no place for a shell string to be assembled from user input.

A change should be something you can read first

Most panels apply a change the moment you press a button. You find out afterwards what it did. In RespireCloud every action can be shown as a plan first: the files it will write, the services it will reload and the risk it carries. You see the difference before it happens.

This is also what makes the assistant safe to use. It does not run commands. It proposes the same plans, and you approve them. High risk actions ask for a fresh passkey or code before they run, and every change is written to an audit log that is chained so tampering shows.

Open tools underneath

We did not want a panel that you cannot leave. A site is a directory served by nginx. A database is a normal MariaDB or PostgreSQL database. A mailbox is a Maildir. Backups are standard restic repositories. If you stop using RespireCloud, your data is where an experienced administrator would expect it. The storage and backups page describes the formats.

A price you can predict

Panels that charge by the number of accounts make growth feel like a penalty, and price rises each year make planning harder. RespireCloud has a free plan for one server, and the paid tiers are one flat price per server. There is no fee per account and no yearly rise. The pricing page lists the tiers and the add-ons, and what is free on purpose.

From one server to a fleet

The same panel manages a single VPS or many servers. The cluster feature adds roles, load balancers with health checks and moving an account with its mail between servers, and the cloud servers feature creates servers at several providers from the panel. You do not move to a second tool when you grow.

What we are still working on

RespireCloud is in early access, and some things are not yet proven in the field. The changelog shows what changes every week, and the status notes on each feature say what is built and what is planned.

We are announcing it now, in early access, because we would rather be read critically while there is still time to change things. This post says what RespireCloud is, what is built, and what we have not proven yet.

What it is

You install RespireCloud on a Linux server of your own. It then sets up and looks after the usual hosting stack: nginx and PHP-FPM for sites, Postfix, Dovecot and Rspamd for mail, PowerDNS for DNS, MariaDB, PostgreSQL and Valkey for data, and restic for backups. Every part uses ordinary open tools underneath, so a site is still a folder, a database is still a database and a mailbox is still a Maildir.

The feature list has one page per area, each with its status. Nothing is shown as ready that is not.

Changes you can see before they happen

The idea that shapes the whole product is that every change is a typed action. The panel can show the same action as a plan first: which files change, which services restart and what could go wrong. You approve the plan, and only then does it run. The same actions are available from the command line and the API, and an assistant can propose them in plain words.

That is why the assistant fits. It turns a request into a plan you approve, and it cannot do anything the panel would not let you do yourself. AI comes with a licence as a monthly allowance, or you can bring your own model key, or use a model on your own server.

Built so the web part has little power

Control panels are attractive targets because one bug can reach every site on the server. In RespireCloud the web panel runs as an unprivileged user. Work that needs root goes to a separate agent that accepts only declared, typed operations and runs programs as argument lists, never as shell strings. The security model explains the design, and we wrote a separate post on how we tested it.

What is not proven yet

We would like you to know the gaps before you find them:

• There is no public download and the production signing keys are not made.
• The cPanel and Plesk importers have run end to end on archives we built to match each format, not on a customer's production backup.
• An independent external penetration test has not started.

The security page and the changelog keep this list current.

What it costs

There is a free plan: one server with the whole base product. Paid tiers are one flat price per server, with no fee per account and no yearly price rise. The pricing page has the tiers and the add-ons.

What to do next

If you run hosting for yourself, an agency or customers, take the guided tour, then read how it compares with cPanel. If you want to try it on a real server, ask for early access and tell us what you run.