Fast sites. Isolated accounts. Your servers.
A complete hosting platform — web, mail, DNS, databases and backups — with every account isolated from every other, a web stack built for speed rather than inherited from 2009, and mail that configures itself.
The closed beta is running, by invitation. It is being built in the open and is not finished; there is no public signup and no checkout yet, and prices are published. What follows is what already runs.
accounts · stacks · zones · certificates · mailboxes · backups
See what it does How it will be licensed
Isolation that is actually isolation
Other panels give each customer a login on a shared server and call it separation. Here every account runs on its own, with its own PHP and its own limits: no shared document root, no shared cache, and no path from one tenant’s code to another’s files, database or mail.
Ceilings are real, not advisory. CPU, memory, processes, disk and bandwidth per plan, enforced from outside the account where nothing inside it can opt out.
And the parts of the platform every tenant touches — the web server, each account’s PHP, each account’s mail delivery — are locked down too, so a compromised site has nowhere to go.
One tenant’s runaway process is not another tenant’s outage. That is the foundation the rest of the product is built on, and it is why the rest of it can be simple.
Built for speed, measured rather than claimed
HTTP/3, Brotli beside gzip, and a full-page cache that can clear a single page when it changes — which is what makes a page cache safe to leave switched on.
Per-account object caching on the plans that include it, and tuned PHP with JIT on PHP 8 and optional preloading. When something is slow, the panel names the script rather than shrugging: real-user timings per site, slow-request logs, and the database’s slow queries split out per account.
PHP from 5.6 to 8.4 — eleven versions, chosen per account — beside Node.js, Python, Ruby, .NET and Java. You build only the stacks you want: at the first run, or later with one button. The old versions are there for the sites that arrive on them, and the panel labels them as out of support rather than pretending otherwise.
WordPress, looked after — on every tier
Most compromised sites are a plugin with a published vulnerability that nobody updated in time. So the panel checks every WordPress it hosts against a vulnerability feed that refreshes several times a day, and names the plugin or theme, the vulnerable version and the one that fixes it.
Then it closes the window between disclosure and update. A site can opt into virtual patching, which blocks the attack on a vulnerable plugin without touching the site’s code, and into security updates for plugins even where automatic updates are off, with a restore point taken first.
All of it is free, on every tier, because a site’s safety is not a business feature. Around it: one-click installs, updates with a restore point behind them, an integrity scan, sign-in to wp-admin from the panel, and hardening switches.
Mail that sets itself up
Your customer types their address and their password into Thunderbird, Apple Mail or Outlook, and it works. No server names, no port numbers, no SSL/TLS dropdown, no support ticket. The panel answers the discovery protocols every mail client already speaks — including Outlook’s, which asks a different question in a different place than everyone else’s.
That one feature removes what is, on most hosts, the single largest category of support contact. Everything underneath it is handled the same way: the records that decide whether your mail is trusted are generated, published and watched rather than left as a checklist somebody forgot.
A staging copy that costs what changes
When we cloned a 64 MB site into a staging copy, its files took 8 KB of disk. A staging site here costs disk only for what actually changes on it. Its database is a real copy, so nothing done on staging reaches the live one.
So staging stops being something you ration by disk. A customer can break it, throw it away and make another, and your disk barely notices.
Backups that are proven, not promised
Every host claims backups. Ask one when a restore was last actually tested and the answer is usually silence, because testing a restore normally means finding a spare machine.
This panel restores one every week and, where the server can run the check, asks the restored site for a page. It picks the account whose backup has gone longest unproven, restores it into a throwaway copy and asks that copy for its front page — without touching the live one. A backup missing the files that make a site work passes a checksum; where the check can run, it fails this, and a restore it cannot ask warns the admins instead.
They are also cheap to send and cheap to keep. After the first night each backup sends only what changed, and content many accounts share — the WordPress files most sites have in common — is stored once. Every night is still a whole backup in its own right, and the server that makes them can add backups but never delete them.
The key that reads them is yours: locked to a recovery key only you hold, with an offline key of ours as a safety net, so a lost key is a support call rather than a catastrophe. Losing a server should be an afternoon of rebuilding, not a phone call you dread — and that is a claim we test on your behalf rather than ask you to trust.
The exits are never locked
Backups, restore, recovery, certificates and a complete account export will be on every plan, including the free one — no exceptions, and a test in the source that refuses any licence feature named after one of them.
A lapsed subscription drops a node to the free tier. It never stops a website, a mailbox or a database: the licence check does not reach any of them. Commercial disagreements are between you and us, and your customers should never be able to tell.