No — signing up is free and requires no payment information. To run Cubes you load prepaid credit; your first top-up gets $5 in bonus credit (one-time), which is enough to run a small Cube around the clock for weeks. Adding that first card also unlocks the Starter tier automatically.

No — and this is the core difference. 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. Each Cube is a Firecracker microVM that boots its own separate kernel, isolated by the CPU's hardware virtualization (KVM) — the same isolation technology behind AWS Lambda. Cubes never share a kernel with each other or with the host.

Two separate things update on their own schedules. Your Cube's userspace — the packages you install — gets automatic security updates daily, applied without rebooting or interrupting SSH. The Linux kernel is different: because a Cube is a real virtual machine, Krova Cloud supplies its kernel from the host at boot rather than from your disk. That means running reboot inside your Cube does not change the kernel — it comes back on the same one, and nothing warns you. To move a running Cube onto a refreshed kernel, restart it from the dashboard, the API, the CLI (krova cubes restart), the SDK, the MCP server or the n8n node. A restart is a cold restart: the Cube boots against the current kernel with its disk fully preserved. A Cube that is powered off already picks up the latest kernel the next time you start it.

Your Cube reaches the internet completely normally — apt and npm installs, Docker pulls, outbound API calls and webhooks all work — and your sites and APIs are reachable worldwide over HTTPS. What it deliberately does not have is an inbound address of its own, and that is a security feature rather than a missing one. Unlike a typical VPS, where every instance is handed a public IP the whole internet can scan and probe, a Cube lives on a private network: nothing reaches it from outside unless you explicitly map a port, and every port mapping can be locked to an IP allowlist. Web traffic on your custom domains enters through Krova Cloud's own managed ingress tier, which terminates HTTPS and forwards to your Cube over an internal, mutually authenticated connection — so the machine running your app is never addressed directly from the internet.

For almost everything people run on a server, no — and not having one is a security win. What makes your app reachable is your domain and the ports you choose to expose, not a fixed address bolted to the whole machine. Web apps and APIs are reachable worldwide over HTTPS through Krova Cloud's managed ingress, which issues and renews your certificates automatically, and anything else — SSH, a database, a game server, any TCP service — is reachable through a port mapping you open on demand and can lock to an IP allowlist. You get inbound access to exactly what you expose, without a public address the whole internet can scan, brute-force, and target. Fewer doors, and all of them yours.

Bandwidth is unmetered: Krova Cloud does not bill per gigabyte and does not set a monthly transfer allowance, so a traffic spike cannot produce a surprise invoice the way per-GB egress does at the hyperscalers. Provider-grade DDoS mitigation is included, and there is no bandwidth penalty if you are attacked. The honest caveat, which is in our Acceptable Use Policy rather than buried: the network is shared, so we reserve the right to rate-limit an individual Cube where sustained traffic would threaten host stability or other customers, and workloads whose whole purpose is consuming bandwidth — public file mirrors, torrent seedboxes, large-scale media relays — need prior written approval. Normal, well-behaved use of a web app, API, database or game server is simply not something we meter.

Every host sits behind provider-grade, network-level DDoS mitigation, and the design of the platform removes most of the attack surface to begin with: your Cube has no inbound address to target, traffic is default-deny until you open a port, and web traffic reaches your app only through our managed ingress tier rather than the machine itself. There is no surge pricing and no bandwidth penalty if you are attacked. If you want application-layer (L7) filtering on top — WAF rules, bot management, rate limiting — you can put your own CDN or reverse proxy in front of your domain; Krova Cloud works behind one, and that service would be on your own account and billing, not resold by us.

Rates are quoted per hour, but you're billed by the minute. Run a Cube for 5 minutes and you pay for 5 minutes, not a full hour — there's no rounding up. Power off a Cube and compute charges (vCPU + RAM) stop immediately; only the disk it occupies on the host keeps billing, at the same per-GB rate. Credit is consumed as you go, and you can watch the balance in real time.

No. Krova Cloud is prepaid pay-as-you-go — there's nothing to subscribe to. You load credit whenever you like and it's drawn down per minute as your Cubes run. Add a card to enable one-click top-ups and optional auto-recharge (we top you back up when your balance gets low). Tiers (which set how many Cubes you can run and how big) unlock automatically as you spend — they're limits, not bills, and cost nothing. Need more headroom? Email support and we'll review your use case and lift your limits where it makes sense.

