Isolation you can check, layer by layer
Every Cube boots its own kernel inside a per-cube sandbox, sits on a private network with no inbound route until you open a port, and serves web traffic through a hardened managed-TLS ingress. Here's exactly how each layer works — and where each one stops.
Its own kernel. A sandbox around every Cube.
A container shares one kernel across every tenant on the host — a single kernel bug can expose all of them. Krova Cloud is the opposite by design.
Its own kernel, per Cube
Every Cube boots its own kernel — never shared with another tenant or the host. One Cube's kernel bug can't reach yours.
Per-cube jailer sandbox
Each Cube's hypervisor runs inside a jailer sandbox — its own unprivileged user, chroot, and PID namespace. A hypervisor escape lands in that sandbox, not as root on the host.
Isolated from other Cubes, not just the host
Cubes can't reach each other on the private network. The bridge drops cube-to-cube traffic in the kernel — not with a firewall rule that has to match first — and a second rule at the routing layer backs it up. Kernel-isolated and network-isolated.
KVM isolation, hardened host
KVM-enforced VM isolation (the same virtualization behind AWS Lambda), the most restrictive seccomp filters, and cross-VM memory-dedup side channels disabled.
Your app is public. Your server isn't.
Lightsail, DigitalOcean, Vultr and Linode all hand your server a public IP — a fixed address the whole internet can scan and hammer, from the second it boots. Krova Cloud gives your app a front door and leaves the machine behind it unlisted.
Outbound: everything. Inbound: your call.
Outbound: everything. Your Cube installs packages, pulls images and calls APIs exactly like any other server. Inbound: your call — it lives on a private, NAT'd network, so there is simply no address out there for botnets to find and probe until you publish one.
Managed TLS, hidden origin
Web traffic on your custom domains enters through Krova Cloud's health-managed ingress tier: certificates are issued and renewed automatically, the origin stays hidden, and unhealthy nodes drop out of DNS on their own. Prefer Cloudflare in front? Orange-cloud your domain and it works instantly.
Only what you open
Nothing inbound is reachable unless you explicitly open a port, and every mapping can be locked to an IP allowlist behind a stateful default-deny firewall. Hosts add provider-grade network DDoS mitigation on top.
A fresh, isolated Cube per API call
Forget the AWS dance — VPC, subnet, security group, AMI, key pair, IAM role, launch template. One call creates a Cube with its own kernel and its own sandbox, and it starts in seconds. Loop it to give every user, agent or build its own: your tier sets how many run at once, and the top tier sets no fixed cap.
What happens when something goes wrong
Every isolation story is easy to tell on the happy path. These are the answers to the questions that actually decide whether you put a production workload here.
If a Cube is compromised
Defence in depth means assuming a layer fails. If a guest kernel is compromised, the attacker is inside their own kernel — not one shared with you — and still bounded by the KVM boundary. If the hypervisor itself were escaped, the jailer sandbox is what they land in: an unprivileged user, in a chroot, in its own PID namespace, behind the most restrictive seccomp filter set. Not root on the host. Cross-VM memory deduplication is disabled, so there is no shared-page side channel between tenants to begin with.
How kernel updates reach you
Your Cube's kernel is supplied by the host, not by the guest — which is why rebooting from inside a Cube cannot change it, and why a compromised guest cannot pin itself to an old kernel. A cold restart from the dashboard or API boots the Cube on the refreshed kernel with its disk exactly as you left it. Above the kernel, security updates for the packages you install arrive daily on their own, without a reboot and without interrupting SSH — and you still have full root to manage everything else yourself.
Your data, and getting it back
Snapshots are content-addressed and deduplicated (Restic), encrypted with a key unique to each Cube, and stored separately from the host it runs on. Deleting a Cube offers to keep a full backup first — checked by default on plans that include backups — so an accidental destroy is recoverable. You can export any Cube as a .cube archive and import it again — your data is portable out of Krova, not just inside it. RAM and disk are reserved 1:1 against real hardware, so a noisy neighbour cannot take capacity you have paid for.
Reporting a vulnerability
If you have found a security issue, please tell us before you tell anyone else. Email [email protected] with enough detail to reproduce it. We will acknowledge your report, keep you updated while we fix it, and credit you if you would like to be credited.
We will not pursue legal action against researchers who act in good faith: test only against your own account and your own Cubes, do not access, modify or destroy anyone else's data, do not degrade the service for other customers, and give us a reasonable window to fix the issue before publishing. Our machine-readable contact is published at /.well-known/security.txt.
Everything you can read before you sign
The agreements, the service commitment and the subprocessor list are all published — read them before you create an account, not after.
Available today
- Data Processing Agreement
- Published SLA
- Named subprocessor list
- Data portability — export any Cube as an archive
Your data stays yours
- Export any Cube as a portable archive
- Snapshots encrypted with a key unique to each Cube
- Stored separately from the host your Cube runs on
- Deleting a Cube offers to keep a backup first
Frequently asked questions
Is a Cube more isolated than a container?
It is a different boundary, not a stronger version of the same one. A container shares the host's single Linux kernel with every other tenant on the machine, so one kernel-level bug can expose all of them. A Cube is a Firecracker microVM that boots its own kernel behind a KVM hardware-virtualization boundary, and its hypervisor process runs inside a per-cube jailer sandbox — an unprivileged user, a chroot, and its own PID namespace. An escape lands in that sandbox, not on the host as root.
Can another Cube on the same host reach mine?
No. Cube-to-cube traffic is dropped by the kernel at the bridge itself — port isolation on every cube's tap, so the frames never reach a firewall rule that has to match first — and a second rule at the routing layer backs it up. The host does not answer ARP on a cube's behalf either, so it cannot route between them.
How do I reach my Cube if it has no public IP?
Through your domain and the ports you choose. Web traffic on your custom domains enters over HTTPS through Krova Cloud's managed ingress, which issues and renews certificates for you and keeps the origin hidden. SSH, databases and any other TCP service open through a port mapping you create — and every mapping can be locked to an IP allowlist behind a stateful default-deny firewall.
What agreements and controls can I review before signing?
A Data Processing Agreement, a published SLA and a named subprocessor list are all available to read before you create an account. Your data stays portable: any Cube exports as a .cube archive you can take with you, and snapshots are deduplicated, encrypted with a key unique to each Cube, and stored separately from the host the Cube runs on.
Can I get my data back out?
Yes. Any Cube exports as a portable .cube archive that you can import again, so your data is portable out of Krova Cloud rather than only inside it. Snapshots are deduplicated, encrypted with a key unique to each Cube, and stored separately from the host it runs on. Deleting a Cube offers to keep a full backup first — checked by default on plans that include backups.
Publish your app, not your server.
Launch an isolated Cube with full root access in under a minute — its own kernel, its own sandbox, and you decide what it exposes.
Cubes from $2.92/moNo credit card to sign up