Questions people ask before they sign up.

Signing up is free, and creating an account takes no payment details. Claim $5 in free credit — one-time, per account — which runs a small Cube around the clock for over a fortnight. Nothing is charged for it, and it unlocks the Welcome tier at the same time.

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 arrives at Krova Cloud's own HTTPS proxy, which terminates HTTPS and passes each request to your Cube on its private address, 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, with certificates issued and renewed for you 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 HTTPS proxy, on the Cube's private address, never at the Cube 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 by the minute while your Cubes run, and stopped Cubes and backups pay only for the disk they keep. 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 at once, how many backups you keep, and how often snapshots are taken) unlock automatically as you spend — they're limits, not bills, and cost nothing. Cube size is never gated: every tier can run up to 16 vCPU, 32 GB RAM and 100 GB disk. 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. Add *.example.com once and every subdomain routes to your Cube under a single wildcard HTTPS certificate, so an app that creates its own subdomains never adds a mapping per subdomain. A wildcard covers one level — app.example.com and api.example.com, but not example.com itself and not a.b.example.com, which is a rule of the certificate standard rather than a Krova Cloud limit; add those as their own domains if you need them. Every subdomain shares one Cube, port and set of route settings, and adding a specific subdomain separately overrides the wildcard for that name. Setup is three DNS records added once and never changed again: a TXT proving you own the domain, the wildcard CNAME for routing, and an _acme-challenge CNAME that lets us issue and renew the certificate. Wildcard domains are available on every plan, with no cap on how many subdomains they serve.

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.

Four images across two distribution families: Ubuntu 24.04 LTS and Debian 13 (trixie), each available plain or with Docker Engine preinstalled. You pick one when you create the Cube and it is a real, full install — not a stripped container base — so you can apt install anything, run systemd, load kernel modules, and administer it exactly as you would any other Linux server. Every image is rebuilt with all security updates applied, so a new Cube starts fully patched. You log in as the ubuntu user on Ubuntu images and debian on Debian images, both with passwordless sudo.

Yes, and you can have it preinstalled. Cubes are full virtual machines with their own kernel, so Docker, Podman, or anything else you would run on a regular Linux server works normally. Two of the four images — Ubuntu 24.04 + Docker and Debian 13 + Docker — ship with Docker Engine and the Compose plugin already installed from Docker's official repository and enabled at boot, with your login user in the docker group so you do not need sudo. Pick a plain image instead if you would rather install it yourself.

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 (the most recent few, then one a day, one a week, one a month, and on the higher tiers one a year), and every snapshot tells you which rung is keeping it. 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 run our own hypervisor rather than reselling someone else's cloud, 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, for 42% to 69% less than an equivalent VPS depending on the size and the provider. Same machine. A very different bill.

Yes — once in the panel, so your app answers for the domain, and once in Krova, so the edge routes traffic to it. Krova does not read anything from inside your Cube, so it cannot see what you configured in Dokploy, Coolify, CloudPanel or CapRover. The only thing you usually have to change is the certificate: Krova already terminates HTTPS at the edge, so tell the panel not to issue one for that domain — in Dokploy that is Certificate: None. If the panel insists on serving HTTPS itself, which CloudPanel typically does, turn on "This app serves HTTPS itself" for the domain in Krova and we will connect to it over HTTPS instead.

Yes, and that is the contract: termination protection blocks accidental customer-initiated deletes, not Krova itself. While the flag is on, every delete call from the dashboard, the API, the CLI, the SDK, the MCP server and the n8n node is refused with HTTP 409 and an explicit error code, so a script or a misclick cannot destroy the cube. Krova Cloud can still terminate on your behalf — every operator-initiated bypass and every automated recovery path (the daily unfunded-storage sweep, snapshot-rollback failure cleanup, transfer cancellation cleanup, and operator-confirmed orphan-dir teardown) writes an audit row whose actorType is admin or system, and that row is the receipt. Power-off, wake, restart, restore, network-reset, and snapshot operations are NOT termination and are allowed regardless of the flag. The toggle is per Cube and opt-in, default off; turn it on in the Cube settings to enable it.