When your balance can't cover the next hour, every running Cube is automatically powered off — its disk is kept, so you can start it again once you top up. We email you a low-balance warning about five days before you'd run out, based on your current usage, and again when the balance reaches zero. Storage still costs us money while your balance sits at zero, so if a space stays unfunded for seven days we permanently delete its backups and the disks of its powered-off Cubes. We send reminders before that happens, and adding credit at any point before the deletion date keeps everything.

Yes. Krova Cloud has a full v1 REST API: create a Cube, power it off, start it, snapshot, restore, attach custom domains, open TCP ports, and more — each authenticated with a scoped API key. You create Cubes one request at a time (concurrency limits rise with your tier, and the top tier has no fixed cap), so standing up a whole batch is a simple loop. A machine-readable OpenAPI spec is published at /api/v1/openapi.json.

Yes. Cubes are full virtual machines with their own kernel. You can install and run Docker, Podman, or any other software you would on a regular Linux server.

Cube shuts down gracefully and its disk is kept exactly as you left it — nothing on it is lost. Compute charges (vCPU + RAM) stop immediately; only the disk component of the Cube's hourly rate continues, since the rootfs still occupies host disk. Starting it again works just like powering on any server.

Krova Cloud is designed for simplicity. There's no VPC to configure, no security groups to set up, no IAM policies to write. You create a Cube, get an SSH connection, and you're done. Billing is transparent and by the minute.

Each Cube is an isolated microVM with its own kernel — not a container — and its Firecracker process runs inside a per-cube jailer sandbox (its own unprivileged user, chroot, and PID namespace), so even a hypervisor escape lands in an isolated sandbox rather than as root on the host. Your data is fully isolated from other users. Snapshots are taken automatically on a schedule and stored in encrypted object storage separate from the machine your Cube runs on, with a key unique to each Cube. Deleting a Cube offers to keep a full backup of it first — checked by default on plans that include backups — so an accidental destroy is recoverable. You can also export any Cube as a portable .cube archive and keep a copy wherever you like.

Snapshots run automatically on your tier's schedule, against a running Cube — there's no downtime to take one, and filesystem buffers are flushed inside the VM first so the captured disk is clean. Retention thins the history the way a backup system should (recent, then daily, weekly and monthly), automatic snapshots can't be deleted by hand, and you can pin one to keep it indefinitely. From any snapshot you can restore the Cube in place, clone it into a brand-new Cube (optionally with a bigger disk), or export the whole machine as a portable .cube archive you download over a private, time-limited link — and import that archive later to boot it as a Cube again.

Yes, and that's deliberate. Any Cube can be exported as a single .cube archive — a compressed, checksummed file containing the whole disk — and downloaded over a private link. The same format imports back, so the round trip works in both directions. Your data is portable out of Krova Cloud, not just inside it.

Firecracker is open source, so you could — but on its own it's a low-level hypervisor. You'd still have to build provisioning, networking, custom-domain TLS, snapshots, billing, and team access, and operate the hosts yourself. Krova Cloud is that entire platform on top of Firecracker — the same microVM technology behind AWS Lambda and Fargate — so you get VM-grade isolation in one click instead of weeks of plumbing. And unlike a shared-kernel container, where a single kernel bug can expose every tenant on the host, each Cube runs its own kernel with KVM-enforced VM isolation — which is what makes it safe for untrusted, multi-tenant workloads.

Because the architecture is cheaper to run and we pass that on. Lightweight Firecracker microVMs pack far more efficiently onto bare metal we own and operate ourselves — no reseller margin in the middle — and we put the savings into the rate card instead of into a sales team. You get the same real, dedicated resources, reserved 1:1 with no overselling, typically at less than half the price of an equivalent VPS. Same machine. A very different bill.

No. If your Cube runs a supported control panel — Dokploy, Coolify, CloudPanel, or CapRover — Krova can recognise it and keep your domain mappings in sync automatically, reading the domain list from whichever web server the panel drives (nginx, Caddy, Apache, Traefik, or LiteSpeed/OpenLiteSpeed), so entering a domain in your panel is enough. A Cube running one of those web servers on its own, with no control panel, is not offered sync — add those domains in Krova as normal. Sync is opt-in and off by default: the first time you turn it on, you see exactly what will change before anything happens. Domains it creates show as Awaiting DNS until you point their DNS at Krova, the same as any manually-added domain. Turning sync off never deletes anything — every domain it manages simply converts back to a normal, manual domain that keeps working. Krova still terminates HTTPS for every domain at its edge either way, so your panel only needs to listen on plain HTTP.