# Krova Cloud — full documentation Version: 1.0 Last updated: 2026-08-26 Canonical URL: https://krova.cloud/llms-full.txt Index: https://krova.cloud/llms.txt Pages included: 55 This is the long-form companion to /llms.txt. It carries the complete text of every marketing and documentation page on krova.cloud, converted to Markdown, in one file — so a model can answer from the source rather than from a summary. It is generated from the rendered pages (scripts/generate-llms-full.ts), never hand-written, so it cannot drift from the site. Legal documents are linked rather than inlined — they change on their own schedule and a stale copy of a contract is worse than a link to the live one. The REST API reference is an interactive OpenAPI explorer; the machine-readable spec is at https://krova.cloud/api/v1/openapi.json. > Krova gives you a private Linux server — a "Cube" — with its own kernel, full root access, and no public IP for the internet to scan. Any vCPU, RAM and disk you want rather than a fixed plan, billed by the minute, and cheaper than every VPS provider we have checked: up to ~69% under AWS Lightsail, DigitalOcean, Vultr and Linode, and 48-70% under every Hetzner plan that was actually in stock when we last looked (2026-08-17, their published USD list at 0% VAT; their Cost-Optimized CX and CAX lines are cheaper on paper but showed "not available" across every plan on that date). The same machine also runs AI agents and untrusted code with no session limit — unlike a sandbox that dies when the session ends, a Cube runs until you stop it. Krova is a self-service cloud platform that runs each app inside its own isolated Linux virtual machine. Every Cube boots its own kernel — never a shared kernel like a container — runs inside a per-cube sandbox, and has no inbound route from the internet until you open a port (outbound access is unrestricted — installs, pulls and API calls work normally). Web traffic is served through a managed-HTTPS ingress (automatic TLS, hidden origin, always-on DDoS mitigation), you get full root access, and you're billed by the minute at less than half the price of AWS Lightsail, DigitalOcean, Vultr, and Linode (up to ~69% lower on larger sizes). A Cube is a Firecracker microVM — the same isolation technology behind AWS Lambda. It has its own Linux kernel, a KVM-based isolation boundary from every other Cube, and 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. Unlike a typical VPS, a Cube has no inbound address of its own: its outbound internet access is unrestricted, but nothing inbound is reachable unless you explicitly map a port, every mapping is IP-allowlistable behind a stateful default-deny firewall, and custom-domain web traffic flows through Krova Cloud's managed ingress — so your origin is never exposed directly. Prefer Cloudflare in front? Orange-cloud your domain and it works instantly. Cubes are protected by provider-grade network DDoS mitigation. There are no VPCs, security groups, or IAM policies to configure — create a Cube (in the dashboard or via the API), get an SSH connection, and you are running. Signing up is free. Claim $5 in free credit to start — one-time, once per account, and nothing is charged for it. Beyond that you load prepaid credit as you go. Rates are quoted per hour but billed by the minute — run a Cube for 5 minutes and you pay for 5 minutes. Powering a Cube off stops compute (vCPU + RAM) billing immediately; only the disk it occupies keeps billing, at the same per-GB rate. Starting it again brings the Cube back with its disk exactly as you left it. Every GB of RAM and disk is reserved 1:1 — no overselling, no thin provisioning. Snapshots use content-addressed deduplication (Restic). Billing is 100% prepaid, pay-as-you-go: you load credit and per-resource rates are consumed for running Cubes regardless of tier — there are no subscriptions and no postpaid overage. ## Pricing - Signing up is free. Claim $5 in free credit — one-time, once per account, and nothing is charged for it - Per-hour usage, billed by the minute: $0.001/hr per vCPU · $0.0025/hr per GB RAM · $0.00005/hr per GB disk. Every GB of RAM and disk is billed 1:1 — no free tier, no overselling. Volume tiers discount larger Cubes (up to 20% off at 9+ vCPU). - Example: 1 vCPU + 2 GB RAM + 20 GB disk ≈ $0.007/hr (~$5/month running 24/7) - Every Cube size is available on every tier: up to 16 vCPU, 32 GB RAM and 100 GB disk from the moment you activate. Size is not something you unlock - Tiers unlock as you grow (limits you climb, not plans you buy): activating a space reaches Welcome, and Pro, Business and Enterprise unlock automatically by cumulative spend — each lifts how many Cubes you can run at once, how many backups you keep, and how often snapshots are taken, at no cost - Up to ~69% cheaper than an equivalent AWS Lightsail / DigitalOcean / Vultr / Linode instance; less than half the price on every comparable size ## Security & isolation - Own kernel per Cube — never a shared kernel; a kernel bug in one Cube can't reach another - Per-cube jailer sandbox (unprivileged uid, chroot, PID namespace) — escape lands in a sandbox, not host root - KVM-based isolation boundary + most-restrictive seccomp filters; cross-VM memory-dedup side channels disabled - Network-isolated from other Cubes, not only kernel-isolated — cube-to-cube traffic is dropped by the kernel at the bridge (layer 2, ARP included), with a routing-layer drop behind it - Your app is public; your server isn't. Outbound: everything (full IPv4 + IPv6 internet). Inbound: your call — no route to the Cube until you open a port, and each one is IP-allowlistable - Custom-domain web traffic served through a managed-HTTPS ingress (automatic TLS, hidden origin, always-on DDoS mitigation); orange-cloud with Cloudflare if you prefer ## Core capabilities - Full root access — your key baked in at creation, no restrictions on installed software. You log in as the `ubuntu` user (`debian` on Debian images) and `sudo su` to root with no password; direct root SSH login is disabled. Cubes created before August 2026 log in as `root` and are unchanged. - Custom domains with automatic HTTPS through the managed ingress — no cert management - Wildcard domains (`*.example.com`) route every subdomain to one Cube with a single wildcard certificate, so an app that creates its own subdomains never adds a mapping per subdomain. A wildcard covers ONE level (`app.example.com`, not `example.com` itself and not `a.b.example.com` — a certificate-standard rule, not a Krova limit), and every subdomain under it shares one Cube, port and set of route settings; an exact domain always wins over the wildcard if you need to override one. Setup is three DNS records added once and never changed again: a `_krova-verify` TXT proving ownership, the `*` CNAME for routing, and an explicit `_acme-challenge` CNAME for certificate issuance and renewal (your own `*` record does NOT cover that name, and on Cloudflare it must be DNS-only/grey). Available on every plan, with no cap on the number of subdomains served. - TCP port forwarding with per-mapping IP whitelists - Automatic snapshots on a per-tier schedule, taken against a running Cube with no downtime, thinned by a real retention policy (recent / daily / weekly / monthly). Automatic snapshots are system-managed and cannot be deleted by hand; pin one to keep it indefinitely - One-click restore of a Cube from any of its snapshots. Deleting a Cube offers to keep a full backup of it first (checked by default on plans that include backups, which then survives the deletion and can be redeployed as a new Cube), so an accidental destroy is recoverable - Cube cloning from any snapshot into a brand-new Cube, with optional disk resize upward — the source snapshot is untouched - Full data portability: export any Cube as a single compressed, checksummed `.cube` archive over a private time-limited link, and import that archive again to boot it as a Cube. Your data is portable out of Krova, not only inside it - Snapshot storage is content-addressed and deduplicated (Restic) — only changed blocks are stored — encrypted with a key unique to each Cube, held in S3-compatible object storage separate from the bare-metal host the Cube runs on, and bundled into the plan with no per-GB snapshot charge (long-lived backups that survive cube deletion are the separately-billed kind) - Teams (Spaces) with granular per-Cube access control and per-Space credit balances - Power off / start to stop compute billing on demand, with automatic power-off on zero balance - Restart (cold restart) to pick up a refreshed guest kernel — disk state is preserved; an in-Cube `reboot` cannot change the kernel because it is supplied by the host - Browser-based xterm.js terminal for any Cube, no local SSH client required - REST API (v1) with scoped API-key auth — create and manage as many Cubes as you need, plus snapshots, domains, port mappings, webhooks; OpenAPI spec at /api/v1/openapi.json ## Operating systems Four images, two distro families, each in a bare and a Docker-preinstalled flavor. Pick one at creation with `--image `; `krova images` lists them. - `ubuntu-24.04` — Ubuntu 24.04 LTS. The default, and what most Docker, Dokploy and k3s documentation assumes. Login user: `ubuntu`. - `ubuntu-24.04-docker` — the same base with Docker Engine and the Compose plugin preinstalled from Docker's official apt repository, `docker.service` enabled at boot. Login user: `ubuntu`. - `debian-13` — Debian 13 "trixie", the current Debian stable. Login user: `debian`. - `debian-13-docker` — Debian 13 with Docker Engine and Compose preinstalled. Login user: `debian`. Every image is built fresh with all security updates applied, boots the same Krova-built Linux kernel, and ships security-only unattended upgrades enabled (daily, no auto-reboot). On the Docker flavors the login user is in the `docker` group, so `docker` works without `sudo`. Package versions differ between the families — Debian 13 carries newer defaults than Ubuntu 24.04 (for example PostgreSQL 17 vs 16, Node.js 20 vs 18, Python 3.13 vs 3.12). Guides that pin a version say which family they assume. ## Common use cases - Run user or untrusted code — each workload in its own isolated Cube, safe for multi-tenant platforms - Sandboxes for AI agents and code interpreters — a disposable computer per agent, with full root, and no session ceiling: a Cube runs until you stop it, unlike session-scoped sandboxes. At the same 2 vCPU / 4 GB shape Krova costs about 93% less than E2B and Daytona and 95% less than Modal, on their own published sandbox rates (compute only; see /vs) - Self-hosted CI runners — run GitHub Actions on a Cube; the runner is outbound-only so no port is published, and Krova's own CI runs on one. Ephemeral per-job runners are also supported via the API - Docker and container workloads, web & app hosting, WordPress, Node.js / Next.js, game servers, and databases - Note: running a VPN (or any anonymization proxy) is not permitted — see the Acceptable Use Policy ## Legal - Terms of Service: https://krova.cloud/terms - Privacy Policy: https://krova.cloud/privacy - Acceptable Use Policy: https://krova.cloud/aup - Cookie Policy: https://krova.cloud/cookies - Data Processing Agreement: https://krova.cloud/dpa - Service Level Agreement: https://krova.cloud/sla - DMCA Policy: https://krova.cloud/dmca - Subprocessors: https://krova.cloud/subprocessors - Refund Policy: https://krova.cloud/refunds ## Contact - Support: support@krova.cloud # Full page text ============================================================================== URL: https://krova.cloud ============================================================================== Secure by architecture # A real Linux server. No public IP to scan. A Cube is a full Linux server — root access, its own kernel, any vCPU, RAM and disk you want, billed by the minute. Your app is public. Your server isn't. [Claim $5 in free credit](https://krova.cloud/signup) [or see how it works →](https://krova.cloud/cube) - No session limit - Own kernel per Cube - Expose only what you want Isolation model [All systems operational](https://stats.uptimerobot.com/dfhNkatAcT) Running hosting infra since 2019 Bare metal in Los Angeles — own hypervisor [Open-source on GitHub →](https://github.com/krovacloud) Installs of our packages, last 30 days 4,703 Counted by npm, not by us — [check it yourself](https://www.npmjs.com/org/krovacloud) Running hosting infrastructure since 2019 Seven years, on our own hardware. [How we got here](https://krova.cloud/about) Cheaper than sandbox providers 92% less At the same size, on their published rates — [see the arithmetic](https://krova.cloud/vs) 01 Why private ## Fewer doors. All of them yours. A typical VPS is handed a public IPv4 the moment it boots, and from then on the whole internet can scan it, brute-force it and point traffic at it. A Cube is not reachable from outside at all until you decide it should be. ### Websites and APIs Point a domain at us with one CNAME. We issue and renew the certificate, terminate HTTPS at our ingress and forward to your Cube over an internal, mutually authenticated connection — so the machine running your app is never addressed directly. ### SSH, databases, anything TCP Open a port when you need one and close it when you don't. Every mapping can be locked to an IP allowlist, so the only things that can reach your database are the addresses you named. ### Outbound is just normal apt and npm installs, Docker pulls, API calls, webhooks out — all unrestricted. Private inbound does not mean a sandboxed network you have to fight; it means nothing arrives that you did not ask for. 02 In practice ## From nothing to root, in one command No VPCs, no security groups, no IAM. Create a Cube in the dashboard or from your terminal, and you're SSH'd into your own isolated server in seconds. ``` krova cubes create web-1 \ --cpu 2 --ram 4 --disk 40 \ --image ubuntu-24.04 ✓ Cube provisioned · booted and ready krova ssh web-1 ubuntu@web-1:~$ ``` 03 The primitives ## Not a container. Not a fragile VPS. A Cube is a real virtual machine with the speed of a container — the isolation you need without the overhead you don't. 01 ### Isolated by design Its own kernel and a per-cube jailer sandbox — never a shared kernel. One Cube's bug can't reach yours. Link: https://krova.cloud/security 02 ### Boots in seconds Firecracker boots a fresh microVM in seconds. Spin them up and tear them down like ordinary processes. Link: https://krova.cloud/cube 03 ### Private by default Outbound: everything. Inbound: your call. Nothing reaches your Cube until you open a port — and each one takes an IP allowlist. Link: https://krova.cloud/security 04 ### Per-minute billing Billed by the minute, only while running. Power off a Cube and compute charges stop instantly. RAM & disk reserved 1:1. Link: https://krova.cloud/pricing/cube 04 Definition ## What is a Cube? A Cube is a lightweight microVM — built on **Firecracker**, the same isolation technology behind AWS Lambda and Fargate. Each Cube boots **its own kernel** in complete isolation from every other Cube — never the shared kernel a container hands every tenant on the box. Firecracker gives you the isolation of a virtual machine with the speed of a container. **Krova Cloud is the platform on top**: one-click or one-API-call provisioning, per-minute billing, custom domains with automatic HTTPS, snapshots, and team access — without running the hypervisor yourself. [Explore the Cube →](https://krova.cloud/cube) [See how isolation works →](https://krova.cloud/security) 05 Workloads ## What you can build on a Cube The isolation of a VM makes a Cube safe for the things a shared box can't handle — and it still runs your everyday workloads. 01 ### Run user & untrusted code Give every end-user their own isolated Cube. Each one is a Firecracker microVM with its own kernel, so one tenant's code can never see or reach another's. Link: https://krova.cloud/solutions/run-untrusted-code 02 ### Sandboxes for AI agents Give every AI agent its own disposable computer with full root. Let it install packages, run shell commands, and browse a filesystem — all sealed inside an isolated Cube. Link: https://krova.cloud/solutions/ai-agents 03 ### Self-hosted CI runners Run GitHub Actions on a microVM you control. The runner only makes outbound connections, so no port is ever exposed — and Krova's own CI runs on one. Link: https://krova.cloud/solutions/ci-runners 04 ### Docker & container workloads Run Docker and Compose inside a Cube that has its own kernel. Your containers get a full, isolated microVM to live in — not a slice of someone else's host. Link: https://krova.cloud/solutions/docker 05 ### Self-managed web & app hosting Run your own web server and stack on a Cube you fully control — full root access, its own kernel, custom domains and automatic HTTPS. This is the self-managed, do-it-yourself route: if you'd rather not administer a server at all, Nest is our managed web-hosting product. Link: https://krova.cloud/solutions/web-hosting 06 ### Databases Run Postgres, MySQL, or Redis on an isolated Cube with reserved RAM and disk. Full root, its own kernel, and resources that are never oversold. Link: https://krova.cloud/solutions/databases [See all solutions](https://krova.cloud/solutions) 06 Included ## Everything ships with every Cube No add-ons to buy. Snapshots, custom domains with automatic HTTPS, team access and the full REST API come with every Cube. ### Full root access - Your SSH key baked in at creation - Run any software — no restrictions - Full systemd, package managers, kernel modules ### Networking & domains - Custom domains with one CNAME + automatic HTTPS - Managed ingress — no certificates to handle - TCP port forwarding with IP whitelists ### Snapshots & backups - Automatic snapshots on a schedule, no downtime to take one - Restore in a click, or clone a snapshot into a whole new Cube - Export a Cube as a portable .cube file and import it back ### Teams & permissions - Spaces to organize by project or team - Granular per-Cube access control - Per-Space credit balance and billing ### Power off & restart - Power off to stop compute billing — start again in seconds - Restart to boot against the current kernel, disk preserved - Auto power-off when credits run out ### API & automation - Full v1 REST API for the whole lifecycle - Scoped API keys + idempotency - Outbound webhooks on every change 07 For developers ## Provision a Cube from your own code A fully-typed TypeScript SDK, a CLI, an MCP server for Claude & Cursor, webhook verification, an n8n node, and a public REST API — all open-source and published on npm. Spin up a Cube per user, per agent, or per build. [Explore developer tools](https://krova.cloud/developers) [Read the getting-started guide](https://krova.cloud/docs/getting-started) - [TypeScript SDK `npm i @krovacloud/sdk`](https://krova.cloud/developers) - [CLI `npm i -g @krovacloud/cli`](https://krova.cloud/developers) - [MCP server `npx -y @krovacloud/mcp`](https://krova.cloud/developers) - [Webhook verification `npm i @krovacloud/webhook`](https://krova.cloud/developers) - [n8n node `npm i n8n-nodes-krova`](https://krova.cloud/developers) 08 Pricing ## Or just run a server. Still half the bill. A Cube is a general-purpose Linux server too — up to 69% less than an equivalent instance on Lightsail, DigitalOcean, Vultr or Linode. Every figure below is current and real, and you're billed by the minute. Micro 1 vCPU · 2 GB RAM · 20 GB disk $5 /mo Popular 2 vCPU · 4 GB RAM · 40 GB disk $10 /mo Large 4 vCPU · 8 GB RAM · 80 GB disk $19 /mo XXL 8 vCPU · 16 GB RAM · 100 GB disk $33 /mo | Feature | Krova Cloud | AWS Lightsail | DigitalOcean | Vultr | Linode | | --- | --- | --- | --- | --- | --- | | Internet exposure | No public IP to scan | Public IPv4 | Public IPv4 | Public IPv4 | Public IPv4 | | Sizing | Any vCPU/RAM/disk | Fixed plans | Fixed plans | Fixed plans | Fixed plans | | Hardened per-cube sandbox | Jailer + own kernel | — | — | — | — | | 8 GB RAM / month | $20 | $44 | $48 | $40 | $48 | [See full pricing](https://krova.cloud/pricing/cube) 10 Answers ## Frequently asked questions **Does my Cube have a public IP address?** 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. **How much bandwidth do I get? Is egress metered?** 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. **Can I run Docker inside a Cube?** 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. **What happens when I power off a Cube?** 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. **Is there a subscription or monthly plan?** 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 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. [See all 22 questions →](https://krova.cloud/faq) ## Stop exposing servers. Start building. Create your free account and SSH into your first Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [View pricing](https://krova.cloud/pricing) ============================================================================== URL: https://krova.cloud/cube ============================================================================== Cube # A real Linux server. Running in seconds. A Cube is a Firecracker microVM with its own kernel — fast, secure and isolated by design. Pick any vCPU, RAM and disk, get full root access, and pay only for the minutes it runs. [Launch a Cube](https://krova.cloud/signup) [See pricing](https://krova.cloud/pricing/cube) Boots in seconds Its own kernel Expose only what you want Billed by the minute ``` spin one up from the CLI krova cubes create web-1 \ --cpu 2 --ram 4 --disk 40 \ --image ubuntu-24.04 …or the same thing in one API call curl -X POST \ https://krova.cloud/api/v1/spaces/$SPACE/cubes \ -H "X-API-KEY: $KROVA_KEY" \ -d '{ "name": "web-1", "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 } }' ``` 01 Sizing ## One Cube, any size These are popular starting points — but you're never boxed into a plan. Dial in any vCPU, RAM and disk you like and the price follows. Every GB is reserved 1:1 on the host, never oversold. Sandbox vCPU 1 RAM 1 GB Disk 10 GB $3 /mo Micro vCPU 1 RAM 2 GB Disk 20 GB $5 /mo Small vCPU 2 RAM 2 GB Disk 20 GB $6 /mo Popular Most picked vCPU 2 RAM 4 GB Disk 40 GB $10 /mo Mid vCPU 3 RAM 6 GB Disk 60 GB $15 /mo Large vCPU 4 RAM 8 GB Disk 80 GB $19 /mo XL vCPU 6 RAM 12 GB Disk 100 GB $25 /mo XXL vCPU 8 RAM 16 GB Disk 100 GB $33 /mo 3XL vCPU 12 RAM 24 GB Disk 100 GB $45 /mo Max vCPU 16 RAM 32 GB Disk 100 GB $59 /mo Monthly figures assume a Cube running 24×7. Billing is by the minute — power off a Cube and compute charges stop instantly. Up to 69% less than comparable plans on Lightsail, DigitalOcean, Vultr and Linode. 02 Built for real isolation ## Run any code, fearlessly Every Cube boots its own kernel behind a per-cube sandbox — so a workload runs on its own, never sharing a kernel with anyone else's. That's the freedom to run the things a shared box can't. ### Run your users' code safely Ship a product that runs your users' code. Each job gets its own kernel and sandbox, so one tenant's workload can never reach another's. ### Sandboxes for AI agents Give every AI agent its own disposable computer — full root, a real filesystem, and a network you control. Spin it up, let it work, throw it away. ### Self-hosted CI runners Run GitHub Actions on a Cube you control. The runner is outbound-only, so no port is published — and dependency caches survive between jobs. [See exactly how isolation works](https://krova.cloud/security) 03 The platform around it ## Everything around your Cube, handled Cube is the primitive. Krova Cloud is the platform that makes it effortless to run. ### Domains & automatic HTTPS Point a domain with one CNAME and get HTTPS automatically — certificates issued and renewed for you, no config. ### Snapshots & backups Automatic snapshots with no downtime, one-click restore, and clone or export any snapshot — your Cube is a file you can take with you. ### Power off & start Power off a Cube to stop compute billing instantly, and start it again in seconds. It auto powers off when credit runs out. ### Full API & tooling Drive the whole lifecycle from a typed SDK, a CLI, an MCP server and a public REST API — every one open-source. [Explore developer tools](https://krova.cloud/developers) [Read the docs](https://krova.cloud/docs) 04 Answers ## Frequently asked questions **How fast does a Cube boot?** In seconds. A Cube is a Firecracker microVM, not a full virtual machine that spends minutes booting — you ask for it, and it is ready to use in seconds. **What can I run on a Cube?** Anything that runs on Linux. You get full root access, systemd, your own kernel modules, Docker, any package manager — no restrictions on what you install or run. **Can I resize a Cube later?** Yes. Grow RAM and disk live with no downtime; change vCPU with a quick restart. Start small and scale the exact Cube up as your app grows. **How am I billed?** By the minute, and only while a Cube is running. Power it off and compute charges stop instantly. There's no subscription — you top up prepaid credit as you go. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. ## Launch your first Cube Create a free account and you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [Build with the API](https://krova.cloud/developers) ============================================================================== URL: https://krova.cloud/nest ============================================================================== Nest # Managed web hosting. Point, click, live. A cPanel-style panel for WordPress, email and everyday sites — one-click installs, automatic SSL and scheduled backups, with no terminal to open. One rate, and it doesn't jump when you renew. [Start hosting](https://krova.cloud/signup) See plans Plans from $1.50/mo No credit card to sign up cPanel-style panel One-click WordPress Automatic SSL Same price at renewal Nest control panel - Websites WordPress, static, PHP - Email Mailboxes & webmail - SSL certificates Issued automatically - Backups Scheduled, restorable - Databases MySQL, one click 01 What you get ## Everything a website needs, already set up A control panel, WordPress, email, SSL, backups and a way in from your old host — set up and managed for you on Krova's own infrastructure. Nothing here asks you to open a terminal or edit a config file. ### Managed control panel A familiar, cPanel-style panel for sites, databases, files and domains. Everything is point-and-click — there is no config file to edit. ### WordPress toolkit Install WordPress in one click, with plugin and theme management built into the panel. Ideal for blogs, brochure sites and small stores. ### Email hosting Create mailboxes on your own domain and read them from webmail or any mail client — no separate email provider to pay for. ### Automatic SSL Every domain gets a TLS certificate issued and renewed for you, so your site is served over HTTPS from the moment it goes live. ### Automated backups Scheduled backups run on their own, leaving restore points you can roll a site back to from the panel in a few clicks. ### Migrate from cPanel Bring your sites, databases and email across from your current cPanel host, so switching doesn't mean rebuilding anything. 02 Nest plans ## Pick a plan, pay from one balance Choose monthly or yearly and it renews automatically until you cancel — yearly takes 10% off twelve months at the monthly rate. Charges come out of the same prepaid Krova balance that pays for your Cubes, so there is no second invoice to track. Full terms on the [Nest pricing page](https://krova.cloud/pricing/nest). Solo $1.50 /mo or $16.20/yr — save 10% - 15 GB disk space - No cap bandwidth / mo - 1 website - No cap MySQL databases - 3 mailboxes [Choose this plan](https://krova.cloud/signup) Start $2 /mo or $21.60/yr — save 10% - 30 GB disk space - No cap bandwidth / mo - 2 websites - No cap MySQL databases - 10 mailboxes [Choose this plan](https://krova.cloud/signup) Grow Popular $3.50 /mo or $37.80/yr — save 10% - 60 GB disk space - No cap bandwidth / mo - 5 websites - No cap MySQL databases - No cap mailboxes [Choose this plan](https://krova.cloud/signup) Pro $6 /mo or $64.80/yr — save 10% - 100 GB disk space - No cap bandwidth / mo - 10 websites - No cap MySQL databases - No cap mailboxes [Choose this plan](https://krova.cloud/signup) Need a bigger plan than the ones above? Email [\[email protected\]](https://krova.cloud/cdn-cgi/l/email-protection#c7b4b2b7b7a8b5b387acb5a8b1a6e9a4aba8b2a3f8b4b2a5ada2a4b3fa8cb5a8b1a6e2f5f789a2b4b3e2f5f7b7aba6a9) and we will size one with you. How Nest compares ## One price. Not an intro price. Shared hosting's headline rate is a teaser: you prepay years up front, and when the term ends the price jumps 2×–4.5×. Nest has one rate. Go month to month, or take 10% off by paying yearly — either way it renews at the price you signed up at. ### Renews at the same price Every host below advertises a teaser rate, then renews at 2×–4.5× that price. Nest renews at the same price it started at — the number on this page is the number in month 37. ### No multi-year contract The intro rate is only yours if you prepay 12, 36 or 48 months — $48–$384 handed over before your site is even live. Nest's shortest term is a single month: Solo starts at $1.50. Cancel whenever, and it runs to the end of the month you paid for. ### Paid from your balance Nest charges come out of the same prepaid balance as your Cubes, so there's no second card to keep track of. Your saved card is only touched for whatever the balance doesn't cover — and if it covers the full amount, not at all. | Plan | Advertised / mo | Renews at / mo | Due up front | 3-year total | | --- | --- | --- | --- | --- | | Krova Nest — our plans | | | | | | Nest · Solo or $16.20/yr (10% off) | $1.50 | $1.50 Same price | $1.50 One month | $54.00 | | Nest · Start or $21.60/yr (10% off) | $2.00 | $2.00 Same price | $2.00 One month | $72.00 | | Nest · Grow or $37.80/yr (10% off) | $3.50 | $3.50 Same price | $3.50 One month | $126.00 | | Nest · Pro or $64.80/yr (10% off) | $6.00 | $6.00 Same price | $6.00 One month | $216.00 | | What other hosts charge — not sold by Krova | | | | | | Hostinger · Premium 48-month term | $2.99 | $10.99 | $143.52 | $107.64 | | Hostinger · Unlimited 48-month term | $3.79 | $16.99 | $181.92 | $136.44 | | Hostinger · Cloud Startup 48-month term | $7.99 | $25.99 | $383.52 | $287.64 | | SiteGround · StartUp 12-month term | $3.99 | $17.99 | $47.88 | $479.64 | | SiteGround · GrowBig 12-month term | $6.69 | $29.99 | $80.28 | $800.04 | | SiteGround · GoGeek 12-month term | $10.69 | $44.99 | $128.28 | $1,208.04 | | Bluehost · Starter 36-month term | $3.99 | $9.99 | $143.64 | $143.64 | | Bluehost · Business 36-month term | $6.99 | $13.99 | $251.64 | $251.64 | | Bluehost · eCommerce Essentials 36-month term | $6.99 | $21.99 | $251.64 | $251.64 | All figures in USD. Competitor rates are each vendor's own US published list pricing as of 2026-07-21, at the longest advertised term. “Due up front” is the full prepaid term at the intro rate; the 3-year total charges the intro rate for the prepaid term and the vendor's own renewal rate for the rest of the 36 months. Nest is quoted at its single rate for all 36 months, charged hourly (monthly ÷ 730) from your prepaid credit. ### Not sure whether you need Nest or a Cube? Pick Nest for WordPress and everyday websites you'd rather manage from a panel than a terminal — we run the server, you run the site. Pick [a Cube](https://krova.cloud/cube) for full root on your own isolated microVM — any stack, any runtime, its own kernel. 03 Answers ## Frequently asked questions **What is Nest?** Nest is managed, shared web hosting — the cPanel-style experience you already know, running on Krova. Get a control panel, one-click WordPress, email accounts, automatic SSL, and automated backups, all billed from the same prepaid credit as the rest of Krova. **Do I need any technical skill to use it?** No. Nest is built for point-and-click site management — install WordPress in one click, create email accounts from the panel, and let SSL renew itself. If you want full root and a terminal instead, that's what a Cube is for. **Can I migrate my existing site from cPanel?** Yes. Nest supports migrating sites, databases, and email from your current cPanel host, so switching over doesn't mean rebuilding from scratch. **Does the price go up when I renew?** No. Nest has no intro rate to expire — the price published on a plan is the price it renews at. A yearly term is 10% off twelve months at the monthly rate, and renews at that same rate; a monthly term renews at the monthly rate. **How is Nest billed?** Nest is a subscription: you pick a plan and a term — monthly or yearly — and it renews automatically until you cancel. Yearly is 10% off twelve months at the monthly rate. Each charge comes out of the same prepaid balance your Cubes use, and your saved card is only charged for whatever the balance doesn't cover. Cancel any time and your sites run to the end of the period you've paid for. ## Get your site live on Nest Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Start hosting](https://krova.cloud/signup) [See full Nest pricing](https://krova.cloud/pricing/nest) ============================================================================== URL: https://krova.cloud/features ============================================================================== Platform features # Certificates, firewall, snapshots, metrics. Already running. A Cube is the machine — its own kernel, full root access, any shape you like. This page is everything around it, and all of it ships with every Cube — no agent to install in the guest, no certificate to renew, no firewall to write from scratch. [Launch a Cube](https://krova.cloud/signup) [See what a Cube is](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up Automatic HTTPS Expose only what you want Snapshots on a schedule Live metrics Public REST API 01 The platform ## What ships with every Cube A raw server is a box and a bill. These are the parts that would otherwise be your weekend: certificate renewal, firewall rules, a backup cron, a metrics agent, and some way to let a colleague in without handing over root. ### Domains & automatic HTTPS Point a domain with one CNAME. The certificate is issued and renewed for you through the managed ingress, and web traffic reaches your Cube without exposing the origin. Prefer Cloudflare in front? Orange-cloud it and it works instantly. ### Expose only what you want Your app is public; your server isn't. Outbound is everything — installs, image pulls, API calls. Inbound is your call: there is no address to knock on until you open a port, and every port you open takes an IP allowlist. Link: https://krova.cloud/security ### Snapshots & one-click restore Automatic snapshots on a schedule, taken against a running Cube with no downtime. Restore in a click, clone one into a brand-new Cube, or export the whole machine as a portable .cube archive. Link: https://krova.cloud/backups ### Observability, no agents Real-time CPU, memory, disk and network for every Cube, a browser terminal that needs no local SSH client, and an activity log of every lifecycle event. Nothing to install inside the guest. ### Power off, start, restart Power off and compute billing stops immediately — only the disk keeps billing, and a zero balance powers the Cube off for you. Start it again with the disk exactly as you left it; a restart is a cold restart, so the Cube comes back on a refreshed guest kernel. ### Resize the Cube you have Grow RAM and disk live with no downtime, and change vCPU with a quick restart. Start on the smallest shape and scale that same Cube as the app grows — there is no larger plan to migrate onto, because there are no plans. ### Spaces for a team Granular per-Cube access control, a per-Space credit balance so one project cannot spend another's budget, and an activity log showing who did what. Share the infrastructure without sharing everything. ### API, SDK, CLI and MCP A public v1 REST API with scoped keys, a typed TypeScript SDK, a CLI, signed webhooks, and an MCP server that lets Claude or Cursor create Cubes in plain English. Every client library is open-source and on npm. Link: https://krova.cloud/developers 02 Month six ## The features that matter are the ones you need in month six Anything can run a container for an afternoon. These are the parts that decide whether you're still here a year later. ### The day something breaks An upgrade goes wrong at 11pm. Automatic snapshots are already running on a schedule, so recovery is a restore measured in seconds rather than an evening rebuilding a machine from memory. Snapshot storage is bundled with no per-GB charge, so nothing about that path depended on you having paid extra in advance. ### The day it outgrows the box Traffic arrives and the shape you picked stops being enough. Grow RAM and disk live with no downtime, change vCPU with a quick restart, and carry on — it is the same Cube, not a new one you have to move onto. There is no next plan up to migrate to, because there was never a plan to begin with. ### The day someone else joins Spaces give a team shared infrastructure without shared everything: per-Cube access control, a per-Space credit balance so one project cannot spend another's budget, and an activity log of who did what. Nobody has to hand over a root password to add a colleague. ### The day you want to leave Export any Cube as a single compressed, checksummed .cube archive over a private, time-limited link. The same archive imports back and boots as a Cube, so the round trip works in both directions. Being able to walk away with your machine is something we ship on purpose — and it is worth checking whether the alternatives can say the same. ### The whole snapshot story has a page of its own Retention and pinning, where snapshots are stored and how they are encrypted, cloning one into a brand-new Cube, and how .cube export and import work end to end. [See how snapshots work](https://krova.cloud/backups) ## Launch a Cube with all of it Every feature on this page ships with every Cube — nothing to bolt on, nothing to enable. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) ============================================================================== URL: https://krova.cloud/backups ============================================================================== Backups & snapshots # Your Cube is a file you own. Snapshots run on a schedule, restore in a click, and clone into a brand-new Cube. Export a whole machine as a portable .cube archive and take it with you — encrypted, deduplicated, and stored away from the host it runs on. [Launch a Cube](https://krova.cloud/signup) [See every platform feature](https://krova.cloud/features) Automatic schedule One-click restore Clone to a new Cube Export & import No per-GB snapshot charge ``` capture a known-good machine krova snapshots create web-1 \ --name pre-upgrade ✓ Created snapshot snap_8f2a (complete) …and roll straight back to it krova snapshots restore web-1 snap_8f2a ``` 01 What a snapshot is ## Four things one snapshot can do Most clouds give you a restore button and stop there. A Krova snapshot also clones, exports and imports — so the machine moves with you. ### Restore it Roll the same Cube back to how it was at any snapshot. The upgrade that broke your box is a few seconds of downtime, not an evening rebuilding it. ### Clone it into a new Cube Build a brand-new Cube from any snapshot — and give it a bigger disk on the way in. Staging that matches production exactly is one action, and the original is never touched. ### Export it as a file Turn any snapshot into a single portable .cube archive and download it over a private, time-limited link. Keep it wherever you keep your own backups. ### Import it back Upload a .cube archive and it boots as a running Cube, optionally on a larger disk. The round trip is the point: your machine is a file you own. 02 Automatic ## You don't have to remember to run them The backup you forgot to take is the one you needed. Snapshots are scheduled, rotated and protected for you — your tier sets how often and how many, and snapshot storage is bundled into the plan, with no per-GB charge on top. ### Taken on a schedule Auto-snapshots run on your tier's cadence without you asking. A powered-off Cube is captured once rather than on every run, because a stopped disk isn't changing. ### Kept on a real retention policy Retention thins the history the way a backup system should — recent ones, then daily, weekly and monthly — so you can go back a long way without paying to store every copy. ### Protected from accidents Automatic snapshots are system-managed and can't be deleted by hand. Pin one you want to keep and it stops being rotated. Deleting a Cube also offers to keep a full backup of it first, checked by default on plans that include backups. ### No downtime to take one Snapshots run against a running Cube. Filesystem buffers are flushed inside the VM first, so what lands on disk is clean — and nothing you're serving goes offline for it. [See cadence and retention by tier](https://krova.cloud/pricing/cube) 03 Where they live ## Where your snapshots actually live A backup on the same machine as the thing it is backing up is not a backup. Here is the real arrangement. ### Encrypted, with a key per Cube Every Cube gets its own snapshot repository with its own randomly generated key, and that key is itself encrypted at rest. One Cube's snapshots are unreadable from another's. ### Stored away from your host Snapshots live in S3-compatible object storage, not on the bare-metal machine your Cube runs on — so losing the host doesn't mean losing the history of what was on it. ### Only what changed is stored Storage is content-addressed and deduplicated. The first snapshot stores the disk; every one after it stores just the changed blocks, which is what makes a frequent schedule affordable. Want the whole isolation and data-handling picture? [Read the security page →](https://krova.cloud/security) A pattern worth stealing ## Build the machine once. Stamp out copies. Set a Cube up exactly how you want it, snapshot it, and clone that snapshot every time you need the same environment again — a fresh box per AI agent run, per CI job, per customer, per demo. Every copy starts from a known-good machine instead of a provisioning script you hope still works. - Clone reads the snapshot directly onto the new Cube's disk — no upload, download or archive step in between. - The source snapshot is read-only during a clone, so the base image can't be damaged by a bad run. - Each clone gets its own SSH key and its own network identity, so copies never collide. - Export the same base as a .cube archive when you want it off the platform entirely. [A Cube per agent](https://krova.cloud/solutions/ai-agents) [Self-hosted CI runners](https://krova.cloud/solutions/ci-runners) ### Portable, on purpose Being able to walk away with your data is a feature, not an oversight. A .cube archive is a single checksummed file holding the whole disk — the same format on the way out and the way back in. 1. 1 Export Pick a snapshot, ask for an export, and get a private download link when the archive is ready. 2. 2 Keep Store it wherever you keep your own backups. It is an ordinary file at that point. 3. 3 Import Upload it back and it boots as a running Cube — same disk, optionally more of it. ## The quick answers ### Do I have to power off a Cube to snapshot it? No. Snapshots are taken against a running Cube, and nothing you are serving goes offline. Filesystem buffers inside the VM are flushed first so the captured disk is clean. ### What is a .cube archive? A .cube archive is a single compressed, checksummed file containing a Cube's whole disk. You can export any snapshot as one and download it over a private, time-limited link, then import it again later to boot it as a new Cube. It is the reason your data is portable out of Krova Cloud and not only inside it. ### Can I build a new Cube from a snapshot instead of overwriting the old one? Yes — that's cloning, and it's the usual way to make a staging box that matches production, or to hand every AI agent run an identical known-good machine. The clone is a separate Cube, the source snapshot is untouched, and you can give the new Cube a larger disk as you create it. ### What happens to my data if I delete a Cube by accident? Deleting a Cube offers to keep a full backup of it first, and on plans that include backups that option is checked by default. Unlike a snapshot, that backup survives the deletion and can be redeployed later as a new Cube with its original configuration. Automatic snapshots are also system-managed and cannot be deleted by hand, which keeps the recovery history intact even when someone is tidying up. ### Are snapshots encrypted? Yes. Each Cube has its own snapshot repository encrypted with its own randomly generated key, and that key is stored encrypted at rest. Snapshots are held in object storage separate from the host your Cube runs on. ### Can I drive snapshots from the API? Yes. Create, list, restore and delete snapshots from the v1 REST API, the typed TypeScript SDK, or the CLI (krova snapshots create, list, restore, rm). Cloning, exporting and importing a Cube are available from the dashboard and the API, so a whole "capture a base image, stamp out copies" pipeline can run from your own code. ## Launch a Cube. It starts protecting itself. Snapshots, restore, clone and export ship with every Cube — nothing to enable and nothing extra to buy. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [View pricing](https://krova.cloud/pricing/cube) ============================================================================== URL: https://krova.cloud/security ============================================================================== Security # 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. [Launch a Cube](https://krova.cloud/signup) [Read the docs](https://krova.cloud/docs/getting-started) 01 Isolation ## 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. 02 Networking ## 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. ### What replaces the public IP What makes your app reachable is your domain and the ports you choose to expose, not a fixed address bolted to the whole machine. Your websites and APIs go out worldwide over HTTPS through the Krova Cloud ingress; SSH, databases, and any other TCP service open through an IP-allowlistable port mapping, on demand. You get inbound access to exactly what you expose — without the standing address the rest of the internet spends all day scanning and attacking. Fewer doors, and all of them yours. 03 Automation ## 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. create-cube.sh ``` curl -X POST https://krova.cloud/api/v1/spaces/$SPACE/cubes \ -H "X-API-KEY: $KROVA_KEY" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "name": "web-1", "image": "ubuntu-24.04", "resources": { "vcpu": 2, "ramGb": 4, "diskGb": 40 }, "sshPublicKey": "ssh-ed25519 AAAA...", "region": "us" }' ``` Full v1 REST API Idempotency keys cloud-init user-data OpenAPI spec [Read the API reference →](https://krova.cloud/docs/api) 04 Operating posture ## 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. 05 Disclosure ## Reporting a vulnerability If you have found a security issue, please tell us before you tell anyone else. Email [\[email protected\]](https://krova.cloud/cdn-cgi/l/email-protection#1c6f696c6c736e685c776e736a7d327f70736978) 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](https://krova.cloud/.well-known/security.txt). 06 Compliance ## 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](https://krova.cloud/dpa) - [Published SLA](https://krova.cloud/sla) - [Named subprocessor list](https://krova.cloud/subprocessors) - Data portability — export any Cube as an archive ### Your data stays yours - [Export any Cube as a portable archive](https://krova.cloud/backups) - 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 07 Answers ## 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. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo No credit card to sign up ============================================================================== URL: https://krova.cloud/solutions ============================================================================== Solutions # What you can build on a Cube Every workload below runs on the same thing: a Firecracker microVM with its own kernel and full root access. That is what makes it safe to run code you didn't write — and it still runs your site, your database and your game server. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up - Own kernel per Cube - Expose only what you want - Billed by the minute 01 Isolation-native ## When the code isn't yours Agents, tenants and CI jobs all execute code somebody else wrote. Each of these gets its own kernel inside a per-cube sandbox, so one workload can never reach another. Multi-tenant platforms ### Run user & untrusted code Give every end-user their own isolated Cube. Each one is a Firecracker microVM with its own kernel, so one tenant's code can never see or reach another's. See how it works Link: https://krova.cloud/solutions/run-untrusted-code Agents & code interpreters ### Sandboxes for AI agents Give every AI agent its own disposable computer with full root. Let it install packages, run shell commands, and browse a filesystem — all sealed inside an isolated Cube. See how it works Link: https://krova.cloud/solutions/ai-agents GitHub Actions & CI ### Self-hosted CI runners Run GitHub Actions on a microVM you control. The runner only makes outbound connections, so no port is ever exposed — and Krova's own CI runs on one. See how it works Link: https://krova.cloud/solutions/ci-runners Containers, done safely ### Docker & container workloads Run Docker and Compose inside a Cube that has its own kernel. Your containers get a full, isolated microVM to live in — not a slice of someone else's host. See how it works Link: https://krova.cloud/solutions/docker 02 Everyday workloads ## Your site, your database, your game server The same machine runs the ordinary things too — with its own kernel, RAM and disk reserved 1:1, and only the ports you open reachable from outside. Bring your own stack ### Self-managed web & app hosting Run your own web server and stack on a Cube you fully control — full root access, its own kernel, custom domains and automatic HTTPS. This is the self-managed, do-it-yourself route: if you'd rather not administer a server at all, Nest is our managed web-hosting product. Link: https://krova.cloud/solutions/web-hosting CMS & publishing ### WordPress hosting Run a fast, isolated WordPress site on a Cube with full root. Its own kernel, reserved resources, custom domains, and automatic HTTPS. Link: https://krova.cloud/solutions/wordpress JavaScript & TypeScript apps ### Node.js & Next.js hosting Deploy Node.js, Next.js, and other JS/TS apps on a Cube with full control. Any Node version, any process manager, your own domain with automatic HTTPS. Link: https://krova.cloud/solutions/nodejs Low-latency multiplayer ### Game servers Run low-latency game servers on a Cube you fully control. Reserved resources, full root, and TCP/UDP ports you open exactly where you want them. Link: https://krova.cloud/solutions/game-servers Postgres, MySQL & Redis ### Databases Run Postgres, MySQL, or Redis on an isolated Cube with reserved RAM and disk. Full root, its own kernel, and resources that are never oversold. Link: https://krova.cloud/solutions/databases 03 Managed hosting ## Just need a website, not a server? Nest is our managed, cPanel-style web hosting — one-click WordPress, email, automatic SSL and backups, billed from the same wallet as your Cubes. It is a different product from a Cube: no server to administer and no root access, which for most website owners is the entire point. [Explore Nest](https://krova.cloud/nest) 04 Answers ## Frequently asked questions **Is each of these a different product?** No — there is one Cube. Every workload on this page runs on the same Firecracker microVM with its own kernel and full root access. What changes is the size you pick and what you install on it. **Can one Cube run several of these at once?** Yes. You have full root, so a single Cube can run your app, its database and a background worker side by side. Splitting them across separate Cubes buys isolation instead: each one gets its own kernel, and its RAM and disk are reserved 1:1 rather than shared. **How do I know what size to create?** Start small and resize as you go. RAM and disk grow live with no downtime, and vCPU changes with a quick restart. Billing is by the minute, so running a bigger Cube for one afternoon costs you an afternoon. **Can I take my work elsewhere later?** Yes. A Cube is a standard Linux server you administer over SSH, so your stack is not written in anyone's config format. Export any Cube as a portable .cube archive and import it again — your environment is a file you hold. ## Pick a workload and launch a Cube Whatever you picked, it starts the same way — create a Cube, SSH in, and go. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) ============================================================================== URL: https://krova.cloud/solutions/run-untrusted-code ============================================================================== Multi-tenant platforms # Run user & untrusted code Give every end-user their own isolated Cube. Each one is a Firecracker microVM with its own kernel, so one tenant's code can never see or reach another's. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Real isolation per tenant Every user's workload runs in its own microVM with its own kernel and a per-cube sandbox — never a shared kernel like a container. Isolated by design, multi-tenant-safe from the first line of code. 02 ### Nothing exposed A Cube reaches the internet normally, but nothing reaches back in — there is no inbound route until you open a port, and each one is IP-allowlistable. A tenant's code can call the APIs it needs and still be unreachable from outside. 03 ### Provision and tear down by API Spin up a fresh Cube for a new user in seconds and delete it just as fast — all through the v1 REST API or SDK. Take a snapshot first if you want a clean, reusable base image. 04 ### Pay only while it runs Power a Cube off to stop compute billing the moment a session ends, and start it again in seconds when the user comes back. Billed by the minute, with RAM and disk reserved 1:1. 02 Setup ## How it works on a Cube Wrap Cube provisioning behind your own app and hand each user a sealed environment. 1. 01 Create a Cube per user with a single API call, baking in your SSH key and a base image. 2. 02 Run the user's code inside the Cube with full root — no restrictions, its own kernel underneath. 3. 03 Keep every port closed except the ones your platform needs, each IP-allowlisted. 4. 04 Power the Cube off between sessions to pause billing, and delete it (with a pre-deletion backup) when the account goes away. 03 Answers ## Frequently asked questions **How is this different from running untrusted code in a container?** A container shares the host kernel with every other tenant on the box. A Cube is a Firecracker microVM with its own kernel and a per-cube sandbox, so the isolation boundary is VM-grade — the same technology behind AWS Lambda. **Can a tenant's Cube reach another tenant's Cube?** No. Cubes are isolated from one another by design and carry no inbound route from the internet until you open a port — you decide exactly which ports are reachable and from which IPs. Outbound access is unaffected: each Cube can still reach the internet normally. **How fast can I create a Cube per user?** A Cube boots in seconds. Create and destroy them programmatically through the SDK, CLI, or REST API as users come and go. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/ai-agents ============================================================================== Agents & code interpreters # Sandboxes for AI agents Give every AI agent its own disposable computer with full root. Let it install packages, run shell commands, and browse a filesystem — all sealed inside an isolated Cube. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### A real computer, fully sandboxed An agent gets root on its own microVM with its own kernel — free to install anything and run any command, while the per-cube sandbox keeps it walled off from your other workloads. 02 ### Disposable by design Snapshot a clean base, hand a copy to each agent run, and delete it when the task finishes. Every run starts from a known-good state and leaves nothing behind. 03 ### One API call from your agent loop Provision, run, and tear down Cubes straight from your code with the typed SDK, or let an MCP-aware assistant manage them in natural language through the Krova Cloud MCP server. 04 ### Only pay for active runs Power a Cube off the instant an agent finishes and start it again in seconds for the next step. Compute is billed by the minute, so idle agents cost nothing. 05 ### It doesn't expire mid-task Every competing sandbox is ephemeral by architecture, not by pricing choice — sessions are capped in hours, and a long-running agent gets cut off. A Cube has no session ceiling. The same machine covers a thirty-second tool call and a service you leave up for a year. 06 ### A fraction of sandbox pricing At 2 vCPU and 4 GB, the published rates of the dedicated sandbox providers run an order of magnitude above ours for the same shape. The gap is largest exactly where isolation is a requirement rather than a nice-to-have — which is the whole reason a Cube exists. 02 Setup ## How it works on a Cube Back each agent session with a fresh Cube it can drive as its own machine. 1. 01 Prepare a base image with your tools pre-installed and capture it as a snapshot. 2. 02 Create a Cube from that snapshot for each agent run, so it starts clean every time. 3. 03 Let the agent execute commands over SSH or the API with full root inside the Cube. 4. 04 Power off or delete the Cube when the run ends — take a snapshot first if you want to inspect it later. 03 Answers ## Frequently asked questions **Can the agent install its own packages and run arbitrary commands?** Yes. The agent has full root inside its Cube — package managers, systemd, kernel modules, anything. The microVM boundary keeps that freedom safely contained. **What happens if an agent breaks its environment?** Nothing outside the Cube is affected. Delete it and create a fresh one from your base snapshot, or restore the snapshot to roll back instantly. **How do I connect this to my agent framework?** Use the typed TypeScript SDK or REST API to manage Cubes from your agent loop, or point an MCP client at the Krova Cloud MCP server to let the model manage them directly. The MCP server exposes the whole lifecycle as tools — create, list, power off, restart, snapshot, restore, domains and port mappings — so an MCP-aware assistant can provision its own machine without you writing glue code. **How long can an agent run before the sandbox is killed?** There is no limit. A Cube is a server, not a session: it runs until you power it off or delete it. That matters for long-horizon work — a build that takes an hour, an agent that supervises a queue, or a task you want to inspect the next morning — where a session-scoped sandbox would have terminated underneath you. **How do I give every agent run an identical starting environment?** Set one Cube up exactly how you want it, snapshot it, then clone that snapshot for each run. Cloning reads the snapshot straight onto the new Cube's disk with no upload or archive step in between, the source snapshot is read-only so a bad run cannot damage the base, and each clone gets its own SSH key and network identity so copies never collide. **What stops one agent reaching another agent's Cube?** Two layers, both enforced in the kernel. Cube-to-cube traffic is dropped at the bridge, ARP included, and a second rule at the routing layer backs it up. On top of that each Cube runs its own kernel inside a per-cube jailer sandbox, so the isolation boundary is VM-grade rather than a shared kernel with namespaces over it. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/ci-runners ============================================================================== GitHub Actions & CI # Self-hosted CI runners Run GitHub Actions on a microVM you control. The runner only makes outbound connections, so no port is ever exposed — and Krova's own CI runs on one. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Nothing exposed to the internet A runner is outbound-only: it long-polls GitHub over HTTPS and GitHub never connects back. You publish no ports at all, so your build machine has no inbound attack surface — unlike a box you have to open up for a webhook. 02 ### Your toolchain, kept warm Root access means any language, build tool or system dependency, installed exactly as your pipeline needs it. Because the Cube persists between jobs, dependency caches and Docker layers are still there on the next run instead of being rebuilt every time. 03 ### Its own kernel, not a shared one Each Cube is a Firecracker microVM with its own kernel and a per-cube sandbox, so builds are isolated at VM grade rather than by namespaces over a shared host. Snapshot a fully-provisioned runner and bring new ones up from it. 04 ### Costs nothing when idle Power a runner off between jobs to stop compute billing and pay by the minute only while a build is actually running. RAM and disk are reserved 1:1, so build times stay predictable instead of sagging under a noisy neighbour. 02 Setup ## How it works on a Cube Install the GitHub Actions runner on a Cube and point a workflow at it. 1. 01 Create a Cube, then add a non-root user for the runner — GitHub's installer refuses to configure as root. 2. 02 Download the Linux x64 runner, install its .NET dependencies, and register it against your organisation or repository. 3. 03 Install it as a systemd service, so it survives a restart and comes back on its own. 4. 04 Point a workflow at it with runs-on: \[self-hosted\] — and add Docker to the Cube if your jobs build or test against containers. Those four steps are the shape of it. The full walkthrough has every command, plus the three whose error messages do not describe the actual problem. [Read the GitHub Actions guide](https://krova.cloud/docs/how-to/github-actions-runner) 03 Answers ## Frequently asked questions **Can I use this with a public repository?** You should not, and this is GitHub's own guidance rather than ours: anyone can fork a public repository and open a pull request whose workflow runs arbitrary code on your runner. Keep self-hosted runners on private repositories. Registering at the organisation level puts a runner in the default runner group, which only private repositories can reach. **Do I need to open any ports on the Cube?** No. The runner only makes outbound connections to GitHub, so nothing needs to be published. SSH is enough to set it up, and the Cube stays unreachable from the internet for CI purposes. **Can I still get a clean machine for every job?** Yes, two ways. Register the runner with --ephemeral and it accepts one job then deregisters, so nothing carries over between builds. Or drive the whole Cube lifecycle from your pipeline with the REST API, SDK or CLI: create one from a prepared snapshot at the start of a run and delete it at the end. Both need a little automation around them; a persistent runner does not. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/docker ============================================================================== Containers, done safely # Docker & container workloads Run Docker and Compose inside a Cube that has its own kernel. Your containers get a full, isolated microVM to live in — not a slice of someone else's host. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Your own kernel for your containers Install the Docker engine and run any image with full root. Because the Cube brings its own kernel, your container host is isolated by design rather than sharing a kernel with other tenants. 02 ### Compose whole stacks Run multi-container apps with Docker Compose — web, worker, cache, and database side by side inside a single Cube you fully control. 03 ### Reachable on your own domain Point a custom domain at your containerised app with one CNAME and get automatic HTTPS. Web traffic enters through managed ingress, so the Cube is never exposed directly. 04 ### Snapshot the whole host Take a live snapshot of the entire Cube — engine, images, and volumes — and restore it instantly to roll back or clone your setup. 02 Setup ## How it works on a Cube Treat a Cube as your container host and deploy your stack onto it. 1. 01 Create a Cube with the CPU, RAM, and disk your images need. 2. 02 SSH in as root and install the Docker engine and Compose. 3. 03 Bring up your stack with docker compose up, then map a custom domain for automatic HTTPS. 4. 04 Snapshot the Cube once it's healthy so you can restore or clone it later. 03 Answers ## Frequently asked questions **Do I get real Docker, or a limited runtime?** Real Docker. You have full root on the Cube, so you install and run the standard Docker engine and Compose exactly as you would on any Linux machine. **Why run Docker inside a Cube instead of on shared infrastructure?** Cube gives your container host its own kernel and a per-cube sandbox, so your workloads are isolated at the VM level — stronger than sharing a kernel across tenants. **Can I expose a container to the web?** Yes. Map a custom domain with a single CNAME and web traffic gets automatic HTTPS through managed ingress — the Cube itself is never exposed directly. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/web-hosting ============================================================================== Bring your own stack # Self-managed web & app hosting Run your own web server and stack on a Cube you fully control — full root access, its own kernel, custom domains and automatic HTTPS. This is the self-managed, do-it-yourself route: if you'd rather not administer a server at all, Nest is our managed web-hosting product. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Full root, nothing managed for you SSH in as root and install exactly the web server, runtime and OS packages your app needs. Nothing is pre-configured or off-limits — you own and administer the whole stack yourself. 02 ### Custom domains with automatic HTTPS Point your domain with a single CNAME — Cloudflare-compatible — and certificates are issued and renewed for you. The origin is never exposed directly. 03 ### Isolated and reserved Your site runs in its own microVM with its own kernel, and every GB of RAM and disk is reserved 1:1 — never oversold. Consistent performance, isolated by design. 04 ### Snapshots and easy rollback Take a live snapshot before a deploy and restore it instantly if anything goes wrong. Keep a pre-deletion backup for an exact replica. 02 Setup ## How it works on a Cube Deploy your site onto a Cube and administer the whole stack yourself. 1. 01 Create a Cube sized for your traffic and SSH in as root. 2. 02 Install your web server and runtime, then deploy your application code. 3. 03 Add your custom domain with one CNAME and let automatic HTTPS take over. 4. 04 Snapshot the Cube so you can roll back or clone the setup anytime. 03 Answers ## Frequently asked questions **Is this the same as Nest?** No. This is self-managed hosting on a Cube — full root access, its own kernel, and you install and administer everything yourself. Nest is Krova's separate, managed web-hosting product: a control panel, one-click WordPress, email and automatic backups, with no server to administer. **Can I host more than one site on a Cube?** Yes. With full root you can run multiple sites and domains on one Cube, or spread them across several — whichever suits your setup. **Is my site's server exposed to the internet?** Web traffic enters through managed ingress rather than hitting the Cube directly, and only the ports you choose are reachable from outside. The Cube's own outbound access is unrestricted. 04 Other options ### Another Krova product may fit better Looking for hands-off, managed hosting instead — a control panel, one-click WordPress and nothing to administer? [See Nest](https://krova.cloud/nest) ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/wordpress ============================================================================== CMS & publishing # WordPress hosting Run a fast, isolated WordPress site on a Cube with full root. Its own kernel, reserved resources, custom domains, and automatic HTTPS. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Full root over your stack Install and tune the whole LEMP or LAMP stack yourself — PHP, your web server, and the database — with no managed-host restrictions on plugins or config. 02 ### Reserved resources, consistent speed RAM and disk are reserved 1:1 on the host, never oversold, so your site stays responsive under load instead of fighting noisy neighbours. 03 ### Custom domain, automatic HTTPS Map your domain with one CNAME and certificates are handled for you. There is no origin address for a botnet to find and probe. 04 ### Snapshot before every change Take a live snapshot before a plugin update or theme change and restore it instantly if something breaks. 02 Setup ## How it works on a Cube Stand up WordPress on a Cube exactly the way you want it. 1. 01 Create a Cube and SSH in as root. 2. 02 Install your web server, PHP, and database, then deploy WordPress. 3. 03 Point your domain with a CNAME and enable automatic HTTPS. 4. 04 Snapshot the finished site so updates are always reversible. 03 Answers ## Frequently asked questions **Can I install any plugin or theme?** Yes. You have full root on the Cube, so there are no host-imposed limits on plugins, themes, or PHP configuration. **Will my site slow down when a neighbour gets busy?** No. Each Cube's RAM and disk are reserved 1:1 and it runs in its own isolated microVM, so performance stays consistent. **How do I recover from a bad update?** Snapshot before you make changes and restore it in a moment if an update misbehaves — your site rolls straight back to the working state. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/nodejs ============================================================================== JavaScript & TypeScript apps # Node.js & Next.js hosting Deploy Node.js, Next.js, and other JS/TS apps on a Cube with full control. Any Node version, any process manager, your own domain with automatic HTTPS. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Any Node version, your way Full root means you pick the Node version, package manager, and process manager. Run the build, keep it alive with systemd or pm2 — no restrictions. 02 ### Long-running and full-stack Cubes are real servers, so long-lived processes, WebSockets, and background workers all just work — no cold starts, no execution time limits. 03 ### Your domain, automatic HTTPS Put your app behind a custom domain with a single CNAME and get managed HTTPS. The Cube itself is never exposed directly. 04 ### Provision from your own code Create and manage Cubes with the typed TypeScript SDK, CLI, or REST API — the whole lifecycle scriptable from your deploy pipeline. 02 Setup ## How it works on a Cube Run your Node or Next.js app on a Cube as a first-class server. 1. 01 Create a Cube and SSH in as root. 2. 02 Install your chosen Node version and pull in your app and dependencies. 3. 03 Build the app and keep it running with systemd or pm2. 4. 04 Map a custom domain with a CNAME for automatic HTTPS, then snapshot the Cube. 03 Answers ## Frequently asked questions **Are there cold starts or execution limits?** No. A Cube is a real, always-on microVM, so your Node process runs continuously — ideal for WebSockets, queues, and long-running work. **Can I run Next.js in production mode?** Yes. Build your Next.js app and run it under a process manager with full root. Add your domain for automatic HTTPS. **Can I automate deployments?** Yes. Manage the Cube lifecycle from your pipeline with the TypeScript SDK, CLI, or REST API. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/game-servers ============================================================================== Low-latency multiplayer # Game servers Run low-latency game servers on a Cube you fully control. Reserved resources, full root, and TCP/UDP ports you open exactly where you want them. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Resources reserved for your players Every GB of RAM and disk is reserved 1:1 and never oversold, so tick rates and frame budgets stay steady even when the lobby fills up. 02 ### Full control of the server Root access lets you run any game server, mod, or plugin and tune the OS exactly the way your community needs. 03 ### Open just the ports you need Forward the specific ports your game uses, each with an IP allowlist. Nothing else on the Cube is reachable — there is no address for anyone to scan. 04 ### Snapshot your world Take a live snapshot of the whole server — configs, mods, and save data — and restore it instantly to roll back or clone a fresh instance. 02 Setup ## How it works on a Cube Host your game server on a Cube tuned for your community. 1. 01 Create a Cube sized for your player count and SSH in as root. 2. 02 Install the game server software, mods, and any dependencies. 3. 03 Forward the exact TCP/UDP ports the game needs, each IP-allowlisted. 4. 04 Snapshot the configured server so you can restore or clone it anytime. 03 Answers ## Frequently asked questions **Will performance be consistent during busy sessions?** Yes. RAM and disk are reserved 1:1 on the host and never oversold, and each Cube is its own isolated microVM — so your server isn't fighting neighbours for resources. **Can I open custom UDP and TCP ports?** Yes. Forward exactly the ports your game needs, each with an IP allowlist. Everything else stays closed by default. **Can I run mods and custom server builds?** Absolutely. Full root means any game, any mod, and any configuration you want. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/solutions/databases ============================================================================== Postgres, MySQL & Redis # Databases Run Postgres, MySQL, or Redis on an isolated Cube with reserved RAM and disk. Full root, its own kernel, and resources that are never oversold. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Why a Cube ## Why run this on a Cube Every line here is enforced by the platform rather than left to you: its own kernel per Cube, RAM and disk reserved 1:1, and full outbound access while nothing reaches in until you open a port — each one IP-allowlistable. 01 ### Reserved RAM and disk Databases love predictable memory and I/O. On a Cube every GB is reserved 1:1 and never thin-provisioned, so your working set stays warm and performance stays steady. 02 ### Tune it exactly how you like Full root lets you set your own config, extensions, and kernel parameters — run Postgres with the extensions you need or Redis tuned for your workload. 03 ### Isolated and unexposed Your database runs in its own microVM with its own kernel and no inbound route. Open the database port only to the specific IPs that need it. 04 ### Snapshots and backups built in Take live snapshots for point-in-time copies and keep a pre-deletion backup for an exact replica — restore instantly whenever you need to. 02 Setup ## How it works on a Cube Run your database on a Cube sized and secured for it. 1. 01 Create a Cube with the RAM and disk your dataset needs and SSH in as root. 2. 02 Install Postgres, MySQL, or Redis and apply your configuration. 3. 03 Open the database port only to the specific IPs that should connect, keeping everything else closed. 4. 04 Schedule snapshots and keep a backup so you can restore to a known-good state anytime. 03 Answers ## Frequently asked questions **Is the memory and disk really reserved for my Cube?** Yes. Every GB of RAM and disk on a Cube is reserved 1:1 on the host and never oversold or thin-provisioned — so your database gets consistent, predictable resources. **Can I install extensions and tune the config?** Yes. With full root you control the full configuration, extensions, and kernel parameters — set the database up exactly the way your workload needs. **How do I keep the database private?** A Cube has no inbound route until you create one. Open the database port only to the specific IPs that need access and leave everything else closed. ## Launch your first Cube Signing up is free — you'll be SSH'd into your own Cube in under a minute. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See all solutions](https://krova.cloud/solutions) ============================================================================== URL: https://krova.cloud/pricing ============================================================================== Pricing # Two products. One balance. Run a Cube and pay by the minute for exactly what you use, or put a site on Nest for a fixed price each month. Both draw on the same prepaid balance, so there's one card and one place to top up. Jump to [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo No credit card to sign up ### Cube A server you control, billed by the minute. Starting from $2.92 /mo - Root access and your own kernel - Any vCPU / RAM / disk combination - Billed by the minute, only while running - Power it off and compute charges stop Smallest Cube: 1 vCPU · 1 GB RAM · 10 GB disk, at $0.0040/hr running 24/7. Up to 69% less than an equivalent VPS. [See Cube pricing](https://krova.cloud/pricing/cube) ### Nest Managed web hosting on a fixed plan. Starting from $1.50 /mo - Control panel — no terminal needed - One-click WordPress and app installs - Email accounts and automatic SSL - Automated backups included Fixed monthly or yearly plan, renewing at the price you signed up at. Pay yearly and save 10%. [See Nest pricing](https://krova.cloud/pricing/nest) 01 How billing works ## No subscription — you load credit and spend it Nothing renews and nothing bills you monthly. Work out what a top-up covers before you make one. ### How long will your credit last? Running 24/7. Power a Cube off and compute billing stops, so real runway is usually longer than this. Credit Cube size $10 on a Popular Cube lasts about 29 days $10.22/month · $0.0140/hour, billed by the minute 02 Choosing ## Which one do you need? The short version: a Cube gives you a terminal, Nest gives you a panel. | Feature | Cube | Nest | | --- | --- | --- | | How you pay | Prepaid, by the minute | Monthly or yearly plan (10% off yearly) | | How you manage it | Root access, your own kernel | Web control panel, no terminal | | What it runs | Anything you can install on Linux | WordPress, PHP sites, email | | Sizing | Any vCPU / RAM / disk combination | Fixed disk, bandwidth and site allowances | | What happens when idle | Stops when you power it off | Plan runs for the period you paid for | | Typical fit | APIs, agents, CI, databases, side projects | Marketing sites, client sites, blogs, email | [Cube pricing](https://krova.cloud/pricing/cube) [Nest pricing](https://krova.cloud/pricing/nest) ### Not sure whether you need a Cube or Nest? Two questions — we'll point you to the right product. Do you want root access and full control? ### One prepaid balance covers both You top up your space once. Cube usage draws it down by the minute; a Nest plan charges against it when the term renews. There is one card on file, one balance to watch, and no separate invoice for either product. Signing up is free, and we credit you $5 to start, one-time — nothing is charged for it. 03 Answers ## Common questions **What's the difference between a Cube and Nest?** A Cube is a server you control: root access, your own kernel, install anything. You're billed by the minute for the compute you run. Nest is managed shared hosting: a control panel, one-click WordPress, email accounts and automatic SSL, on a fixed monthly or yearly plan. Pick Cube if you want a terminal, Nest if you want a panel. **Do I need two accounts or two payment methods?** No. One Krova Cloud account, one prepaid balance. Cube usage draws it down per minute; a Nest plan charges against the same balance when it renews. There is only ever one card on file, and only one place to top up. **Can I use both at the same time?** Yes, and plenty of people do — a Nest for the marketing site and email, a Cube for the app or API behind it. They live in the same space and share the same balance and team permissions. **Is there a free plan?** Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. From there you add prepaid credit as you go. Nest plans are paid from that same balance. ## Start free, pay for what you run. Signing up is free, and we credit you $5 to start — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [Talk to us](https://krova.cloud/contact) ============================================================================== URL: https://krova.cloud/pricing/cube ============================================================================== Cube pricing # Less than half the price. Any size you want. The same dedicated vCPU, RAM and disk you would buy from AWS Lightsail, DigitalOcean, Vultr or Linode — for up to 69% less. Sized to whatever shape you want, billed by the minute, and every GB reserved 1:1 on the host. Choose a product Cube is prepaid compute you control over SSH. [Nest](https://krova.cloud/pricing/nest) is managed web hosting on a fixed monthly or yearly plan. [Launch a Cube](https://krova.cloud/signup) See the rate card Cubes from $2.92/mo No credit card to sign up 01 Rates ## What each resource costs Quoted per hour, charged per minute. Power a Cube off and vCPU and RAM stop billing immediately — only the disk it occupies keeps its per-GB rate, on the full disk size. | Resource | Rate | | --- | --- | | vCPU | $0.0010/hr per vCPU | | RAM | $0.0025/hr per GB Sold 1:1 with host RAM — no overselling | | Disk | $0.00005/hr per GB Reserved 1:1 — no overselling | Example: 1 vCPU + 2 GB RAM + 20 GB disk $0.007 /hr ~$5.11/mo running 24/7 Claim $5 in free credit — one-time, per account, and nothing is charged for it. Billed by the minute — run 5 minutes, pay 5 minutes 02 Sizes ## Common Cube sizes Pick any vCPU, RAM and disk combination you like — these are only the popular presets, with the volume discount already applied. | Size | vCPU | RAM | Disk | Volume discount | Per hour | Per month | | --- | --- | --- | --- | --- | --- | --- | | Sandbox | 1 | 1 GB | 10 GB | — | $0.0040 | $2.92 | | Micro | 1 | 2 GB | 20 GB | — | $0.0070 | $5.11 | | Small | 2 | 2 GB | 20 GB | — | $0.0080 | $5.84 | | Popular | 2 | 4 GB | 40 GB | — | $0.0140 | $10.22 | | Mid | 3 | 6 GB | 60 GB | 5% off | $0.0201 | $14.67 | | Large | 4 | 8 GB | 80 GB | 5% off | $0.0266 | $19.42 | | XL | 6 | 12 GB | 100 GB | 15% off | $0.0349 | $25.48 | | XXL | 8 | 16 GB | 100 GB | 15% off | $0.0451 | $32.92 | | 3XL | 12 | 24 GB | 100 GB | 20% off | $0.0616 | $44.97 | | Max | 16 | 32 GB | 100 GB | 20% off | $0.0808 | $58.98 | Per-month estimate = hourly rate × 730 hours, running 24/7. Power off a Cube and disk continues at the same per-GB rate while vCPU and RAM stop billing entirely. 4 OS images to start from. At Popular (2 vCPU · 4 GB): Krova $10.22/mo vs Lightsail $20 — 51% less. Same vCPU, RAM and disk. ### Pick by workload Not sure what size to start with — pick the workload that matches. [Sandbox per run AI agent 1 vCPU · 2 GB · 20 GB $5.11/mo Choose this size](https://krova.cloud/pricing/cube) [API + frontend Web app 2 vCPU · 4 GB · 40 GB $10.22/mo Choose this size](https://krova.cloud/pricing/cube) [Postgres / Redis Database 4 vCPU · 8 GB · 80 GB $19.42/mo Choose this size](https://krova.cloud/pricing/cube) [CI / ephemeral Build runner 8 vCPU · 16 GB · 100 GB $32.92/mo Choose this size](https://krova.cloud/pricing/cube) ### How long will your credit last? Running 24/7. Power a Cube off and compute billing stops, so real runway is usually longer than this. Credit Cube size $10 on a Popular Cube lasts about 29 days $10.22/month · $0.0140/hour, billed by the minute 03 Tiers ## Tiers unlock as you grow There's nothing to subscribe to. Every new space starts on the entry tier and climbs the ladder on its own — activate the space, then spend as you go — unlocking more Cubes at once and bigger sizes. Tiers set your limits; usage is the only thing you pay for. Welcome Add a payment card - 3 cubes running at once - 16 vCPU · 32 GB RAM · 100 GB disk max cube size - 5 backups Pro After $15 lifetime spend - 10 cubes running at once - 16 vCPU · 32 GB RAM · 100 GB disk max cube size - 25 backups Business After $50 lifetime spend - 25 cubes running at once - 16 vCPU · 32 GB RAM · 100 GB disk max cube size - 100 backups Enterprise After $300 lifetime spend - No cap cubes running at once - 16 vCPU · 32 GB RAM · 100 GB disk max cube size - No cap backups Tiers are limits, not bills — they cost nothing. You're charged only for the compute and storage your Cubes actually use. [Launch a Cube](https://krova.cloud/signup) ### Need a higher tier sooner? Tiers unlock automatically as you spend, but if you need headroom now — bigger Cubes, or more of them at once — just ask. Tell us what you're running and we'll lift your limits where it makes sense. [Ask for more headroom](https://krova.cloud/cdn-cgi/l/email-protection#55262025253a2721153e273a23347b36393a20316a2620373f30362168013c30277067652025322734313070676527302420302621) 04 No overselling ## Every GB is reserved 1:1 Budget hosting leans on overselling — more RAM and disk sold than the host physically has, on the bet that customers won't use it. When workloads spike, you pay for that bet: thrashed RAM, evicted pages, throttled I/O, and an app that slows down exactly when it is busiest. Krova Cloud reserves what you provision. Your 4 GB Cube holds 4 GB of host RAM to itself, and a 40 GB disk occupies 40 GB of real storage — no thin provisioning, no surprise out-of-disk errors. RAM Reserved 1:1 against host RAM whenever your Cube is running, and dedicated to it alone. Never oversold. Disk Real bytes on real disk, not a quota against a shared pool — held whether the Cube runs or not, which is why disk is the one thing that keeps billing after you power off. 05 Versus the alternatives ## How this compares Every figure read from the provider's own pricing page and stamped with the date we read it, with the arithmetic shown. [VPS providers 51–69% less Lightsail, DigitalOcean, Vultr and Linode at the same vCPU, RAM and disk. See the arithmetic](https://krova.cloud/vs) [Hetzner 48–70% less Matched shape for shape against every plan they had in stock on 2026-08-17. See the arithmetic](https://krova.cloud/vs/hetzner) [Sandbox providers 93–95% less E2B, Modal and Daytona at 2 vCPU / 4 GB on their published rates. See the arithmetic](https://krova.cloud/vs) 06 Answers ## Questions about the bill **Is there a subscription or monthly plan?** 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 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. **How does billing work — what if I only run a Cube for 5 minutes?** 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. **What happens when I power off a Cube?** 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. **What happens when my credit runs out?** 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. **Why is Krova Cloud cheaper than AWS, DigitalOcean, or Linode?** 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. Nest ### Want a control panel instead of a terminal? Nest is managed shared hosting — WordPress in one click, email accounts, automatic SSL and backups. It is billed on a fixed monthly or yearly plan rather than per minute, so it has its own pricing page. [See Nest pricing](https://krova.cloud/pricing/nest) ## No subscription. Pay by the minute. Prepaid credit, drawn down only while your Cubes run. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [How isolation works](https://krova.cloud/security) ============================================================================== URL: https://krova.cloud/pricing/nest ============================================================================== Nest pricing # Managed hosting on a plan, not a meter. A control panel, one-click WordPress, email accounts, automatic SSL and backups — for a fixed price each month or year. Pay yearly and save 10%, at every renewal. Choose a product Nest is a subscription for managed hosting. [Cube](https://krova.cloud/pricing/cube) is prepaid compute billed by the minute. 01 Plans ## Pick a plan Every plan includes the control panel, one-click app installs, automatic SSL, email accounts and automated backups. Choose monthly or yearly when you subscribe — you can switch plans later. Solo $1.50 /mo or $16.20/yr — save 10% - 15 GB disk space - No cap bandwidth / mo - 1 website - No cap MySQL databases - 3 mailboxes [Choose this plan](https://krova.cloud/signup) Start $2 /mo or $21.60/yr — save 10% - 30 GB disk space - No cap bandwidth / mo - 2 websites - No cap MySQL databases - 10 mailboxes [Choose this plan](https://krova.cloud/signup) Grow Popular $3.50 /mo or $37.80/yr — save 10% - 60 GB disk space - No cap bandwidth / mo - 5 websites - No cap MySQL databases - No cap mailboxes [Choose this plan](https://krova.cloud/signup) Pro $6 /mo or $64.80/yr — save 10% - 100 GB disk space - No cap bandwidth / mo - 10 websites - No cap MySQL databases - No cap mailboxes [Choose this plan](https://krova.cloud/signup) Prices in USD. Yearly is 10% off twelve months at the monthly rate — a standing rate, not an introductory offer. 02 How billing works ## How the subscription works Nest bills differently from a Cube. Here is exactly what you are agreeing to. ### A term that renews You buy a fixed term — one month or one year — and it renews automatically on the same calendar date each period until you cancel. Yearly is 10% off twelve monthly payments, and renews at that same discounted rate. ### Paid from your balance first Each charge comes out of your prepaid Krova Cloud balance first. Your saved card is charged only for whatever the balance doesn't cover — and if the balance covers it in full, your card isn't touched. No saved card is needed to subscribe if your balance is sufficient. ### Cancel any time, no partial refund Cancel any time from your dashboard. Your sites keep running until the end of the period you've already paid for, and no further renewal is charged. Cancelling doesn't refund the unused part of the current period, and you can undo a scheduled cancellation before it takes effect. ### If a payment fails If a renewal can't be paid we retry on an escalating schedule and email you. If it still fails, the account is suspended — panel and sites offline, nothing deleted yet — and you get a 14-day window to add credit and bring it straight back. After that window the account and its data are deleted. Verification comes first Nest subscriptions require the account owner to be verified before purchase. It's a one-time check, and it has to be approved — not just submitted — before you can subscribe. Auto-recharge caps don't block a renewal The monthly limit you can set on automatic top-ups governs balance-triggered top-ups only. It does not cap a Nest renewal you authorised at purchase, where the amount and date were shown up front. The full terms — renewal, payment, cancellation and what happens after suspension — are in [section 5.6 of our Terms](https://krova.cloud/terms), with refund policy in [our refund policy](https://krova.cloud/refunds). How Nest compares ## One price. Not an intro price. Shared hosting's headline rate is a teaser: you prepay years up front, and when the term ends the price jumps 2×–4.5×. Nest has one rate. Go month to month, or take 10% off by paying yearly — either way it renews at the price you signed up at. ### Renews at the same price Every host below advertises a teaser rate, then renews at 2×–4.5× that price. Nest renews at the same price it started at — the number on this page is the number in month 37. ### No multi-year contract The intro rate is only yours if you prepay 12, 36 or 48 months — $48–$384 handed over before your site is even live. Nest's shortest term is a single month: Solo starts at $1.50. Cancel whenever, and it runs to the end of the month you paid for. ### Paid from your balance Nest charges come out of the same prepaid balance as your Cubes, so there's no second card to keep track of. Your saved card is only touched for whatever the balance doesn't cover — and if it covers the full amount, not at all. | Plan | Advertised / mo | Renews at / mo | Due up front | 3-year total | | --- | --- | --- | --- | --- | | Krova Nest — our plans | | | | | | Nest · Solo or $16.20/yr (10% off) | $1.50 | $1.50 Same price | $1.50 One month | $54.00 | | Nest · Start or $21.60/yr (10% off) | $2.00 | $2.00 Same price | $2.00 One month | $72.00 | | Nest · Grow or $37.80/yr (10% off) | $3.50 | $3.50 Same price | $3.50 One month | $126.00 | | Nest · Pro or $64.80/yr (10% off) | $6.00 | $6.00 Same price | $6.00 One month | $216.00 | | What other hosts charge — not sold by Krova | | | | | | Hostinger · Premium 48-month term | $2.99 | $10.99 | $143.52 | $107.64 | | Hostinger · Unlimited 48-month term | $3.79 | $16.99 | $181.92 | $136.44 | | Hostinger · Cloud Startup 48-month term | $7.99 | $25.99 | $383.52 | $287.64 | | SiteGround · StartUp 12-month term | $3.99 | $17.99 | $47.88 | $479.64 | | SiteGround · GrowBig 12-month term | $6.69 | $29.99 | $80.28 | $800.04 | | SiteGround · GoGeek 12-month term | $10.69 | $44.99 | $128.28 | $1,208.04 | | Bluehost · Starter 36-month term | $3.99 | $9.99 | $143.64 | $143.64 | | Bluehost · Business 36-month term | $6.99 | $13.99 | $251.64 | $251.64 | | Bluehost · eCommerce Essentials 36-month term | $6.99 | $21.99 | $251.64 | $251.64 | All figures in USD. Competitor rates are each vendor's own US published list pricing as of 2026-07-21, at the longest advertised term. “Due up front” is the full prepaid term at the intro rate; the 3-year total charges the intro rate for the prepaid term and the vendor's own renewal rate for the rest of the 36 months. Nest is quoted at its single rate for all 36 months, charged hourly (monthly ÷ 730) from your prepaid credit. 03 Answers ## Nest billing questions **How is Nest billed?** Nest is a subscription. You pick a plan and a term — monthly or yearly — and it renews automatically on the same date each period until you cancel. Yearly is priced at 10% off twelve months at the monthly rate, and that discounted rate applies at every renewal, not just the first. **How do I pay for it?** Each charge is taken from your prepaid Krova Cloud balance first — the same balance your Cubes draw on. Your saved card is only charged for the shortfall if your balance does not cover the full amount. If your balance covers it, your card is never touched, and you do not need a saved card at all to subscribe. **Can I cancel, and do I get a refund?** You can cancel any time from your dashboard. Cancellation takes effect at the end of the period you have already paid for — your sites keep running until then and no further renewal charge is made. Cancelling does not refund the unused part of the current period. You can undo a scheduled cancellation any time before the period ends. **What happens if a renewal payment fails?** We retry on an escalating schedule and email you. If it still cannot be paid, the hosting account is suspended — your panel and sites go offline, but nothing is deleted at that point. You then have a 14-day recovery window: add credit (or reactivate from the dashboard) and everything comes straight back. If the window passes without payment, the account and its data are deleted. **Is Nest billed by the minute like a Cube?** No, and this is the main difference between the two products. A Cube is prepaid compute charged per minute only while it runs. Nest is a fixed subscription for a defined period — you are buying a hosting plan for a month or a year, not metered usage. Both are paid out of the same prepaid balance. **Do I need anything before I can subscribe?** Your account needs to be verified first. Verification is a quick one-time check on the account owner, and it has to be approved before a Nest subscription can be purchased. ## Put your site on a managed panel. One-click WordPress, email, SSL and backups — on a plan you can cancel any time. [Start hosting](https://krova.cloud/signup) [Explore Nest](https://krova.cloud/nest) ============================================================================== URL: https://krova.cloud/vs ============================================================================== Comparisons # The same machine, priced both ways. 10 head-to-head pages. Every competitor figure was read off their own pricing page on the date shown, and each page shows the arithmetic. [Launch a Cube](https://krova.cloud/signup) Cubes from $2.92/mo No credit card to sign up 01 Head to head ## Pick the one you're deciding against Sandbox platforms and VPS providers, each sized to the same vCPU, RAM and disk as a Cube. Open one for both rate cards, the arithmetic under them, and a dated link to the source. ### Krova Cloud vs E2B Sandboxes for AI agents and code interpreters, driven by an SDK. Cube $10.22/mo · E2B $120.89/mo · 2 vCPU · 4 GB · verified 2026-08-04 92% less, at the same size Link: https://krova.cloud/vs/e2b ### Krova Cloud vs Modal Serverless AI infrastructure — inference, training, and sandboxes. Cube $10.22/mo · Modal $173.71/mo · 2 vCPU · 4 GB · verified 2026-08-13 94% less, at the same size Link: https://krova.cloud/vs/modal ### Krova Cloud vs Daytona Secure infrastructure for running AI-generated code, by the sandbox. Cube $10.22/mo · Daytona $120.89/mo · 2 vCPU · 4 GB · verified 2026-08-13 92% less, at the same size Link: https://krova.cloud/vs/daytona ### Krova Cloud vs Vercel Sandbox Ephemeral sandboxes for running AI-generated code, inside Vercel. Cube $9.93/mo · Vercel Sandbox $248.78/mo · 2 vCPU · 4 GB · verified 2026-08-13 96% less, at the same size Link: https://krova.cloud/vs/vercel-sandbox ### Krova Cloud vs AWS Lightsail Amazon's simplified VPS — fixed monthly bundles. Cube $11.68/mo · AWS Lightsail $20.00/mo · 2 vCPU · 4 GB · verified 2026-08-17 42% less, at the same size Link: https://krova.cloud/vs/lightsail ### Krova Cloud vs Vultr General-purpose cloud VMs — Cloud Compute instances. Cube $11.68/mo · Vultr $20.00/mo · 2 vCPU · 4 GB · verified 2026-08-17 42% less, at the same size Link: https://krova.cloud/vs/vultr ### Krova Cloud vs Northflank A developer platform for services, jobs and sandboxed workloads. Cube $10.22/mo · Northflank $48.66/mo · 2 vCPU · 4 GB · verified 2026-08-14 79% less, at the same size Link: https://krova.cloud/vs/northflank ### Krova Cloud vs Linode Akamai Cloud's general-purpose VMs — the Shared CPU plans. Cube $11.68/mo · Linode $24.00/mo · 2 vCPU · 4 GB · verified 2026-08-17 51% less, at the same size Link: https://krova.cloud/vs/linode ### Krova Cloud vs DigitalOcean General-purpose VPS hosting — Droplets. Cube $11.68/mo · DigitalOcean $24.00/mo · 2 vCPU · 4 GB · verified 2026-08-17 51% less, at the same size Link: https://krova.cloud/vs/digitalocean ### Krova Cloud vs Hetzner European VPS hosting — Cloud servers, plus two US regions. Cube $11.68/mo · Hetzner $23.59/mo · 2 vCPU · 4 GB · verified 2026-08-17 50% less, at the same size Link: https://krova.cloud/vs/hetzner 02 Methodology ## How these numbers were produced A comparison page is only worth reading if it survives being checked. This is exactly how every figure above was produced. ### Read, not remembered Every competitor figure was opened in a browser on their own pricing page and read off it, on the date printed beside the comparison. Not a blog post, not a comparison site, not memory. Each page links straight back to the source, so you can check it in one click. ### Like-for-like, or not at all Both sides are sized to the same vCPU, RAM and disk. Where a provider caps a machine below our usual shape, the comparison drops to their ceiling rather than quoting a size they cannot sell. Where they cap the month, we quote their capped monthly price rather than multiplying the hourly rate out. ### Deliberately conservative Sandbox providers bill storage separately, so their figure is compute alone while ours still carries the disk — which makes our advantage look smaller, not larger. Platform fees are shown as their own line rather than folded into the headline multiple. ### Kept fresh, by force Competitors change prices without telling anyone, so a good reading quietly rotting is the real risk. A build-time guard fails once any comparison here is more than ninety days old, which makes the re-check mandatory rather than remembered. Spotted a figure that has moved? [Tell us and we will fix it](https://krova.cloud/contact) — a comparison page is only worth reading if it survives being checked. ## Numbers check out? Launch one. Signing up is free. Size a Cube against whatever you are comparing it with, and check every figure above on your own account. [Launch a Cube](https://krova.cloud/signup) [See the per-hour rates](https://krova.cloud/pricing/cube) ============================================================================== URL: https://krova.cloud/vs/e2b ============================================================================== Comparison # Krova Cloud vs E2B Sandboxes for AI agents and code interpreters, driven by an SDK. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $10.22/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 92% less than E2B Their figure read from [their own pricing page](https://e2b.dev/pricing) on 2026-08-04 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 40 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $10.22 /mo $0.0140/hr · billed by the minute E2B $120.89 /mo $0.1656/hr · plus a $150/mo platform fee At this size Krova Cloud costs 92% less than E2B on usage alone — before their $150/month platform fee, which would take it to 26.5×. ### How we got there E2B: $0.000014 per vCPU-second and $0.0000045 per GiB-second — $0.0504/vCPU-hr and $0.0162/GiB-hr — plus $150/month for the Pro tier. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. E2B's figures were read from [their own pricing page](https://e2b.dev/pricing) on 2026-08-04. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - No session limit. Their sandboxes stop at 1 hour on Hobby and 24 hours on Pro — a Cube runs until you stop it. - No monthly platform fee. Pro is $150/month before you run anything. - Full root access into a real Linux server, not only an SDK surface — systemd, Docker, kernel modules, any package manager. - Snapshot a warm base once, then clone it into a fresh Cube per agent run. Every run starts from a known-good machine instead of rebuilding the environment. - Export any Cube as a portable .cube archive and import it again. Your agent environment is a file you hold, not a state that only exists inside one vendor. - Automatic scheduled snapshots with real retention, kept in encrypted, content-addressed storage and bundled into the plan with no per-GB charge — so a wrecked sandbox is a restore, not a rebuild. - The same Cube can become your production host, so there is no migration when the experiment works. 03 Answers ## Before you decide **Where do these E2B numbers come from?** From E2B's own pricing page, opened in a browser and read off it on 2026-08-04 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $10.22 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/modal ============================================================================== Comparison # Krova Cloud vs Modal Serverless AI infrastructure — inference, training, and sandboxes. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $10.22/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 94% less than Modal Their figure read from [their own pricing page](https://modal.com/pricing) on 2026-08-13 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 40 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $10.22 /mo $0.0140/hr · billed by the minute Modal $173.71 /mo $0.2380/hr At this size Krova Cloud costs 94% less than Modal. ### How we got there Modal: $0.00003942 per physical core-second — their page defines a physical core as a 2 vCPU equivalent — and $0.00000667 per GiB-second, with a minimum of 0.125 cores per container. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Modal's figures were read from [their own pricing page](https://modal.com/pricing) on 2026-08-13. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - No session ceiling and no serverless lifecycle. A Cube is a machine that stays up until you stop it, not a function invocation that has to be kept warm. - Full root access into a real Linux server — systemd, Docker, kernel modules, any package manager — rather than a Python-decorator programming model you have to fit your app into. - Roughly a twentieth of the price at the same 2 vCPU / 4 GB shape, on their own published sandbox rates. - The same Cube becomes your production host, so a prototype does not need re-platforming when it works. - Snapshot a warm base once, then clone it into a fresh Cube per run — every agent starts from a known-good machine instead of rebuilding its environment. - Export any Cube as a portable .cube archive and import it again — your environment is a file you hold, not state that only exists inside one vendor. 03 Answers ## Before you decide **Where do these Modal numbers come from?** From Modal's own pricing page, opened in a browser and read off it on 2026-08-13 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $10.22 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/daytona ============================================================================== Comparison # Krova Cloud vs Daytona Secure infrastructure for running AI-generated code, by the sandbox. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $10.22/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 92% less than Daytona Their figure read from [their own pricing page](https://www.daytona.io/pricing) on 2026-08-13 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 40 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $10.22 /mo $0.0140/hr · billed by the minute Daytona $120.89 /mo $0.1656/hr At this size Krova Cloud costs 92% less than Daytona. ### How we got there Daytona: $0.0504 per vCPU-hour and $0.0162 per GiB-hour, with storage billed separately at $0.000108 per GiB-hour after the first 5 GiB. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Daytona's figures were read from [their own pricing page](https://www.daytona.io/pricing) on 2026-08-13. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - No session ceiling. A Cube runs until you stop it, so the same machine covers a 30-second agent run and a service you leave up for a year. - Roughly a fourteenth of the price at the same 2 vCPU / 4 GB shape, on their own published rates. - Full root access into a real Linux server, not only an SDK surface — install anything, run systemd, run Docker. - Disk is included in the per-minute rate rather than metered as a separate line once you pass a free allowance. - Automatic scheduled snapshots with real retention, plus clone-to-a-new-Cube — a wrecked sandbox is a restore, not a rebuild. - Export any Cube as a portable .cube archive and import it again — your data is portable out of Krova, not only inside it. 03 Answers ## Before you decide **Where do these Daytona numbers come from?** From Daytona's own pricing page, opened in a browser and read off it on 2026-08-13 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $10.22 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/vercel-sandbox ============================================================================== Comparison # Krova Cloud vs Vercel Sandbox Ephemeral sandboxes for running AI-generated code, inside Vercel. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $9.93/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 96% less than Vercel Sandbox Their figure read from [their own pricing page](https://vercel.com/docs/vercel-sandbox/pricing) on 2026-08-13 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 32 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $9.93 /mo $0.0136/hr · billed by the minute Vercel Sandbox $248.78 /mo $0.3408/hr At this size Krova Cloud costs 96% less than Vercel Sandbox. ### How we got there Vercel Sandbox: $0.128 per Active CPU hour and $0.0212 per GB-hour of provisioned memory on Pro. Active CPU is metered on actual CPU work, so a mostly-idle sandbox costs less than this — the figure here is a sandbox under sustained load, which is the like-for-like comparison against a Cube that stays up. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Vercel Sandbox's figures were read from [their own pricing page](https://vercel.com/docs/vercel-sandbox/pricing) on 2026-08-13. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - No maximum runtime. Their sandboxes are capped at 45 minutes on Hobby and 24 hours on Pro — a Cube runs until you stop it. - Any disk size you like. Every one of their plans caps a sandbox at 32 GB, on Hobby, Pro and Enterprise alike. - Full root access into a real Linux server you can also serve production traffic from, rather than an execution environment that has to hand off to something else. - Memory is billed on what you provision either way, but our vCPU is billed on the minute the machine is up rather than metered per active CPU-hour — one predictable line instead of two variable ones. - Snapshot a warm base once, then clone it into a fresh Cube per run, so every agent starts from a known-good machine. - Export any Cube as a portable .cube archive and import it again — your environment is a file you hold, not state inside one vendor's platform. 03 Answers ## Before you decide **Where do these Vercel Sandbox numbers come from?** From Vercel Sandbox's own pricing page, opened in a browser and read off it on 2026-08-13 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $9.93 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/lightsail ============================================================================== Comparison # Krova Cloud vs AWS Lightsail Amazon's simplified VPS — fixed monthly bundles. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $11.68/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 42% less than AWS Lightsail Their figure read from [their own pricing page](https://aws.amazon.com/lightsail/pricing/) on 2026-08-17 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 80 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $11.68 /mo $0.0160/hr · billed by the minute AWS Lightsail $20.00 /mo $0.0274/hr At this size Krova Cloud costs 42% less than AWS Lightsail. ### How we got there AWS Lightsail: The $20/month IPv6-only Linux bundle includes 2 vCPUs, 4 GB memory, 80 GB SSD and 4 TB transfer, billed as a flat monthly price. The otherwise identical bundle with a public IPv4 address is $24. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. AWS Lightsail's figures were read from [their own pricing page](https://aws.amazon.com/lightsail/pricing/) on 2026-08-17. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Any vCPU, RAM and disk combination you like, instead of eleven fixed bundles you have to round up to. - Its own kernel per instance in a per-cube jailer sandbox, rather than a shared-tenancy VPS. - Billed by the minute. Power a Cube off and compute billing stops the same minute, rather than paying a flat month whatever you use. - No inbound route until you open a port, so there is nothing to harden on day one. - Automatic scheduled snapshots with real retention, bundled into the plan with no per-GB snapshot charge. - Clone any snapshot straight into a new Cube, or export it as a portable .cube archive and take it with you. 03 Answers ## Before you decide **Where do these AWS Lightsail numbers come from?** From AWS Lightsail's own pricing page, opened in a browser and read off it on 2026-08-17 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $11.68 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/vultr ============================================================================== Comparison # Krova Cloud vs Vultr General-purpose cloud VMs — Cloud Compute instances. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $11.68/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 42% less than Vultr Their figure read from [their own pricing page](https://www.vultr.com/pricing/) on 2026-08-17 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 80 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $11.68 /mo $0.0160/hr · billed by the minute Vultr $20.00 /mo $0.0300/hr At this size Krova Cloud costs 42% less than Vultr. ### How we got there Vultr: Their Cloud Compute (Regular Performance) 2 vCPU / 4 GB plan with 80 GB SSD and 3 TB bandwidth is $0.03/hour, capped at $20.00/month. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Vultr's figures were read from [their own pricing page](https://www.vultr.com/pricing/) on 2026-08-17. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Its own kernel per instance in a per-cube jailer sandbox, rather than virtual machines that run atop shared vCPUs — which is how their own page describes this plan family. - Any vCPU, RAM and disk combination you like, instead of fixed plan sizes. - Billed by the minute, and powering a Cube off stops compute billing the same minute. - No inbound route until you open a port, and every port mapping is IP-allowlistable. - RAM and disk reserved 1:1 against real hardware — no overselling, no thin provisioning. - Automatic snapshots with real retention included, plus clone-to-a-new-Cube and portable .cube export. 03 Answers ## Before you decide **Where do these Vultr numbers come from?** From Vultr's own pricing page, opened in a browser and read off it on 2026-08-17 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $11.68 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/northflank ============================================================================== Comparison # Krova Cloud vs Northflank A developer platform for services, jobs and sandboxed workloads. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $10.22/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 79% less than Northflank Their figure read from [their own pricing page](https://northflank.com/pricing) on 2026-08-14 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 40 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $10.22 /mo $0.0140/hr · billed by the minute Northflank $48.66 /mo $0.0667/hr At this size Krova Cloud costs 79% less than Northflank. ### How we got there Northflank: $0.01667 per vCPU-hour and $0.00833 per GB-hour, which is exactly their published nf-compute-200 plan at $48.00/month. Disk is billed separately at $0.15 per GB per month. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Northflank's figures were read from [their own pricing page](https://northflank.com/pricing) on 2026-08-14. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Full root access into a real Linux server with its own kernel — install anything, run systemd, run Docker — rather than a container scheduled onto a shared platform. - Disk is included in the per-minute rate rather than metered separately at a per-GB-month charge on top of compute. - No session ceiling and no platform lifecycle: a Cube runs until you stop it, so one machine covers a short agent run and a service you leave up for a year. - Its own kernel in a per-cube jailer sandbox, which is the isolation boundary you actually want when the code being run is not yours. - Automatic scheduled snapshots with real retention, bundled into the plan with no per-GB snapshot charge. - Clone any snapshot straight into a new Cube, or export the whole machine as a portable .cube archive and take it elsewhere. 03 Answers ## Before you decide **Where do these Northflank numbers come from?** From Northflank's own pricing page, opened in a browser and read off it on 2026-08-14 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $10.22 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/linode ============================================================================== Comparison # Krova Cloud vs Linode Akamai Cloud's general-purpose VMs — the Shared CPU plans. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $11.68/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 51% less than Linode Their figure read from [their own pricing page](https://www.akamai.com/cloud/pricing/north-america) on 2026-08-17 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 80 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $11.68 /mo $0.0160/hr · billed by the minute Linode $24.00 /mo $0.0360/hr At this size Krova Cloud costs 51% less than Linode. ### How we got there Linode: Their Shared CPU Linode 4 GB plan is 2 CPUs, 4 GB RAM and 80 GB storage at $0.0360/hour, capped at $24.00/month. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Linode's figures were read from [their own pricing page](https://www.akamai.com/cloud/pricing/north-america) on 2026-08-17. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Any vCPU, RAM and disk combination you like, instead of a fixed ladder you have to round up to. - Its own kernel per instance in a per-cube jailer sandbox, rather than a shared-CPU plan their own page describes as running on legacy hardware. - Billed by the minute, and powering a Cube off stops compute billing the same minute rather than paying a flat month regardless. - No inbound route until you open a port, and every port mapping is IP-allowlistable. - RAM and disk reserved 1:1 against real hardware — no overselling, no thin provisioning. - Automatic snapshots with retention included, plus clone-to-a-new-Cube and portable .cube export. 03 Answers ## Before you decide **Where do these Linode numbers come from?** From Linode's own pricing page, opened in a browser and read off it on 2026-08-17 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $11.68 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/digitalocean ============================================================================== Comparison # Krova Cloud vs DigitalOcean General-purpose VPS hosting — Droplets. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $11.68/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 51% less than DigitalOcean Their figure read from [their own pricing page](https://www.digitalocean.com/pricing/droplets) on 2026-08-17 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 80 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $11.68 /mo $0.0160/hr · billed by the minute DigitalOcean $24.00 /mo $0.0357/hr At this size Krova Cloud costs 51% less than DigitalOcean. ### How we got there DigitalOcean: A Basic (Regular) Droplet with 4 GiB RAM, 2 vCPUs and 80 GiB SSD is $0.03571/hour, $24.00/month. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. DigitalOcean's figures were read from [their own pricing page](https://www.digitalocean.com/pricing/droplets) on 2026-08-17. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Roughly half the price for the same vCPU and RAM. - Its own kernel per instance in a per-cube jailer sandbox, rather than a shared-kernel neighbourhood. - Billed by the minute. Power a Cube off and compute billing stops the same minute. - Any vCPU, RAM and disk combination you like, instead of fixed plan sizes. - No inbound route until you open a port, so there is nothing to harden on day one. - Automatic scheduled snapshots with real retention, and deleting a Cube offers to keep a full backup first — so an accidental destroy is recoverable. - Clone any snapshot straight into a new Cube, optionally on a larger disk. Staging from production is one action, not a rebuild. - Export any Cube as a portable .cube archive and import it again — your data is portable out of Krova, not only inside it. 03 Answers ## Before you decide **Where do these DigitalOcean numbers come from?** From DigitalOcean's own pricing page, opened in a browser and read off it on 2026-08-17 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $11.68 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/vs/hetzner ============================================================================== Comparison # Krova Cloud vs Hetzner European VPS hosting — Cloud servers, plus two US regions. Here is the same machine priced both ways, the arithmetic that produced each number, and what a Cube gives you beyond the price. [Launch a Cube](https://krova.cloud/signup) [See Cube pricing](https://krova.cloud/pricing/cube) Cubes from $2.92/mo This machine $11.68/mo No credit card to sign up At 2 vCPU · 4 GB RAM, Krova Cloud costs 50% less than Hetzner Their figure read from [their own pricing page](https://www.hetzner.com/cloud/regular-performance/) on 2026-08-17 01 The price, checked ## The same machine, both prices Both sides priced at 2 vCPU · 4 GB RAM · 80 GB disk, running 24/7. Theirs comes from their own pricing page; ours is computed from the live rate card the product bills from. Krova Cloud $11.68 /mo $0.0160/hr · billed by the minute Hetzner $23.59 /mo $0.0378/hr At this size Krova Cloud costs 50% less than Hetzner. ### How we got there Hetzner: A CPX22 Cloud server (Regular Performance) with 4 GB RAM, 2 shared AMD vCPUs and 80 GB SSD is $0.0378/hour, capped at $23.59/month excluding VAT. Krova Cloud: $0.001/hr per vCPU, $0.0025/hr per GB RAM, $0.00005/hr per GB disk. Monthly figures are the hourly rate × 730. Hetzner's figures were read from [their own pricing page](https://www.hetzner.com/cloud/regular-performance/) on 2026-08-17. Prices change — check theirs before you decide, and tell us if this page is out of date. 02 Beyond the price ## What you get on a Cube that you don't get there Price is the headline. This is the part that decides whether you stay. - Around half the price for the same vCPU, RAM and disk — and 48% to 70% less across every Hetzner plan that was in stock on 2026-08-17. - Their Cost-Optimized range is cheaper on paper, and on 2026-08-17 every plan in it showed 'not available' on their own page. A Cube provisions in seconds, at any size. - Its own kernel per instance in a per-cube jailer sandbox, rather than a shared-kernel neighbourhood. - Billed by the minute rather than hourly, and powering a Cube off stops compute billing the same minute. - Any vCPU, RAM and disk combination you like, instead of fixed plan sizes. - No inbound route and no public IPv4 to scan — web traffic arrives through managed HTTPS, everything else only on ports you open behind an IP allowlist. - US-West capacity on our own bare metal in Los Angeles, priced the same as everything else rather than at a US premium. - Automatic scheduled snapshots with real retention, and deleting a Cube offers to keep a full backup first. - Export any Cube as a portable .cube archive and import it again — your data is portable out of Krova, not only inside it. 03 Answers ## Before you decide **Where do these Hetzner numbers come from?** From Hetzner's own pricing page, opened in a browser and read off it on 2026-08-17 — not from a blog post, a comparison site or memory. The rates and the arithmetic are printed above so you can redo the sum yourself, and a build-time guard fails once any comparison on this site passes ninety days, so a stale reading cannot sit here quietly. **Why is Krova Cloud cheaper at the same size?** You pay per resource — $0.001 per vCPU-hour, $0.0025 per GB of RAM and $0.00005 per GB of disk — instead of buying a fixed plan and rounding up to whatever it includes. There is no subscription, so what you pay for is the machine you asked for, by the minute — and every GB of RAM and disk in it is reserved 1:1 against real hardware. **What am I committing to?** Nothing monthly. There is no subscription and no minimum — you top up prepaid credit and pay for the minutes a Cube runs, and powering one off stops compute billing that same minute, with only its disk still billing. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. **What exactly is a Cube?** A Firecracker microVM with its own Linux kernel and full root access, inside a per-cube jailer sandbox — install anything, run systemd, run Docker, and leave it up as long as you like. Your app is public; your server isn't: outbound is unrestricted, so package installs, image pulls and API calls all work normally, while nothing reaches in until you map a port, and every mapping takes an IP allowlist. Custom domains run through the managed HTTPS ingress, so the origin is never exposed. ## Run the same machine for $11.68 a month No subscription and no minimum — top up prepaid credit, size a Cube however you like, and compute billing stops the minute you power it off. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See every comparison](https://krova.cloud/vs) ============================================================================== URL: https://krova.cloud/faq ============================================================================== # Questions people ask before they sign up. Everything below is answered the way we would answer it in a support ticket — including the parts that are limits rather than features. If yours is not here, [ask us](https://krova.cloud/contact). Answers ## Frequently asked questions Cubes from $2.92/mo · 1 vCPU · 1 GB · 10 GB · billed by the minute·+$5 free credit·No card to sign up [Cube pricing](https://krova.cloud/pricing/cube) [Both products](https://krova.cloud/pricing) **Do I need a credit card to get started?** 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. **Do Cubes share a kernel like containers?** 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. **How does my Cube get kernel and security updates?** 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. **Does my Cube have a public IP address?** 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. **Do I actually need a public IP?** 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. **How much bandwidth do I get? Is egress metered?** 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. **Is it protected against DDoS attacks?** 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. **How does billing work — what if I only run a Cube for 5 minutes?** 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. **Is there a subscription or monthly plan?** 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 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. **What happens when my credit runs out?** 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. **Can I point a wildcard domain at a Cube?** 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. **Can I create and manage Cubes with an API?** 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. **Which operating systems can I run on a Cube?** 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. **Can I run Docker inside a Cube?** 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. **What happens when I power off a Cube?** 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. **How is this different from AWS EC2?** 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. **Is my data safe?** 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. **How do backups and snapshots work?** 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. **Can I take my server with me if I leave?** 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. **Why not just run Firecracker or containers myself?** 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. **Why is Krova Cloud cheaper than AWS, DigitalOcean, or Linode?** 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. **Do I need to add my domain twice if I use a control panel?** 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. ### Like the answers? Check the price. Same vCPU, RAM and disk as Lightsail, DigitalOcean, Vultr & Linode — up to 69% less, billed by the minute. Or pick managed hosting from $1.50/mo. Cube — Popular $10.22/mo · 2 vCPU · 4 GB · 40 GB Nest — Start $2.00/mo · 30 GB · 2 sites Compare [See arithmetic →](https://krova.cloud/vs) [See Cube pricing](https://krova.cloud/pricing/cube) [See both products](https://krova.cloud/pricing) ## Still deciding? Launch one and see. [Launch a Cube](https://krova.cloud/signup) Claim $5 in free credit. ============================================================================== URL: https://krova.cloud/developers ============================================================================== Developers # Every Cube is one API call away. Or one prompt. Create, snapshot, restore and tear down isolated microVMs from your own code — a typed TypeScript SDK, a CLI, an MCP server for Claude and Cursor, webhook verification and an n8n node. Every one of them speaks the same v1 REST API. [Launch a Cube](https://krova.cloud/signup) [Read the API reference](https://krova.cloud/docs/api) Cubes from $2.92/mo No credit card to sign up [Every package on this page is open source on GitHub](https://github.com/krovacloud) 01 Packages ## Official packages Every package is published on npm and open source on GitHub, and every one speaks the same v1 API — so the SDK, the CLI and your agent all see the same Cube. Copy a command and start. ### TypeScript SDK A fully-typed client for the Krova Cloud API. Provision Cubes, manage domains, snapshots, and webhooks with autocomplete and end-to-end types. [Docs](https://krova.cloud/docs/sdk) [npm](https://www.npmjs.com/package/@krovacloud/sdk) [GitHub](https://github.com/krovacloud/krova-node/tree/main/packages/sdk) ### CLI Manage your Cubes from the terminal — create, power off, start, SSH in, and forward ports to in-Cube services with the krova command. Adds the krova command to your PATH. [Docs](https://krova.cloud/docs/cli) [npm](https://www.npmjs.com/package/@krovacloud/cli) [GitHub](https://github.com/krovacloud/krova-node/tree/main/packages/cli) ### MCP server Let Claude, Cursor, and any MCP-aware assistant manage your Cubes in natural language — no glue code required. Point your MCP client at this command — no install step. [Docs](https://krova.cloud/docs/mcp) [npm](https://www.npmjs.com/package/@krovacloud/mcp) [GitHub](https://github.com/krovacloud/krova-node/tree/main/packages/mcp) ### Webhook verification Verify inbound Krova Cloud webhook signatures in one call, so you can trust every event before you act on it. [Docs](https://krova.cloud/docs/webhooks) [npm](https://www.npmjs.com/package/@krovacloud/webhook) [GitHub](https://github.com/krovacloud/krova-node/tree/main/packages/webhook) ### n8n node Drag Krova Cloud into your n8n workflows — create, power off, start, and delete Cubes and manage domains and snapshots without writing code. Install as a community node from n8n Settings. [Docs](https://krova.cloud/docs/n8n) [npm](https://www.npmjs.com/package/n8n-nodes-krova) [GitHub](https://github.com/krovacloud/krova-node/tree/main/packages/n8n-node) 02 For agents ## Built to be driven by an agent A Cube is meant to be created, used and destroyed by software — yours, or a model acting on your behalf. ### Let the model provision its own machine Point any MCP client — Claude Code, Cursor, or your own — at the Krova MCP server and the assistant gets the whole lifecycle as tools: create, list, power off, restart, snapshot, restore, domains, port mappings, pricing and images. No glue code, and nothing bespoke to maintain when the model changes. ### Or drive it yourself, typed The TypeScript SDK covers the same v1 API with full types, and the CLI covers the same ground from a shell or a CI step. A machine-readable OpenAPI spec is published, so a client in another language is a generation step rather than a support ticket. ### One base image, many identical runs Set a Cube up with your toolchain, snapshot it, and clone that snapshot per run. Cloning reads straight onto the new disk with no upload or archive hop, so each run starts from a known-good machine instead of re-running an install script and hoping the registry is up. ### Know when something changed Outbound webhooks fire on lifecycle events, and the webhook package verifies the signature for you so you are not hand-rolling HMAC comparison. Scoped API keys and idempotency keys mean a retry storm cannot double-provision. 03 REST API ## Every Cube action is a plain HTTP call The same v1 API the SDK, the CLI, the MCP server and the n8n node are all built on — nothing is held back for our own clients. One scoped header and you are in. Authenticate with a scoped `X-API-KEY` header — the same one the packages above use. The full OpenAPI 3 spec is published at [/api/v1/openapi.json](https://krova.cloud/api/v1/openapi.json), so a client in a language we do not ship is a generation step — or drop it into Postman and click around. [Open the interactive API reference](https://krova.cloud/docs/api) ### Every request starts with a key Keys are created per space from your dashboard settings. Scope each one to the permissions it needs, then export it as `KROVA_KEY` for the SDK, the CLI, or a raw request. [See how keys are scoped](https://krova.cloud/docs/api-keys) Questions ## Quick answers **Is there a CLI?** Yes — the `krova` CLI lets you create, manage, and connect to Cubes, forward ports, manage domains, and stream webhooks from your terminal. Install it from npm (`npm i -g @krovacloud/cli`) or via the one-line script on this page. **Can I manage Cubes with TypeScript?** Yes — the `@krovacloud/sdk` package is a fully-typed TypeScript client for the v1 REST API. Create Cubes, manage snapshots, attach domains, open ports, and more — all with full type safety and autocomplete. **Is there an MCP server?** Yes — the Krova MCP server lets Claude, Cursor, and any MCP client manage your Cubes in natural language. You can ask an agent to create a Cube, snapshot it, open a port, or check billing — all through conversation. **Can I use this with n8n?** Yes — Krova ships an n8n node that provisions Cubes, powers them on and off, takes snapshots, and deletes them — all as workflow steps with no code. **How do I auth API requests?** Every request is authenticated with a scoped API key sent in the `X-API-KEY` header. Keys are created per space from your dashboard settings, and each one can be scoped to specific permissions. The full OpenAPI 3 spec is published at /api/v1/openapi.json. ## Ship your first Cube from code Create a scoped key, install the SDK, and provision an isolated microVM in a few lines. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [Read the docs](https://krova.cloud/docs/getting-started) ============================================================================== URL: https://krova.cloud/research/pricing-methodology ============================================================================== # How we calculate our pricing claims Last updated: 2 August 2026 Krova Cloud says its Cubes cost up to 69% less than an equivalent instance from AWS Lightsail, DigitalOcean, Vultr or Linode, and less than half the price on every comparable size. This page is the working behind those two sentences: the rate card, the arithmetic, the competitor prices we measured against, the dates we checked them, and — importantly — what the comparison leaves out. Everything below is generated from the same pricing module the [pricing page](https://krova.cloud/pricing) and the billing engine use, so it cannot drift from what you are actually charged. **On this page** 1. 1. The rate card 2. 2. The arithmetic 3. 3. Volume tiers 4. 4. The comparison 5. 5. What this comparison excludes 6. 6. Reproducing this yourself ## 1. The rate card A Cube is billed per resource, per hour, and metered by the minute. There is no instance type and no plan: you pick vCPU, RAM and disk independently and pay for what those come to. - **$0.001** per vCPU, per hour - **$0.0025** per GB of RAM, per hour - **$0.00005** per GB of disk, per hour RAM and disk are reserved 1:1 — there is no overselling and no thin provisioning, so the GB you are billed for is a GB that exists on the host. Powering a Cube off stops the vCPU and RAM charges immediately; the disk keeps billing at the same per-GB rate, because it is still occupying real storage. ## 2. The arithmetic The hourly cost of a Cube is: ``` hourly = ((vcpu × 0.001) + (ramGb × 0.0025) + (diskGb × 0.00005)) × tierMultiplier ``` Monthly figures on this site are `hourly × 730` — 730 hours being the average month (8,760 hours ÷ 12). We use 730 rather than 720 or 744 so a monthly quote is neither flattering nor pessimistic depending on which month you read it in. Because billing is per-minute and usage-based, a monthly figure is an *illustration of a Cube left running 24/7*, never a subscription you are committed to. ## 3. Volume tiers Larger Cubes get a lower effective rate through a multiplier applied to the whole hourly cost. The tiers are: | vCPU range | Multiplier | Effective discount | | --- | --- | --- | | 1–2 vCPU | 1× | 0% off | | 3–4 vCPU | 0.95× | 5% off | | 5–8 vCPU | 0.85× | 15% off | | 9+ vCPU | 0.8× | 20% off | ## 4. The comparison Competitor prices were researched on 31 May 2026 and re-checked on 2 August 2026 against the live vendor pricing pages. For each size we take the cheapest plan from the named providers that meets or exceeds the same vCPU, RAM and disk, and compare it with what the formula above produces for the identical specification. | Specification | Krova Cloud/mo | Lightsail/mo | Cheapest/mo | Saving | | --- | --- | --- | --- | --- | | 2 vCPU · 4 GB RAM · 80 GB disk | $11.68 | $20.00 | $24.00 | 51% | | 4 vCPU · 8 GB RAM · 100 GB disk | $20.15 | $40.00 | $48.00 | 58% | | 8 vCPU · 16 GB RAM · 100 GB disk | $32.92 | $80.00 | $96.00 | 66% | | 16 vCPU · 32 GB RAM · 100 GB disk | $58.98 | $160.00 | $192.00 | 69% | The headline “up to 69%” is the largest value in the final column — `Math.max` over the rows above, not a figure chosen for effect. The smallest is 51%, which is the honest floor of the same set and the reason the other claim is worded “less than half” rather than “69% cheaper”. ## 5. What this comparison excludes A price comparison is only useful if you know what it does not cover. This one deliberately excludes: - **Bandwidth and egress.** Every provider prices transfer differently, and a Cube's allowance is not represented in the table above. A workload that moves a lot of data may compare differently. - **Committed-use and annual discounts.** The competitor prices are list, on-demand, monthly. Several providers discount for annual prepayment; Krova Cloud has no commitment to discount, because there is no subscription. - **Free tiers and promotional credit.** Introductory credit distorts the first months of any comparison, so none is counted on either side. - **Regional price variation.** Competitor pricing can differ by region; we compare against their published US pricing. - **Features that are not like-for-like.** Every competitor instance in this table comes with a public IPv4 address, which a Cube deliberately does not have. That is a genuine architectural difference, not a cost saving we are claiming credit for — see [how isolation works](https://krova.cloud/security). If you find a size where this arithmetic does not hold, or a competitor price that has moved since we last checked, please tell us — the numbers above are generated, so correcting the source corrects every page that quotes it. ## 6. Reproducing this yourself You do not have to take the table on trust. The live rates are served from the public API and need no authentication: ``` curl https://krova.cloud/api/v1/pricing ``` Apply the formula in section 2 to any specification and you will get the same figure the [pricing page](https://krova.cloud/pricing) quotes and the same figure you are billed. The competitor prices are the vendors' own published list prices on the dates given above. ============================================================================== URL: https://krova.cloud/customers ============================================================================== Customers # Proof you can check in one click A Cube runs whatever a Linux server runs — multi-tenant platforms, AI agents, everyday apps. Rather than tell you who trusts us, here is what you can verify for yourself. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 On the record ## Proof you can check yourself We would rather hand you a number you can check in one click than a story you have to take on trust. So here is what is on the record today. Installs of our packages, last 30 days 4,703 Across 5 public packages, counted by npm rather than by us — [check it yourself](https://www.npmjs.com/org/krovacloud). These are installs, which include CI and mirrors — not a user count. Running hosting infrastructure since 2019 7 years of it, starting as a shared-hosting business. [How we got here](https://krova.cloud/about). Already running something on Krova Cloud? We would rather publish your numbers than our adjectives — [tell us what you built](https://krova.cloud/contact) and we will write it up. ## Your story next Put something real on a Cube and see whether it holds up. That is the only proof that counts — and if it does, we would like to write it down. [Launch a Cube](https://krova.cloud/signup) [Tell us what you built](https://krova.cloud/contact) ============================================================================== URL: https://krova.cloud/about ============================================================================== About # Running hosting infrastructure since 2019 We started in April 2019 keeping other people's websites online, and spent those years learning exactly how shared hosting fails. Krova Cloud is what we built with the answer: every workload gets its own kernel, on our own hypervisor, on bare-metal servers we run in Los Angeles — not resold from a hyperscaler. [Launch a Cube](https://krova.cloud/signup) [Explore the Cube](https://krova.cloud/cube) Cubes from $2.92/mo No credit card to sign up 01 Principles ## What we believe A short list of principles we don't bend on — they shape every part of the product. ### Isolation by default Every Cube boots its own Linux kernel inside a per-cube jailer sandbox — never the shared kernel a container hands every tenant on the box. A kernel bug in one Cube cannot reach another. Isolation is not an upgrade you buy here; it is the floor. ### No surprises Per-minute billing, RAM and disk reserved 1:1 with the host so nothing is oversold, and the whole price list is public before you sign up. Power a Cube off and compute billing stops instantly. No egress traps, no fine print. ### Developer-first A typed TypeScript SDK, a CLI, an MCP server for Claude and Cursor, webhook verification and a public REST API — published on npm and open-source on GitHub. If you can script it, you can run a fleet of Cubes from it. ### Honest simplicity Simple, not simplistic. We describe the product in plain terms, keep the dashboard uncluttered, and ship sensible defaults — so the easy path is also the right one. 02 The product ## What we're building Firecracker gives you the isolation of a virtual machine at the speed of a container. Everything wrapped around it is the part we build. On its own, Firecracker is just a hypervisor. Krova Cloud is the platform on top: provisioning in one click or one API call, per-minute billing, custom domains with automatic HTTPS, snapshots, and team access — VM-grade isolation without running the hypervisor yourself. We build the whole experience around the Cube — the dashboard, the SDK and CLI, the docs, and the billing — so starting an isolated environment feels as light as starting a container while giving you a real machine with its own kernel underneath. That is the product, and it is the only thing we work on. [See what a Cube can do →](https://krova.cloud/cube) 03 Since 2019 ## We did not start in 2026 Krova Cloud is the second version of a hosting business we have been running since April 2019. The first one taught us exactly what to fix. We began as Hosting Gujju, a shared-hosting business — the same job, a much smaller version of it. We spent those years doing the unglamorous part: keeping other people's websites up, answering tickets at inconvenient hours, and learning exactly how shared hosting fails. Krova Cloud is what we built once we understood the real problem. Shared hosting puts every customer on one shared kernel and hopes. A Cube gives every workload its own. 04 Where it runs ## Our own hypervisor, on bare metal in Los Angeles We are not reselling someone else's cloud. The hypervisor, the networking, the firewalling and the HTTPS ingress are all ours. Location Los Angeles, United States Hardware Dedicated bare-metal servers we rent from Dedicated.com — not a slice of someone else's cloud. The stack Hypervisor, networking, firewalling and HTTPS ingress: all built and operated by us. The company Krova Inc., a Delaware corporation. That is also why the pricing works. There is no hyperscaler margin stacked underneath us. Every vendor that touches your data is named on our [subprocessors page](https://krova.cloud/subprocessors), and how we secure the platform is written up on our [security page](https://krova.cloud/security). ## Launch your first Cube Signing up is free. Size a Cube, SSH in — the whole thing takes under a minute — Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See what a Cube costs](https://krova.cloud/pricing/cube) ============================================================================== URL: https://krova.cloud/contact ============================================================================== Contact # Talk to us. Straight to the right inbox. Sizing a larger workload, stuck on a running Cube, or working out whether Krova Cloud fits what you're building — here is the fastest route to an answer. [Email support](https://krova.cloud/cdn-cgi/l/email-protection#88fbfdf8f8e7fafcc8e3fae7fee9a6ebe4e7fdec) or find the right inbox → No sales call needed — Cubes from $2.92/mo No credit card to sign up 01 Where to write ## Pick the route that fits Each of these lands somewhere different, and picking the right one saves a round trip. Some reach a mailbox; the rest answer the question outright, with nothing to wait for. ### Sales & larger workloads Planning a fleet of Cubes, one much bigger machine, or something with specific requirements? Send the shape and the workload and we will help you size it. [Email the team](https://krova.cloud/cdn-cgi/l/email-protection#05767075756a7771456e776a73642b66696a70613a7670676f606671385664696076203735606b74706c777c) ### Product support Account questions, billing, or something misbehaving on a running Cube. The support inbox goes straight to the team that operates the platform. [Email support](https://krova.cloud/cdn-cgi/l/email-protection#5d2e282d2d322f291d362f322b3c733e31322839) ### Security & disclosure See exactly how per-cube isolation works, or report something you have found. Vulnerability reports go to the support inbox — the same address our security.txt publishes. [Read the security page](https://krova.cloud/security) ### Developers & the API Building on the API? The SDK, CLI, MCP server and REST API are documented and open-source — most integration questions are answered there before an email is needed. [Explore developer tools](https://krova.cloud/developers) Abuse, spam, phishing or copyright complaints about something we host have their own intake at [report abuse](https://krova.cloud/report-abuse), and formal legal notices go to [\[email protected\]](https://krova.cloud/cdn-cgi/l/email-protection#9df1f8fafcf1ddf6eff2ebfcb3fef1f2e8f9). 02 What to include ## Before you write Most of what arrives has a faster answer elsewhere — and the rest gets one sooner when the first message carries the right detail. ### Sizing something larger Tiers lift automatically as you spend, so most people never need to ask. If you need headroom sooner — one much bigger Cube, or many at once — tell us the shape and the workload and we will review it. Limits are set per space, so we can raise yours without you changing plan or moving anything. ### Checking it fits before you commit You do not need to talk to anyone to try it. Signing up is free, and the platform is self-serve from there. If you would rather sanity-check an architecture first, send the shape of what you are building and we will tell you plainly whether a Cube is the right substrate — including when it is not. ### Reporting a security issue Send it to the support inbox — that is the address published in our /.well-known/security.txt per RFC 9116, and it reaches a real mailbox. Include enough detail to reproduce. We do not run a paid bounty, and we would rather say so than have you find out after the fact. ### Something broken right now Check the status page first — it is an external uptime monitor, so it is not us marking our own homework. If it is not platform-wide, support is the fastest route: include the Cube name or ID and roughly when it started, because the lifecycle log for that Cube is the first thing we read and a time window narrows it immediately. 03 Self-serve ## Faster than an email thread The places that answer most of what reaches the inbox, with nothing to wait for. ### Documentation Setup, the API, snapshots, custom domains and billing. Most of what reaches the inbox is already written down here. [Read the docs](https://krova.cloud/docs) ### Platform status Uptime and incident history, published by an external monitor rather than by us — so it is not us marking our own homework. [Check platform status](https://stats.uptimerobot.com/dfhNkatAcT) ### Community Discord Swap tips, ask questions and follow what is shipping, alongside other people running Cubes. [Join the Discord](https://discord.gg/GgGz4AjJ6B) Pricing is published in full rather than quoted on request — every rate, tier and limit is on the [pricing page](https://krova.cloud/pricing), so you can work out the cost of your own workload without emailing anyone. ## Or skip the email and run one The quickest way to find out whether Krova Cloud fits is to launch a Cube and look at it. Signing up is free. Claim $5 in free credit — one-time, per account, and nothing is charged for it. [Launch a Cube](https://krova.cloud/signup) [See what it costs](https://krova.cloud/pricing) ============================================================================== URL: https://krova.cloud/docs ============================================================================== # Krova Cloud documentation Everything you need to launch and manage lightweight cloud servers (Cubes) on Krova Cloud — step-by-step guides plus a full, interactive REST API reference. ## Get started ### Getting started Create a space, add credit, and launch your first Cube in a few minutes. Link: https://krova.cloud/docs/getting-started ## Guides ### Cubes Create, size, connect to, and manage Cubes — and how power-off billing works. Link: https://krova.cloud/docs/cubes ### Custom domains Point your own domain at a Cube with automatic HTTPS, add a wildcard domain (*.example.com) for every subdomain at once, tune per-domain proxy settings, and use Cloudflare — set SSL/TLS to Full to avoid a redirect loop or a 526. Link: https://krova.cloud/docs/custom-domains ### Nest Managed shared web hosting — WordPress, email, SSL, and backups via a control panel, on a monthly or yearly plan paid from the same credit balance as Cubes. Link: https://krova.cloud/docs/nest ### API keys Create scoped API keys and drive everything programmatically over the REST API. Link: https://krova.cloud/docs/api-keys ## How-to ### Deploy PostgreSQL Install PostgreSQL 16 on a Cube, create a database and user, then connect two ways — an SSH tunnel while you develop, and an IP-allow-listed TCP port mapping for a deployed app. Link: https://krova.cloud/docs/how-to/postgres ### Run a Node.js app Run a Node.js app on a Cube as a systemd service that survives reboots, and serve it on your own domain over HTTPS. Link: https://krova.cloud/docs/how-to/nodejs ### Install Dokploy Run a self-hosted PaaS on a Cube — Docker Swarm, Traefik and automatic TLS — including why the URL the installer prints does not work on a Cube. Link: https://krova.cloud/docs/how-to/dokploy ### Deploy an app with Dokploy Deploy an app through Dokploy and give it a domain — the HTTPS switch to leave off, and the port the Krova mapping has to use. Link: https://krova.cloud/docs/how-to/dokploy-deploy ### GitHub Actions runner Self-host a GitHub Actions runner on a Cube as a systemd service — outbound-only with no published ports, and the three steps whose error messages do not describe the actual problem. Link: https://krova.cloud/docs/how-to/github-actions-runner ### Snapshot and restore Snapshot a Cube, restore it when something goes wrong, and know when you need a Backup instead — the copy that outlives the Cube. Link: https://krova.cloud/docs/how-to/snapshots ### Back up and bring back Create a Backup that outlives a Cube, redeploy an identical Cube from it, and move a Cube between spaces with its .cube archive. Link: https://krova.cloud/docs/how-to/backup-restore ### Manage Cubes from Claude Connect Krova to Claude, Cursor or any MCP client so you can manage Cubes in conversation — including the environment variable beyond the API key. Link: https://krova.cloud/docs/how-to/mcp-claude ## Reference ### TypeScript SDK The fully-typed @krovacloud/sdk client — provision and manage Cubes, the catalog, and every API operation from Node.js. Link: https://krova.cloud/docs/sdk ### CLI Install and use the krova CLI — authenticate, manage Cubes, SSH in, forward ports, and stream webhooks. Link: https://krova.cloud/docs/cli ### MCP server Let Claude, Cursor, and any MCP client manage your Cubes in natural language via @krovacloud/mcp. Link: https://krova.cloud/docs/mcp ### Webhooks Receive and verify Krova Cloud webhook events with @krovacloud/webhook — HMAC-SHA256, replay protection, any framework. Link: https://krova.cloud/docs/webhooks ### n8n node Drag Krova Cloud into your n8n workflows — provision, power off, start, and delete Cubes with no code. Link: https://krova.cloud/docs/n8n ### REST API Interactive OpenAPI reference for the v1 REST API — try requests right in the browser. Link: https://krova.cloud/docs/api ============================================================================== URL: https://krova.cloud/docs/getting-started ============================================================================== # Getting started Create a space, add credit, and launch your first Cube on Krova Cloud in a few minutes. Krova Cloud lets you run lightweight cloud servers — called **Cubes** — on dedicated cloud infrastructure. Each Cube is a fast, isolated virtual machine you get full root access to. This guide takes you from zero to a running Cube you can SSH into. ## 1. Create your account Sign up with a magic link (email) or with Google. There's nothing to install — everything is managed from the dashboard. ## 2. Choose a space Every Cube lives in a **space**. You get a personal space automatically, and you can create **team spaces** to share Cubes, billing, and members with others. Billing, credit, and limits all apply per space. ## 3. Add credit Krova Cloud is prepaid, pay-as-you-go: you load credit and it's consumed for the compute and storage you use — rates are quoted per hour, but usage is billed by the minute. Top up from **Billing** with a card (one-time, via Stripe Checkout). Activating your account credits you $5 to start (one-time, per account) and unlocks the Welcome tier automatically — nothing is charged for it. Later spaces open on the Welcome tier straight away; the credit is not repeated. You can also turn on **auto-recharge** so a running workload never stops for a brief shortfall. If a space's balance hits zero, its Cubes automatically **power off** (no data loss) and can be started again once you top up. ## 4. Launch your first Cube From your space dashboard, create a Cube and pick: - **Size** — vCPUs, RAM, and disk. You can resize later. - **Image** — the OS/distribution to boot (Ubuntu 24.04 or Debian 13, each with an optional Docker-preinstalled flavor). - **SSH key** — your public key, added to the Cube at boot so you can log in. Cube boots in seconds. Its live status, metrics, and connection details appear on the Cube's page. ## 5. Connect over SSH Each Cube exposes an SSH endpoint (host and port) shown on its page. Connect with the key you added: ``` ssh -p ubuntu@ ``` You log in as `ubuntu` (or `debian` on a Debian image). Run `sudo su` for a root shell — no password needed. Cubes created before August 2026 log in as `root` instead and are unchanged; the Connect tab on each Cube always shows the exact command for that Cube. Either way you have a full Linux server with root access. Install whatever you need — Docker, a database, a web app — just like any VPS. ## Next steps - [Cubes](https://krova.cloud/docs/cubes) — sizing, power off/start, and how billing works. - [Custom domains](https://krova.cloud/docs/custom-domains) — put your own domain in front of a Cube with automatic HTTPS. - [API keys](https://krova.cloud/docs/api-keys) — automate everything over the REST API. ============================================================================== URL: https://krova.cloud/docs/cubes ============================================================================== # Cubes Create, size, connect to, and manage Cubes — and understand how running and power-off billing works. A **Cube** is a lightweight virtual machine running on dedicated cloud infrastructure. You get full root access and a real Linux environment — run Docker, databases, web apps, build agents, anything you would on a VPS. ## Creating a Cube Create a Cube from your space dashboard. You choose: - **vCPUs, RAM, and disk** — the resources allocated to the Cube. RAM and disk are dedicated (not oversold). - **Image** — the operating system to boot. Ubuntu 24.04 or Debian 13, each available plain or with Docker Engine preinstalled. - **SSH key** — your public key, written to the Cube at boot. Cube provisions and boots in seconds. Available sizes and the per-hour cost are shown in the create form so you always know what you'll pay. ## Connecting Every Cube has an SSH endpoint shown on its page. Connect with the key you added at creation: ``` ssh -p ubuntu@ ``` The login user is `ubuntu` on Ubuntu images and `debian` on Debian images. It has passwordless `sudo`, so `sudo su` gives you a root shell. Root SSH login is disabled. Cubes created before August 2026 log in as `root` and keep working exactly as they did. To expose other services, add **TCP port mappings**from the Cube's networking tab — each maps a public host port to a port inside the Cube, with an optional IP allow-list. For HTTP/HTTPS apps, a [custom domain](https://krova.cloud/docs/custom-domains) is usually the better fit. ## Resizing You can change a Cube's vCPU and RAM, and grow its disk, after creation. Resizing applies the new resources to the running Cube; metered billing simply continues at the new size. ## Power off & start Cubes have two main states beyond running: - **Stopped** — the Cube is powered off but its disk is preserved. You can power a Cube off manually, and a space whose balance reaches zero has its Cubes automatically powered off (no data loss). - **Running** — start a stopped Cube any time (top up first if the balance is zero) and it starts back up from its saved disk. ## Restart **Restarting** a Cube is a *cold* restart: the hypervisor process is stopped and relaunched, so the Cube boots against the host's current kernel. Your disk is preserved — only the kernel changes. This is the **only** way a Cube picks up a refreshed guest kernel after a platform update. A `reboot` issued *inside* the Cube cannot do it: the kernel is supplied by the host, not from your disk, so an in-Cube reboot brings the same kernel back with no error to tell you so. ``` krova cubes restart my-api ``` Cube must be running (a stopped Cube already picks up the latest kernel when you start it). Restarting briefly interrupts service, and a second restart while one is still in flight is rejected rather than queued twice. ## How billing works Billing is prepaid, charged against your space's credit. Rates are quoted per hour, but usage is metered and billed by the minute — no rounding up to the hour: - A **running** Cube is billed for its compute (vCPU + RAM) and its disk. - A **stopped** Cube is billed only for its disk storage — much cheaper than running, so powering off is the right way to pause a workload you want to keep. - Unexpected shutdowns (a crash, an in-guest `shutdown`, a host reboot) are never charged compute for the partial hour — you only pay for time the Cube actually ran. ## Snapshots & backups Cubes can be snapshotted and backed up to off-host object storage, and restored, cloned, or redeployed from those copies. Automatic snapshot cadence and retention depend on your tier; you can also take manual snapshots and pin the ones you want to keep. ## Next steps - [Custom domains](https://krova.cloud/docs/custom-domains) — serve a Cube on your own domain over HTTPS. - [API keys](https://krova.cloud/docs/api-keys) and the [REST API](https://krova.cloud/docs/api) — create and manage Cubes programmatically. ============================================================================== URL: https://krova.cloud/docs/custom-domains ============================================================================== # Custom domains Point your own domain at a Cube with automatic HTTPS, and tune per-domain proxy settings. Map a domain you own to a port on a Cube. Krova Cloud runs a reverse proxy in front of your Cube that terminates HTTPS, forwards requests to your app, and passes through the real visitor information your app needs. ## Add a domain 1. Point your domain at Krova Cloud by adding a **CNAME** record to `dns.krova.cloud`. 2. In your Cube's networking tab, add the domain and the **port** your app listens on inside the Cube. 3. HTTPS is provisioned and renewed automatically — there are no certificates to manage. If your DNS is on Cloudflare, both modes work: **DNS-only** (grey cloud — Krova Cloud issues the certificate) or **Proxied** (orange cloud — Cloudflare's edge sits in front). If you use the orange cloud, you must set Cloudflare's SSL/TLS mode to **Full** — see [Using Cloudflare](https://krova.cloud/docs/custom-domains#cloudflare). ## Wildcard domains Add ***.example.com** once and every subdomain routes to your Cube — no separate mapping per subdomain. This is the right choice when your app creates subdomains itself, for example one per customer. A wildcard covers **one level** of subdomain: **app.example.com** and **api.example.com**, but **not example.com** itself and **not a.b.example.com**. That is a rule of the certificate standard, not a Krova Cloud limit — add the root domain or a deeper name as its own domain if you need it. Every subdomain shares one Cube, one port and one set of settings, because they are all one mapping. If a specific subdomain needs different settings, add it as a separate domain — an exact match always wins over the wildcard. Three DNS records, all added once and never changed again: 1. **TXT** `_krova-verify.example.com` — proves the domain is yours. A wildcard covers every subdomain, so we verify ownership before creating one. 2. **CNAME** `*.example.com` → your ingress target — routes the traffic. 3. **CNAME** `_acme-challenge.example.com` → the target shown on the domain — lets us issue and renew the HTTPS certificate. **The third record trips people up, twice.** First, your own `*` record does *not* cover it — DNS wildcards match at any depth, so without an explicit record your wildcard answers `_acme-challenge` with something that has no certificate information in it. Second, on Cloudflare it must be **DNS only** (grey cloud); a proxied record returns Cloudflare's own addresses and the certificate authority finds nothing. Wildcard domains are available on **every plan**, with no cap on the number of subdomains they serve. ## Using Cloudflare If your domain is **proxied** through Cloudflare (the **orange cloud** in your DNS records), Cloudflare's SSL/TLS encryption mode must be set to **Full**. This is the single most common cause of a custom domain not working behind Cloudflare. In your Cloudflare dashboard, for the zone holding your domain: 1. Go to **SSL/TLS** → **Overview**. 2. Set the encryption mode to **Full**. The setting is per-zone, so it applies to every proxied record in that domain — not just the one pointing at your Cube. ### Why Full, and not the other modes - **Flexible** — Cloudflare fetches your origin over plain **HTTP**. Krova Cloud always redirects HTTP to HTTPS, so Cloudflare receives that redirect and passes it to the browser; the browser retries over HTTPS, Cloudflare fetches the origin over plain HTTP again, and the request bounces forever. The browser gives up with `ERR_TOO_MANY_REDIRECTS`. - **Full** — Cloudflare connects to your origin over HTTPS without validating the origin's certificate. This is what Krova Cloud requires, and it works from the moment you add the domain. - **Full (strict)** — Cloudflare connects over HTTPS *and* validates the origin certificate against a public CA. A proxied domain is served an internal, self-signed origin certificate so that it works instantly, and a self-signed certificate is exactly what Full (strict) rejects — so Cloudflare returns **error 526** instead of your site. **Cloudflare's own documentation often advises "Full or higher" — do not follow that advice here.** "Higher" means Full (strict), which breaks proxied Krova Cloud domains with a 526. Choose **Full**, specifically. If your domain is **DNS-only** (the grey cloud), Cloudflare is not in the request path at all and none of this applies — there is no SSL/TLS mode to change, and Krova Cloud issues a real Let's Encrypt certificate for the domain. ### Troubleshooting - **`ERR_TOO_MANY_REDIRECTS`, "too many redirects", or a redirect loop** — your SSL/TLS mode is almost certainly **Flexible**. Set **SSL/TLS** → **Overview** → **Full**, then reload. Cloudflare caches redirects, so also purge the cache or test in a private window if the loop persists. - **Cloudflare 526** ("Invalid SSL certificate") — your SSL/TLS mode is **Full (strict)**. Change it to **Full**. Do not try to fix this by installing a certificate on the origin; the origin certificate is managed by Krova Cloud and is not something you can replace. - **The domain works on grey cloud but breaks when you turn the orange cloud on** — this is the same SSL/TLS mode issue. Set the mode to **Full** before switching the record to Proxied. Krova Cloud does not detect your SSL/TLS mode — it lives in your Cloudflare zone, not ours. Set it to **Full** before you point an orange-cloud domain at us and neither failure can happen. If a domain is already looping, change the mode to **Full**, then purge your Cloudflare cache: Cloudflare can keep serving a cached redirect from before the fix. ## Real visitor information Your app receives the real client details on every request, so logging, rate-limiting, and geolocation work as expected: - `X-Real-IP` and `X-Forwarded-For` — the real visitor IP (spoof-safe; not the proxy's address). - `X-Forwarded-Proto` and `X-Forwarded-Host` — the original scheme and hostname. ## Per-domain settings Each domain has its own independent proxy configuration — changing one domain never affects another. You can tune all of these from the domain's settings (and over the [REST API](https://krova.cloud/docs/api), at create time or any time after): - **Security headers** — let Krova Cloud enforce platform security headers, or pass your app's own through. - **Request & response header overrides** — inject or remove headers to/from your app. - **Max request body size** — cap upload sizes (or leave blank for no cap). - **Response compression** — optional gzip/zstd at the edge (off by default; most CDN-fronted domains are already compressed). - **IP allow / deny lists** — restrict who can reach the app by IP or CIDR (IPv4 and IPv6). - **Basic Auth** — put a username/password in front of the domain (the password is hashed and never stored in plaintext). - **Connect over HTTPS** — speak HTTPS rather than plain HTTP on the internal hop to your Cube. Leave this off unless something inside your Cube insists on HTTPS; see [When your Cube terminates TLS itself](https://krova.cloud/docs/custom-domains#origin-https). See the [REST API reference](https://krova.cloud/docs/api) for the exact field names, types, and an example that sets these in one request. ## Uploads & CORS ### Upload size limits Krova Cloud does not cap upload sizes by default — your app receives every byte you send. If an upload returns a **413 Request Entity Too Large**, the limit is almost always inside your Cube, not at the Krova Cloud proxy: - **nginx** — raise `client_max_body_size` in your nginx config (e.g. `client_max_body_size 500m;`). - **PHP** — raise `post_max_size` and `upload_max_filesize` in `php.ini`. - **Framework body parsers** — check your framework's body-size limit (Express `limit`, Next.js `bodyParser.sizeLimit`, Django `DATA_UPLOAD_MAX_MEMORY_SIZE`, etc.). If you want Krova Cloud to enforce a hard cap at the proxy (to reject over-size requests before they reach your app), set **Max request body** in the domain's settings. When a request declares its size in `Content-Length`, the proxy returns 413 cleanly before forwarding. Chunked uploads without a `Content-Length` header that exceed the cap may in rare cases return a 502 instead of 413 — this is a known Caddy limitation. ### CORS If a cross-origin frontend (e.g. a separate SPA on `app.example.com` calling an API at `api.example.com`) is being blocked by the browser, enable **CORS** in the domain's settings. Krova Cloud handles the entire CORS protocol at the proxy — your app never needs to touch `Access-Control-*` headers: - Preflight `OPTIONS` requests are answered at the edge (your app never sees them). - `Access-Control-Allow-Origin` is added to every response, including error responses (413, 403) and upstream-down interstitials, so cross-origin callers always get a parseable error. - Use the **wildcard** (`*`) for a public API that any origin may call. Use an **explicit origin list** (e.g. `https://app.example.com`) when you need cookies or `Authorization` headers (credentials). - The **preflight cache** (`Access-Control-Max-Age`) defaults to 600 s and can be set up to 86 400 s (Chromium's hard cap), reducing the number of preflight round-trips. ## Removing a domain Removing a domain takes down its route immediately. Update your DNS afterwards if you're pointing the domain somewhere else. ## HTTPS is handled at the edge Krova terminates TLS at its edge and forwards requests to your Cube as plain HTTP. Nothing about this is a compromise, and nothing about it leaves your traffic unencrypted: the hop from Krova's edge to your Cube stays entirely inside Krova's own infrastructure — over an internal-CA mutually authenticated connection to the host, then a private bridge into the Cube. Nothing crosses the public internet unencrypted at any point. Services running inside a Cube should therefore listen on **plain HTTP**, not HTTPS. Inbound traffic reaches your Cube through Krova's edge rather than directly, so a certificate requested from inside the Cube can never be validated by a public CA — there is nothing for a validator to connect to. And if the in-cube proxy redirects port 80 to HTTPS anyway, the browser is sent to https://, Krova terminates that at the edge and forwards plain HTTP again, the panel redirects again, and the request loops forever. If the software inside your Cube cannot be told to stop redirecting — CloudPanel, typically — you do not have to fight it. See [When your Cube terminates TLS itself](https://krova.cloud/docs/custom-domains#origin-https). If you run **Dokploy** for a domain that Krova fronts, set **Certificate: None** for that domain in Dokploy. Krova is already handling the certificate at the edge; a certificate configured in the panel only causes the redirect loop above. ### When your Cube terminates TLS itself Some control panels hold their own certificate and cannot be told to stop — CloudPanel is the common one. Those Cubes answer plain HTTP with a redirect to HTTPS, which is exactly the loop described above. For them, turn on **Connect over HTTPS** in the domain's settings: Krova then speaks HTTPS on the internal hop instead of plain HTTP, the panel is satisfied, and the loop stops. Turning it on is safe to try. Krova applies the change, then fetches the domain *through the live route* to confirm it really serves — and puts the domain straight back on plain HTTP if it does not. A Cube that cannot serve HTTPS internally ends up exactly where it started rather than offline. This is not a security setting, and turning it on does not make your traffic more private: the internal hop was never exposed to begin with (see above). It exists only to satisfy software inside the Cube that refuses to answer over cleartext. If your app is happy on plain HTTP — which almost every app is — leave this off. It is settable when you attach a domain and changeable at any time afterwards, from the domain's settings, the [REST API](https://krova.cloud/docs/api) (`originScheme`), the [CLI](https://krova.cloud/docs/cli), the [SDK](https://krova.cloud/docs/sdk), [MCP](https://krova.cloud/docs/mcp), or [n8n](https://krova.cloud/docs/n8n). ============================================================================== URL: https://krova.cloud/docs/nest ============================================================================== # Nest What Nest is, how its monthly or yearly subscription is paid from your credit balance, and how to open the control panel from your dashboard. **Nest** is managed, cPanel-style shared web hosting — the second product line alongside Cubes. Instead of a root VM, a Nest gives you a hosting account on a managed **control panel**: one-click WordPress installs, email mailboxes, automatic SSL, and automated backups, without touching a terminal. Pick [a Cube](https://krova.cloud/docs/cubes) when you want full root and any stack; pick Nest when you want a familiar, point-and-click hosting panel for WordPress or everyday sites. ## What you get - **Websites** — WordPress (one-click install and management), static sites, and PHP apps. - **Email** — mailboxes on your own domain, reachable from webmail or any mail client. - **SSL** — every domain gets a TLS certificate issued and renewed automatically; sites are served over HTTPS from the moment they go live. - **Backups** — scheduled backups with restore points you can roll back to from the panel. - **Databases** — MySQL databases, created in one click. - **Migration** — bring an existing site, database, and email over from your current cPanel host. ## How billing works Nest is a **subscription**, which is the main way it differs from a Cube. You choose a plan and a term — **monthly or yearly** — and it renews automatically on the same calendar date each period until you cancel. A yearly term is **10% off** twelve months at the monthly rate, and it renews at that same discounted rate; it is not an introductory offer. Each charge is drawn from the **same prepaid credit balance** your space already uses for Cubes. Your saved card is charged *only* for the shortfall your balance doesn't cover — if the balance covers the full amount, your card isn't touched at all, and you don't need a saved card to subscribe. Your account must be **verified and approved** before you can buy a Nest plan. You can **cancel any time** from your dashboard. Cancellation takes effect at the end of the period you have already paid for — your sites keep running until then and no further renewal is charged. Cancelling does not refund the unused part of the current period, and you can undo a scheduled cancellation before it takes effect. If a renewal charge can't be covered, we retry on an escalating schedule and email you. If it still can't be paid, your Nest is **suspended** — the panel and your sites become unreachable, but nothing is deleted at that point. You then have a **14-day recovery window**: add credit (or reactivate from the dashboard) and everything comes back. If that window passes without payment, the hosting account and its data are deleted. ## Using Nest Once a Nest is set up for your space, find it under **Nest** in your space's dashboard sidebar. The Nest page lists your hosting account — plan, status, primary domain, and price — and gives you a single action: - **Open panel** — signs you straight into the control panel (no separate login to remember) so you can manage websites, email, DNS, backups, and everything else for that hosting account. All day-to-day site management — installing WordPress, creating mailboxes, adding domains, restoring a backup — happens inside the control panel itself; Krova handles provisioning, billing, and suspend/reactivate around it. ## Next steps - [Nest plans](https://krova.cloud/nest) — compare plans and pricing. - [Cubes](https://krova.cloud/docs/cubes) — the other product line, for full root access on your own isolated microVM. - [Getting started](https://krova.cloud/docs/getting-started) — create a space and add credit. ============================================================================== URL: https://krova.cloud/docs/api-keys ============================================================================== # API keys Create scoped API keys and drive Krova Cloud programmatically over the v1 REST API. Everything you can do in the dashboard you can also do over the REST API — create and manage Cubes, snapshots, domains, port mappings, and webhooks. For the full, interactive endpoint list, see the [REST API reference](https://krova.cloud/docs/api). ## Create a key API keys are created per **space** from the dashboard. A key inherits the permissions of the membership that created it, so it can only do what that member can do. Copy the key when it's shown — it's only displayed once. ## Authenticate Send your key in the `X-API-KEY` header on every request. The base URL is: ``` https://krova.cloud/api/v1 ``` For example, to list the Cubes in a space: ``` curl -H "X-API-KEY: kro_your_key" \ https://krova.cloud/api/v1/spaces/{spaceId}/cubes ``` ## Idempotency For mutating requests (creating Cubes, domains, mappings…), send an `Idempotency-Key` header with a unique value. Replays of the same key return the original response instead of performing the action twice — safe to retry on a flaky connection. Keys are scoped per space and expire after 24 hours. ## Rate limits Mutating `POST`/`PATCH`/`DELETE` endpoints are rate-limited per client IP. If you exceed the limit you'll get a `429` response — back off and retry. ## OpenAPI spec The API is described by an OpenAPI document you can feed into your own tooling or code generators: ``` https://krova.cloud/api/v1/openapi.json ``` The [interactive reference](https://krova.cloud/docs/api) is rendered directly from that spec, so it's always in sync with the live API. ============================================================================== URL: https://krova.cloud/docs/how-to/postgres ============================================================================== # Deploy PostgreSQL on a Cube Install PostgreSQL on a Cube, create a database and user, and connect two ways: an SSH tunnel for development, and an IP-allow-listed TCP mapping. A Cube is a real Linux machine with root access, so running PostgreSQL on one is the same job it would be on any VPS — with one difference worth getting right from the start: how you reach the database from outside it. By the end of this guide you will have PostgreSQL running on a Cube, a database and user created, and both ways of connecting to it: - **An SSH tunnel** — nothing is published at all. Ideal while you are developing at your own machine. - **An IP-allow-listed TCP port mapping** — a real endpoint your deployed app can hold a connection pool against, reachable only from the addresses you name. Pick one; you do not need both. The thing to avoid is the third option — publishing the port with no allow-list at all. ## Before you start - A Krova Cloud space with some credit. The Cube used here costs about **$0.0065/hour**, or roughly **$4.75/month** if you leave it running. - An SSH key pair. If you do not have one, run `ssh-keygen -t ed25519` and press Enter at each prompt. - A `psql` client on your own machine, to test the connection at the end. On macOS, `brew install libpq`; on Debian or Ubuntu, `sudo apt install postgresql-client`. This guide fits inside the **Welcome** tier, so a brand-new account can follow it start to finish with nothing unlocked. ## Step 1 — Create the Cube From your space, go to **Cubes** and choose **New Cube**. The settings that matter here: - **Image** — `Ubuntu 24.04`. PostgreSQL comes from Ubuntu's own package archive, so the plain image is all you need. The Docker image is only worth picking if you plan to run other services in containers alongside it. - **Size** — 1 vCPU, 2 GB RAM and 10 GB disk is a comfortable starting point for development and small production workloads, and you can [resize](https://krova.cloud/docs/cubes) later without rebuilding. - **SSH key** — paste the contents of your public key file (usually `~/.ssh/id_ed25519.pub`). It is written to the Cube at boot. This field is required; the Create button stays disabled until you fill it. The summary panel shows the exact hourly, daily and monthly cost before you commit. Create the Cube and it boots in seconds. ## Step 2 — Connect over SSH Open the Cube and look at the **Connect** tab. It shows the exact command for your Cube, including its port: ``` ssh ubuntu@ -p ``` If the key you created the Cube with is not your default, point at it explicitly: ``` ssh -i ~/.ssh/my_key ubuntu@ -p ``` You can also use the in-browser **Terminal** button on the Cube page if you would rather not leave the dashboard. ## Step 3 — Install PostgreSQL On the Cube, install the server and its contrib extensions: ``` apt update apt install -y postgresql postgresql-contrib ``` Ubuntu 24.04 ships **PostgreSQL 16**; Debian 13 ships **PostgreSQL 17**. Everything below works the same on either — only the version number and the `/etc/postgresql//` path differ. The package starts the service and enables it at boot for you — confirm both: ``` systemctl is-active postgresql # active systemctl is-enabled postgresql # enabled ``` ## Step 4 — Create a database and a user PostgreSQL installs with a `postgres` superuser and no application database. Create a dedicated role and database rather than letting your app connect as the superuser. Generate a strong password first, and keep it somewhere safe: ``` openssl rand -base64 24 ``` Then create the role and database: ``` sudo -u postgres psql \ -c "CREATE ROLE appuser LOGIN PASSWORD '';" \ -c "CREATE DATABASE appdb OWNER appuser;" ``` Check it landed: ``` sudo -u postgres psql -c "\l appdb" ``` The listing should show `appdb` with `appuser` as its owner. ## Step 5 — Connect from your own machine Out of the box PostgreSQL listens only on the Cube's loopback interface — you can confirm that with `sudo -u postgres psql -tAc "SHOW listen_addresses;"`, which prints `localhost`. Nothing outside the Cube can reach port 5432, which is exactly what you want. To reach it from your laptop, forward the port over SSH. Run this on **your machine**, not on the Cube: ``` ssh -L 15432:localhost:5432 ubuntu@ -p ``` Leave that session open. In another terminal, connect as though the database were local: ``` psql -h 127.0.0.1 -p 15432 -U appuser -d appdb ``` The traffic rides inside the SSH connection, so it is encrypted end to end and the database is still not published to the internet. Any tool that speaks PostgreSQL works the same way — point it at `127.0.0.1:15432`. The Cube's **Connect** tab has a ready-made port-forwarding command you can copy and adapt. ## Step 6 — Connect a deployed app The tunnel is the right tool while you are working at your own machine, but it is a foreground SSH session: an app running somewhere else cannot depend on you keeping it open. For that, give the database its own endpoint with a **TCP port mapping**, and put an **IP allow-list** on it so only your app can reach it. ### Add the mapping On the Cube's **Networking** tab choose **Add Mapping**: - **Cube Port** — `5432`. - **IP Whitelist** — the public IP of whatever will connect. Single addresses and CIDR ranges both work, comma- or newline-separated. **Do not leave the allow-list empty.** The form warns you that an unrestricted mapping is publicly accessible, and a Postgres port open to the internet is found and brute-forced within hours. If you do not know the connecting IP yet, stay on the tunnel until you do. Krova assigns a public host port — shown on the mapping as `Connect: :`. That is the address your app uses; it is not the same number as `5432`. ### Let PostgreSQL answer on it The mapping forwards traffic to the Cube, but PostgreSQL is still bound to loopback, so it will refuse the connection until you widen it. On the Cube, edit `postgresql.conf`: ``` listen_addresses = '*' ``` Then add a matching rule to `pg_hba.conf`, so only this database and role may authenticate, and only with a hashed password: ``` host appdb appuser 0.0.0.0/0 scram-sha-256 ``` The `0.0.0.0/0` here is not as broad as it looks — the allow-list on the mapping has already decided who may reach the port at all. This line governs who may then authenticate. Reload and confirm: ``` systemctl restart postgresql sudo -u postgres psql -tAc "SHOW listen_addresses;" # * ``` ### Connect ``` psql -h -p -U appuser -d appdb ``` Your app connects the same way — this is an ordinary PostgreSQL endpoint, so any driver or ORM works with no special handling. The allow-list is enforced in the host firewall, ahead of the Cube, so a source that is not on it never reaches PostgreSQL at all: the connection does not get refused, it simply times out. Your app also keeps its real client address — `inet_client_addr()` reports the connecting IP, not a gateway — so per-client logging and `pg_hba.conf` rules behave the way you expect. Keep the allow-list current. If your app moves, or its egress IP changes, update the mapping first — otherwise the connection starts timing out with nothing in the PostgreSQL log to explain it, because the packets never arrived. ## What it costs The Cube in this guide (1 vCPU, 2 GB RAM, 10 GB disk) bills at about **$0.0065/hour** — roughly **$0.16/day**. Usage is metered by the minute, so you are not rounded up to the hour. If you only need the database occasionally, **power the Cube off** when you are done. A stopped Cube is billed for its disk alone and keeps all its data, so you can start it again later and pick up exactly where you left off — see [Cubes](https://krova.cloud/docs/cubes) for how the two states bill. ## Cleaning up If this was a trial run, delete the Cube from its page. That destroys the disk and everything on it, including the database — take a snapshot first if there is anything you want to keep. ## Next steps - [Cubes](https://krova.cloud/docs/cubes) — resizing, snapshots, and how running versus stopped billing works. - [Custom domains](https://krova.cloud/docs/custom-domains) — if the app that uses this database needs to be served over HTTPS. - [CLI](https://krova.cloud/docs/cli) — create and manage Cubes like this one from your terminal instead of the dashboard. ============================================================================== URL: https://krova.cloud/docs/how-to/nodejs ============================================================================== # Run a Node.js app on a Cube Run a Node.js app on a Cube as a systemd service that survives reboots, and serve it on your own domain over HTTPS. A Cube gives you a normal Linux box, so running Node is the ordinary job it would be anywhere: install a runtime, run the app under an init system so it restarts on its own, and put a domain in front of it. Two things are specific to a Cube and easy to get wrong, so they get their own steps: **which Node you install** (the one in your distribution's archive is past end-of-life, on both Ubuntu and Debian), and **which interface your app listens on** (bind to loopback and your domain returns 503). This guide fits inside the **Welcome** tier — the Cube used here is 1 vCPU, 2 GB RAM and 10 GB disk, about **$0.0065/hour**. ## Step 1 — Create the Cube and connect Create a Cube with the plain `Ubuntu 24.04` image and your SSH public key, then connect with the command on its **Connect** tab: ``` ssh ubuntu@ -p ``` ## Step 2 — Install Node.js **Do not use your distribution's packaged Node.** Ubuntu 24.04 offers **Node 18**, which reached end of life in April 2025; Debian 13 offers **Node 20**, which reached end of life in April 2026. Neither gets security updates any more. Check for yourself: ``` apt-cache policy nodejs ``` Install the current LTS from NodeSource instead. Fetch the setup script and read it before running it, rather than piping it into a shell: ``` curl -fsSL https://deb.nodesource.com/setup_lts.x -o nodesource.sh less nodesource.sh bash nodesource.sh apt-get install -y nodejs ``` Confirm what you got: ``` node --version npm --version ``` ## Step 3 — Put the app somewhere sensible Give the app its own directory and its own unprivileged user, so a compromise of the app is not a compromise of the Cube: ``` useradd --system --create-home --shell /usr/sbin/nologin nodeapp mkdir -p /opt/hello-app ``` A minimal `/opt/hello-app/server.js` to prove the plumbing — replace it with your own app once the path works end to end: ``` import { createServer } from "node:http"; const port = process.env.PORT ?? 3000; createServer((req, res) => { res.writeHead(200, { "content-type": "text/plain; charset=utf-8" }); res.end(`Hello from a Krova Cube.\nnode ${process.version}\n`); }).listen(port, "0.0.0.0", () => { console.log(`listening on 0.0.0.0:${port}`); }); ``` The `"0.0.0.0"` in that `listen()` call is load-bearing — see Step 5. Add a `package.json` with `"type": "module"` so the `import` works, then hand the directory to the app user: ``` chown -R nodeapp:nodeapp /opt/hello-app ``` ## Step 4 — Run it under systemd Running `node server.js` in your SSH session lasts exactly as long as the session does. A systemd unit makes the app a real service: it restarts if it crashes and it comes back on its own after a reboot. Write `/etc/systemd/system/hello-app.service`: ``` [Unit] Description=hello-app After=network-online.target Wants=network-online.target [Service] Type=simple User=nodeapp WorkingDirectory=/opt/hello-app Environment=NODE_ENV=production Environment=PORT=3000 ExecStart=/usr/bin/node /opt/hello-app/server.js Restart=always RestartSec=2 NoNewPrivileges=true PrivateTmp=true ProtectSystem=strict ProtectHome=true [Install] WantedBy=multi-user.target ``` Then enable and start it: ``` systemctl daemon-reload systemctl enable --now hello-app systemctl is-active hello-app # active systemctl is-enabled hello-app # enabled ``` `enable` is the half people forget. `start` runs it now; `enable` is what brings it back after a reboot. The combined `enable --now` does both. ## Step 5 — Bind to 0.0.0.0, not 127.0.0.1 This is the one that costs people an afternoon. **An app listening only on `127.0.0.1` cannot be reached through a domain**. Krova's ingress runs outside your Cube and connects to it over the network, so a process bound to loopback refuses that connection and the domain answers: ``` {"error":"upstream_unavailable","message":"The application behind this domain is starting up or temporarily unreachable. Retry shortly.","status":503} ``` Nothing is wrong with your domain or your certificate when you see that — the request reached Krova and Krova could not reach your app. Check what the app is actually bound to: ``` ss -ltn | grep 3000 ``` `127.0.0.1:3000` is the problem; `0.0.0.0:3000` is what you want. Binding to all interfaces is safe here because the Cube is not directly addressable from the internet — only the ports you publish through a domain or a TCP mapping are reachable. ## Step 6 — Put a domain in front Add a DNS record for your domain pointing at `dns.krova.cloud`, then on the Cube's **Networking** tab choose **Add Domain**: - **Domain** — e.g. `app.example.com`. - **Port** — `3000`, the port your app listens on inside the Cube. The field defaults to `80`. - **This app serves HTTPS itself** — leave **unchecked**. Your app speaks plain HTTP; Krova terminates TLS at its edge and issues and renews the certificate. Your app never needs a certificate, never needs port 443, and never needs to know its own public name. It listens on a port; Krova does the rest. If your DNS is proxied through Cloudflare, set the zone's SSL/TLS mode to **Full** — see [custom domains](https://krova.cloud/docs/custom-domains). ## Step 7 — Prove it survives a reboot `systemctl is-enabled` printing `enabled` is a statement of intent, not evidence. Reboot the Cube and check: ``` systemctl reboot ``` Reconnect after a few seconds and confirm the service came back on its own, without you starting it: ``` uptime -p # up 0 minutes systemctl is-active hello-app # active curl -s http://127.0.0.1:3000/ ``` Your domain should serve again as soon as the app is listening. If the service is `inactive` after a reboot, you started it without enabling it. ## Deploying changes Once the app is a service, a deploy is: update the files, then `systemctl restart hello-app`. Because `Restart=always` is set, a crash on startup will loop rather than fail silently — check `journalctl -u hello-app -n 50` if a restart does not take. ## What it costs The Cube here (1 vCPU, 2 GB RAM, 10 GB disk) is about **$0.0065/hour** — roughly **$0.16/day**. Usage is metered by the minute. A web app is normally something you leave running; if you do power the Cube off, you are billed for its disk alone — see [Cubes](https://krova.cloud/docs/cubes). ## Next steps - [Deploy PostgreSQL on a Cube](https://krova.cloud/docs/how-to/postgres) — give the app a database, on the same Cube or another. - [Install Dokploy on a Cube](https://krova.cloud/docs/how-to/dokploy) — if you would rather deploy from Git through a UI than manage systemd units yourself. - [Custom domains](https://krova.cloud/docs/custom-domains) — per-domain proxy settings, and the Cloudflare specifics. ============================================================================== URL: https://krova.cloud/docs/how-to/dokploy ============================================================================== # Install Dokploy on a Cube Install Dokploy on a Cube for a self-hosted PaaS — deploy from Git with Traefik and automatic TLS. Includes the step the installer gets wrong on a Cube. **Dokploy** is an open-source, self-hosted PaaS — a web UI over Docker Swarm and Traefik that deploys apps from a Git repository, provisions databases, and issues TLS certificates. It is the self-hosted answer to Heroku or Vercel, and a Cube is a good place to run it: you get root, real resources, and no per-seat pricing. The install itself is one command. The part worth reading carefully is **Step 4** — the installer finishes by printing a URL that does not work on a Cube, and following it will leave you thinking the install failed when it did not. ## Before you start Dokploy's own requirements are **2 GB RAM and 30 GB of disk**, on Ubuntu 24.04 among other distributions. Cube size is not gated by tier — every activated space can run up to 16 vCPU, 32 GB RAM and 100 GB disk — so the 30 GB this guide needs is available from the start. - A Cube of **2 vCPU, 4 GB RAM, 40 GB disk** — about **$0.0140/hour**, roughly **$0.34/day** or **$10/month** if left running. - An SSH key pair, as with any Cube. - Optionally a domain you control, if you want to reach Dokploy at a real address rather than through a tunnel. ## Step 1 — Create the Cube Create a Cube with the `Ubuntu 24.04 + Docker` image. The installer will install Docker itself if it is missing, but starting from the Docker image skips that step and a few minutes of package work. **Use an Ubuntu image for this one.** Krova also offers Debian 13, but Dokploy's own supported-distribution list stops at Debian 12, so we do not suggest it here — their installer has not been validated against Debian 13. Size it at **2 vCPU / 4 GB / 40 GB**. Dokploy idles at a few hundred MB, but every app and database you deploy runs on the same Cube, so the headroom is the point. ## Step 2 — Connect over SSH ``` ssh ubuntu@ -p ``` If you have deleted and recreated a Cube, your SSH client may refuse to connect with a host-key warning. Host ports are recycled, so a new Cube can be handed the port a previous one used — and it has its own host key. Drop the stale entry and reconnect: ``` ssh-keygen -R "[]:" ``` Before installing, confirm the ports Dokploy needs are free: ``` ss -ltn | grep -E ":(80|443|3000)\s" ``` That should print nothing. The installer refuses to run if **80**, **443** or **3000** is already in use. ## Step 3 — Run the installer Dokploy publishes a single install script. Fetch it, look at it, then run it — piping a remote script straight into a shell is worth avoiding as a habit, even from a project you trust: ``` curl -fsSL https://dokploy.com/install.sh -o install.sh less install.sh sh install.sh ``` It initialises Docker Swarm, starts Dokploy and a PostgreSQL container for its own state, and pulls Traefik to handle inbound traffic. Give it a few minutes. When it finishes you should see two healthy services: ``` docker service ls ``` Both `dokploy` and `dokploy-postgres` should read `1/1`. ## Step 4 — Ignore the URL it prints The installer ends with *"Please go to http://:3000"*. **On a Cube that address will not load.** Nothing is broken — the installer asks the internet what your public IP is, and because a Cube reaches the internet through its host, the answer it gets back is the *host's* address, not the Cube's. Port 3000 was never published there, so the connection simply times out. Reach it over an SSH tunnel instead. Run this on **your machine**: ``` ssh -L 3000:localhost:3000 ubuntu@ -p ``` Leave it open and visit `http://localhost:3000`. You should get Dokploy's **Setup the server** screen. ## Step 5 — Create the admin account first That first screen is an **unauthenticated registration form**, and it creates the server's administrator. Whoever loads it first becomes the admin. **So create your account before Dokploy is reachable from anywhere else.** Doing it through the tunnel means the form is only ever exposed to your own machine. If you publish port 3000 first and register afterwards, anything that reaches the port in between can claim the server. Once you have registered and logged in, the tunnel has done its job. ## Step 6 — Give it a real address A tunnel is fine for setup, but you will not want to open one every time. Point a domain at the Cube instead. The important thing to understand first: **TLS is terminated at Krova's edge, not inside your Cube**. A Cube has no inbound address of its own, so a certificate requested by something running inside it can never be validated. Dokploy ships Traefik and Traefik can normally issue its own certificates — on a Cube it cannot, and it does not need to. Krova issues and renews the certificate for you, and forwards plain HTTP to a port inside the Cube. ### Map the domain Add a DNS record for your domain pointing at `dns.krova.cloud` (the Cube's networking tab has a copy button for it). Then, on that tab, choose **Add Domain**: - **Domain** — the hostname, e.g. `dokploy.example.com`. - **Port** — `3000`, the port the Dokploy UI listens on inside the Cube. This is the field to get right: the default is `80`, which is Traefik, not the dashboard. - **This app serves HTTPS itself** — leave it **unchecked**. Dokploy serves the dashboard over plain HTTP internally; Krova adds the TLS. The domain appears as **Active** with **HTTPS live** once the certificate is issued, and the dashboard is then reachable at `https://your-domain` with no tunnel and no published port 3000. ### If your DNS is behind Cloudflare With the orange cloud on, set Cloudflare's SSL/TLS mode to **Full**. - **Flexible** fetches the origin over plain HTTP and causes an endless redirect loop. - **Full (Strict)** fails, because Krova's ingress presents a self-signed origin certificate. Full encrypts to the origin without demanding a publicly-trusted certificate there, which is exactly the right setting. Krova detects a proxied domain and shows this warning on the mapping itself, so you do not have to remember which mode you picked. ### Domains for the apps you deploy Add each hostname twice: once in Dokploy, so Traefik routes it to the right container, and once on the Cube's **Networking** tab, so Krova routes it to the Cube. The Krova side always points at **Port 80** — Dokploy's Traefik — not your container's port. Traefik does the per-hostname routing from there, so one mapping serves every app you deploy. ### Or a TCP port mapping, allow-listed If you would rather reach port 3000 directly without a domain, add a **TCP port mapping** for `3000` and put your own IP in the **IP Whitelist**. **Do not publish port 3000 without an allow-list.** It is an admin control panel for a machine that can deploy arbitrary code; leaving it open to the internet is the worst version of this setup. ## What it costs The Cube described here bills at about **$0.0140/hour** — roughly **$0.34/day**, or **$10/month** if you leave it running. Usage is metered by the minute. Unlike a database you can pause, a PaaS is usually the thing everything else depends on, so plan on leaving it running. If you do power the Cube off, Dokploy and its containers come back with the disk — you are billed only for storage while it is stopped. ## Cleaning up Deleting the Cube removes Dokploy, every app it deployed, and its database along with the disk. If anything on it matters, snapshot first — and remember that Dokploy's own state lives in its PostgreSQL container, so a snapshot of the Cube is what captures it. ## Next steps - [Custom domains](https://krova.cloud/docs/custom-domains) — required for serving Dokploy and its apps over HTTPS. - [Deploy PostgreSQL on a Cube](https://krova.cloud/docs/how-to/postgres) — if you would rather run a database directly than through Dokploy. - [Cubes](https://krova.cloud/docs/cubes) — resizing, snapshots, and how billing works when a Cube is stopped. ============================================================================== URL: https://krova.cloud/docs/how-to/dokploy-deploy ============================================================================== # Deploy an app with Dokploy Deploy an app through Dokploy on a Cube and give it a domain — including the one switch to leave off, and the port the Krova mapping has to use. This picks up where [Install Dokploy on a Cube](https://krova.cloud/docs/how-to/dokploy) left off: Dokploy is running and you can reach its dashboard. Now put an actual app behind a domain. The Dokploy half is the same as it would be on any server — their docs cover it well. What is specific to a Cube is **who issues the certificate**, and that is the one thing worth reading carefully. ## Step 1 — Create a project and a service In Dokploy, create a **Project**, then **Create Service** inside it. The options are **Application**, **Database**, **Compose**, **Template** and **Import**. For a web app you want **Application**. ## Step 2 — Choose a source On the service's **General** tab, the **Provider** row offers GitHub, GitLab, Bitbucket, Gitea, **Docker**, plain Git, and Drop. The Git providers need an OAuth connection set up in Dokploy's settings first — GitHub tells you so rather than failing later. If you just want to see the whole path working end to end, **Docker** needs nothing configured: give it a public image and press Save. ``` traefik/whoami:latest ``` That image is a useful first deploy because it echoes the request back to you — so once it is live, the response itself tells you the routing worked and what reached the container. ## Step 3 — Add the domain in Dokploy, with HTTPS off On the service's **Domains** tab choose **Add Domain**: - **Host** — the hostname, e.g. `app.example.com`. - **Container Port** — the port your container listens on. For `traefik/whoami` that is `80`. - **HTTPS** — leave it **off**. That last one matters. The switch tells Dokploy's Traefik to request its own Let's Encrypt certificate, and **on a Cube that cannot succeed**: a Cube has no inbound address of its own, so an ACME challenge issued from inside it can never be validated. Krova issues the certificate at its edge instead and forwards plain HTTP inward. With HTTPS off, the domain row in Dokploy reads `HTTP` and `Cert: none`. That is the correct state, not a missing step — the certificate exists, it just lives one layer out. ## Step 4 — Deploy Back on **General**, press **Deploy** and confirm. Dokploy pulls the image and starts it as a Docker Swarm service. On the Cube you can watch the result directly: ``` docker service ls ``` Your service appears alongside `dokploy` and `dokploy-postgres`, and should read `1/1`. ## Step 5 — Add the domain on the Cube Dokploy is serving the domain now, but Krova does not know about it yet. Add it on the Cube's **Networking** tab. Use **Port 80** — that is Dokploy's Traefik, not your container's port. Traefik then routes by hostname to the right container, which is why one mapping covers every app you deploy through Dokploy rather than needing one per container. ## Step 6 — Check what actually arrived Load the domain. With `traefik/whoami` the response shows the full path the request took: ``` Hostname: 7402d1632397 RemoteAddr: 10.0.1.4:53358 GET / HTTP/1.1 Host: app.example.com Cf-Connecting-Ip: 203.0.113.50 ``` - `Hostname` is the container ID — you reached the app, not an error page. - `RemoteAddr` is Dokploy's Traefik on the Swarm overlay network, which is the hop in front of your container. - `Cf-Connecting-Ip` is the real client address, preserved through the whole chain — so per-visitor logging and rate limiting behave the way you expect. ## When something does not work - **503 from the domain** — Krova reached your Cube but not your app. Check the service is `1/1` in `docker service ls`, and that the container port on the domain matches what the image actually listens on. - **The domain never appears in Krova** — sync reads live routing, so redeploy the service after adding the domain in Dokploy. - **A certificate warning** — check the HTTPS switch in Dokploy is off. If Traefik is trying to serve its own certificate, that is the one it failed to obtain. ## Next steps - [Install Dokploy on a Cube](https://krova.cloud/docs/how-to/dokploy) — if you have not set the Cube up yet. - [Run a Node.js app on a Cube](https://krova.cloud/docs/how-to/nodejs) — the same result without a PaaS, using systemd directly. - [Custom domains](https://krova.cloud/docs/custom-domains) — per-domain settings and the Cloudflare specifics. ============================================================================== URL: https://krova.cloud/docs/how-to/github-actions-runner ============================================================================== # Run a GitHub Actions runner on a Cube Self-host a GitHub Actions runner on a Cube as a systemd service that survives reboots — outbound-only, with no published ports and nothing exposed to the internet. GitHub's hosted runners are fine until you want more CPU than they give you, a build cache that survives between jobs, or a machine you control. A **self-hosted runner** on a Cube gives you all three: root, persistent disk, and a cost you can predict. The property that makes a Cube a particularly good host for this is that a runner is **outbound-only**. It long-polls GitHub over HTTPS and GitHub never connects back to it. So you publish **no ports at all** — SSH is enough to set it up, and your CI machine is never reachable from the internet. The steps below are short. Three of them have a trap that will stop you dead with an error that does not describe the actual problem — **Step 3**, **Step 4** and **Step 5**. Those are the ones worth reading rather than pasting. ## Before you start **Use private repositories only.** This is GitHub's own guidance and it is not a formality: anyone can fork a public repository and open a pull request whose workflow runs arbitrary code on your runner. A self-hosted runner attached to a public repo is a machine you have handed to strangers. Registering at the organisation level puts the runner in the default runner group, which only private repositories can reach. Leave it there, or scope it deliberately with `--runnergroup`. - A Cube running **Ubuntu 24.04**. Start at **2 vCPU / 4 GB / 20 GB** and grow it once you know the workload. - An SSH key pair, as with any Cube. - Admin rights on the organisation or repository you are registering against. Size for your builds, not for the runner. The runner process itself idles at a few megabytes; compilation, tests and Docker layers are what consume the Cube. Its `_work` directory grows without bound as jobs check out repositories and cache toolchains, so plan a cleanup step or extra disk before it matters. ## Step 1 — Create the Cube Create a Cube with the `Ubuntu 24.04` image. If your workflows use `container:`, `services:`, or call `docker` directly, use `Ubuntu 24.04 + Docker` instead — it is the same image with Docker Engine already installed. You can also start plain and add Docker later; nothing about the Cube prevents it. Adding the runner user to the `docker` group does mean any job can become root on the Cube, so make that choice on purpose rather than by habit. ## Step 2 — Connect over SSH The Cube's **Connect** tab shows the exact command, with the host and port already filled in: ``` ssh ubuntu@ -p ``` If your key is not your default one, point at it explicitly with `-i ~/.ssh/your_key`. A `Permission denied (publickey)` here means the connection reached the Cube and only the key was rejected — the network path is fine. ## Step 3 — Create a user for the runner The runner's `config.sh` refuses to run as `root` and exits with `Must not run with sudo`. There is an environment variable that overrides this. **Do not use it.** A runner executes whatever a workflow tells it to, and running that as root means a single bad job owns the whole Cube. ``` adduser --disabled-password --gecos "" runner install -d -o runner -g runner /home/runner/actions-runner ``` GitHub's hosted runners give workflows passwordless `sudo`, and plenty of published actions assume it. If you want that parity: ``` echo 'runner ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/runner chmod 440 /etc/sudoers.d/runner ``` That does make any job root-equivalent on the Cube. Skip it if you would rather discover which workflows genuinely need it. ### The trap: never use an interactive `su` Every command from here on runs as `runner`, and the obvious way to do that — typing `su - runner` and then pasting the rest — **silently corrupts the whole sequence**. `su - runner` starts an interactive shell. The lines you pasted after it are still sitting in your terminal's input buffer, so that new shell reads them as its own input, in an order you did not intend. In practice a stray `exit` logs you straight back out and the remaining commands run *as root*, in root's home directory — which is how you end up staring at `Must not run with sudo` again after carefully creating a non-root user. Use the non-interactive form instead. It runs one command as `runner` and returns: ``` su - runner -c '' ``` ## Step 4 — Download and verify the runner Open **Settings → Actions → Runners → New self-hosted runner** on your organisation or repository and choose **Linux** and **x64**. That page always shows the current version, its checksum and a registration token, so take the download and checksum lines from it rather than from any guide — this one included. **Choosing the right platform there is load-bearing.** Each package has its own valid checksum, so downloading the macOS build onto a Linux Cube passes verification perfectly and then fails later with an error about something else entirely. Cubes are x86-64 Linux: you want `actions-runner-linux-x64`. Then run it as the `runner` user, substituting the version and checksum GitHub showed you: ``` RUNNER_VERSION=2.336.0 RUNNER_SHA= TARBALL=actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz URL=https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/${TARBALL} su - runner -c "cd ~/actions-runner \ && curl -fsSL -O '${URL}' \ && echo '${RUNNER_SHA} ${TARBALL}' | sha256sum -c - \ && tar xzf '${TARBALL}' \ && ls -d bin externals" ``` You want `OK` from the checksum, then `bin externals`. ## Step 5 — Install the .NET dependencies The runner is a .NET application and a minimal Ubuntu image does not ship what it needs. This step is **not optional**: `config.sh` checks these libraries before it does anything else and aborts with `Dependencies is missing for Dotnet Core 6.0` if they are absent. The runner package includes the installer, which runs as root: ``` cd /home/runner/actions-runner && ./bin/installdependencies.sh ``` It installs `libkrb5-3`, `zlib1g`, `liblttng-ust1t64`, `libssl3t64` and `libicu74`. **A run of `E: Unable to locate package libicu80` … `libicu75` is normal.** The script tries ICU versions newest-first and stops at the one your distribution has: on Ubuntu 24.04 that is `libicu74`, on Debian 13 it is `libicu76`, several lines down either way. The line that matters is `Finish Install Dependencies` at the end. ## Step 6 — Register the runner The registration token from that GitHub page expires in about an hour, so do Steps 4 and 5 first and fetch the token immediately before this one. ``` su - runner -c 'cd ~/actions-runner && ./config.sh \ --url https://github.com/ \ --token \ --name \ --labels krova,cube \ --work _work \ --unattended --replace' ``` `--unattended` is worth keeping even when you are typing by hand: it makes registration fail loudly on a bad token instead of dropping into an interactive prompt that will swallow whatever you paste next. `self-hosted`, `linux` and `x64` are applied automatically — `--labels` adds to them. Use `--url https://github.com//` instead for a single repository. Success looks like `√ Connected to GitHub`, `√ Runner successfully added` and `√ Settings Saved`. ## Step 7 — Run it as a service Without this the runner only lives as long as your SSH session. `svc.sh` is **generated by Step 6** with the service name baked in, so it does not exist until registration has succeeded. It runs as root, from the runner directory, and takes the username to run as: ``` cd /home/runner/actions-runner ./svc.sh install runner ./svc.sh start ./svc.sh status ``` The unit is enabled, so the runner comes back on its own after a Cube restart. ## Step 8 — Verify it actually runs a job First confirm the service is up and listening: ``` systemctl is-active 'actions.runner.*' journalctl -u 'actions.runner.*' -n 30 --no-pager ``` You want `active`, and a `Listening for Jobs` line in the journal. That is the runner reporting its own health, which is not the same as a job succeeding. Prove the rest by landing one. Commit this to a private repository the runner can see, then run it from the **Actions** tab: Install **git** first — `actions/checkout` needs it and a minimal image does not have it, so without this the very first job fails on its very first step: ``` command -v git || apt-get install -y git name: cube-runner-smoke on: workflow_dispatch jobs: smoke: runs-on: [self-hosted, krova] steps: - uses: actions/checkout@v7 - name: Where am I run: | echo "host: $(hostname)" echo "user: $(whoami)" echo "arch: $(uname -m)" df -h / - name: Passwordless sudo run: sudo -n true && echo "sudo OK" - name: Egress run: curl -sS -o /dev/null -w 'github: %{http_code}\n' https://api.github.com ``` That exercises the four things the steps above only implied: that jobs reach the runner, that `checkout` can clone, `sudo` works, and the Cube has outbound network from inside a job. ## Where to go next - **Container jobs.** Install Docker (or recreate the Cube from `Ubuntu 24.04 + Docker`), then `usermod -aG docker runner` and **restart the runner service**. Group membership does not apply to an already-running process, so skipping the restart leaves the runner on its old groups and every `docker` call inside a job fails as though the install were broken. - **Disposable runners.** Add `--ephemeral` at registration and the runner accepts one job then deregisters, so nothing leaks between jobs. It needs re-registering per job, so pair it with automation. - **More runners.** Each one is its own Cube with its own name. Give them a shared label and GitHub will distribute jobs across them. - [Snapshot the Cube](https://krova.cloud/docs/how-to/snapshots) once the runner is configured, so rebuilding it later is a restore rather than this page again. ============================================================================== URL: https://krova.cloud/docs/how-to/snapshots ============================================================================== # Snapshot and restore a Cube Snapshot a Cube, restore it when something goes wrong, and understand when you need a Backup instead — the copy that outlives the Cube. A snapshot is a point-in-time copy of a Cube's disk, saved to cloud storage. Taking one does not interrupt anything — the Cube keeps running while it uploads. Restoring one does interrupt: the Cube is stopped, its disk is replaced, and it starts again. ## Snapshots and Backups are not the same thing Both copy your disk, and the difference only matters at the moment you need one: - **Snapshots live with the Cube.** They are cheap, incremental, and ideal for "undo the last hour". They are **deleted when the Cube is deleted**. - **Backups outlive the Cube.** A Backup stores the disk *and* the Cube's configuration — CPU, RAM, disk, domains, TCP mappings — so you can redeploy an identical Cube later, after the original is gone. If a copy needs to survive deleting the Cube, it must be a Backup. You can promote any snapshot with **Save as Backup**. How many of each you get, and how often automatic snapshots run, depends on your tier. The **Welcome** tier has no automatic snapshots and no Backups — manual snapshots only. Higher tiers add automatic snapshots on a cadence and a retention ladder. ## Step 1 — Take a snapshot Open the Cube's **Snapshots** tab and choose **Create Snapshot**. Give it a name that says what state it captures — `before-upgrade` is useful six weeks later in a way that `snapshot-3` is not. The Cube stays up throughout. The list separates **Auto** from **Manual**, and each snapshot reports the **Added** size — the deduplicated new data it contributed, not the size of your whole disk. The first snapshot uploads everything; later ones only what changed, which is why they are cheap to take often. Take one **before** anything you might want to undo: a distribution upgrade, a database migration, a config change you are not sure about. ## Step 2 — Restore On the snapshot you want, choose **Restore**. The confirmation is worth reading, because it describes exactly what happens: *"This will stop the Cube, replace the disk with snapshot …, and restart it. Any data written since the snapshot was taken will be lost."* All three parts are literal. The Cube goes down, the whole disk is replaced — not merged — and everything written after the snapshot is gone, including data you wanted to keep that happens to live on the same disk. If some of it matters, take a fresh snapshot **before** restoring the old one; then you can move between the two. The Cube reboots as part of the restore, so services come back the way they would after any reboot — which is to say, only the ones you `systemctl enable`d. ## Step 3 — Check it actually came back A restore that reports success is not the same as a Cube that works. Reconnect and confirm the things you know should have changed: ``` uptime -p # up 0 minutes — the Cube did cycle systemctl is-active curl -s http://127.0.0.1:/ ``` If you serve the Cube on a domain, check that too — it should return to normal once the app is listening again. A **503** means Krova is reaching the Cube but not your app, so the service has not come up yet. ## The other things you can do with a snapshot - **Save as Backup** — promote it to a copy that survives deleting the Cube. - **Clone** — build a *new* Cube from this snapshot and leave the original untouched. This is the safe way to test a restore, or to fork production into a staging copy. - **Export** — download the snapshot. - **Pin** — exempt it from automatic pruning, so a snapshot you care about is not aged out by the retention ladder. **Prefer Clone over Restore when you are unsure.** Restore overwrites the Cube you have; Clone gives you a second one to inspect first, at the cost of running two for a while. ## When you are deleting a Cube The delete dialog offers **Preserve backup before deleting**, and it is **checked by default**. That is the right default when you might want the Cube back — and it keeps billing you for the stored disk afterwards. If you are deleting something disposable, uncheck it deliberately rather than leaving a backup you did not mean to keep. See [Cubes](https://krova.cloud/docs/cubes) for how stored data bills. ## Next steps - [Cubes](https://krova.cloud/docs/cubes) — resizing, power states, and how running versus stopped billing works. - [Deploy PostgreSQL on a Cube](https://krova.cloud/docs/how-to/postgres) — a database is the usual reason to want a snapshot before a change. ============================================================================== URL: https://krova.cloud/docs/how-to/backup-restore ============================================================================== # Back up a Cube and bring it back Create a Backup that outlives a Cube, redeploy an identical Cube from it, and move a Cube between spaces by downloading and importing its archive. A **Backup** stores a Cube's disk *and its configuration* — vCPU, RAM, disk size, image, region and its mappings — so you can bring an identical Cube back later. Unlike a [snapshot](https://krova.cloud/docs/how-to/snapshots), a Backup survives deleting the Cube it came from. There are two ways to use one: **Redeploy**, which builds a new Cube in place, and **Download** plus **Import**, which moves it to another space or account. ## Step 1 — Create the Backup Two routes to the same thing: - From a snapshot — **Save as Backup** on any snapshot in the Cube's **Snapshots** tab. - While deleting — the delete dialog's **Preserve backup before deleting**, which is ticked by default. Backups are billed **per GB-month** for as long as they exist, and the archive is compressed: a 10 GB Cube whose disk is mostly empty produces a few hundred MB, and the Backups page shows both the size and the monthly cost before you commit to keeping it. ## Step 2 — Redeploy into a new Cube On the **Backups** page choose **Redeploy**. This creates a *new* Cube with the same disk state — the original, if it still exists, is untouched. Three things about the form are worth knowing before you use it: - **Disk can only grow.** vCPU and RAM move freely within your plan, but the disk cannot shrink below what the backup recorded — shrinking the filesystem would corrupt it. - **An SSH key is required**, even though the disk already contains the old one. Supply the key you intend to use for the new Cube. - **Mappings are re-attempted, and conflicts are skipped.** Domains and TCP mappings stored in the backup are re-applied on boot — but if the original Cube still holds one, the new Cube simply boots without it. Nothing is stolen and nothing errors; the mapping is just absent, and you add it manually if you meant to move it. The last one is the surprise in practice. Redeploying alongside a live original gives you a Cube with all the data and none of the domains, which is exactly right for a staging copy and exactly wrong if you expected a failover. ### The hostname comes from the disk The name you give the new Cube is the name in the dashboard. Inside it, `hostname` still returns whatever the original was, because that lives on the restored disk. If anything you run keys off the hostname, set it explicitly after the first boot. ## Step 3 — Check what actually came back Connect to the new Cube and confirm the state you expected, rather than trusting that a green status means your data is there: ``` systemctl is-active # enabled units come back on their own curl -s http://127.0.0.1:/ # the app answers ls -la /path/that/should/exist # your data is on the disk ``` Services you `enable`d start by themselves, because that state is on the disk too. Services you only ever `start`ed do not. ## Step 4 — Moving a Cube somewhere else Redeploy works within the same space. To move a Cube to a different space or account, download the Backup and import it there. **Download** gives you a `.cube` file — a tar archive whose first entry is a `manifest.json` describing the Cube's resources and image. Two things to note: - The link is **presigned and expires in 15 minutes**. - **Anyone holding that URL can download the archive** during that window, with no further authentication. It is a copy of your whole disk — treat the link as a credential and do not paste it anywhere shared. In the destination space, use **Import Cube** from the Cubes page and upload the `.cube` file. The manifest fills in the resources, and the same rule applies as on redeploy — you can raise the disk but not lower it. If the archive's disk is larger than your plan allows, the import is blocked until you upgrade rather than failing partway. ## Backups are not a backup strategy on their own Everything here lives in the same platform as the Cube. That covers the cases you will actually hit — a bad deploy, a deleted file, a Cube you removed too eagerly — but it is not an off-platform copy. If the data matters, keep something of your own as well: a database dump to your own object storage, a Git remote you control. ## Next steps - [Snapshot and restore a Cube](https://krova.cloud/docs/how-to/snapshots) — the lighter, in-place version for undoing a change. - [Cubes](https://krova.cloud/docs/cubes) — resizing, power states and how stored data bills. ============================================================================== URL: https://krova.cloud/docs/how-to/mcp-claude ============================================================================== # Manage Cubes from Claude with MCP Connect Krova Cloud to Claude, Cursor or any MCP client and manage Cubes in conversation — including the env var the server needs beyond the API key. `@krovacloud/mcp` exposes Krova Cloud as a set of tools an AI agent can call over the [Model Context Protocol](https://modelcontextprotocol.io). Once it is connected you can ask for "my running cubes", or "a 2 vCPU Ubuntu cube in US", and the client calls the API for you instead of you opening the dashboard. The [MCP server reference](https://krova.cloud/docs/mcp) covers the tool surface. This page is the setup, end to end, including the two things that are easy to get wrong. ## Step 1 — Create an API key In your space, go to **Space settings** → **API Keys** → **Generate key**, and give it a name that says where it will live, like `claude-desktop`. **Copy the key immediately.** It is shown once, at the moment it is created. Afterwards the dashboard only displays its prefix, and there is no way to reveal the rest — if you lose it, generate a new one and delete the old. A key **carries your own permissions in that space**. Anyone holding it can act as you there, including deleting Cubes. Put it in your client's config file, not in a repository, and generate a separate key per machine so you can revoke one without disturbing the others. ## Step 2 — You also need the space ID This is the step people miss. The API key authenticates you, but it does not say *which space* to act on — an account can have several. Set both: - `KROVA_API_KEY` — the key from Step 1. - `KROVA_SPACE_ID` — the space to work in. The space ID is in your dashboard URL: everything between the host and the next slash, e.g. `https://krova.cloud//cubes`. Without it the server starts, connects and lists its tools quite happily — and then every call fails with *"No spaceId provided and no default configured"*. Nothing is broken; it just does not know where to look. You can also pass `spaceId` per call, which is what you want if you work across several spaces. ## Step 3 — Add the server to your client MCP clients share the same shape of configuration. For **Claude Desktop** this goes in `claude_desktop_config.json`; for **Claude Code** and **Cursor**, in the equivalent MCP config for your project or user: ``` { "mcpServers": { "krova": { "command": "npx", "args": ["-y", "@krovacloud/mcp"], "env": { "KROVA_API_KEY": "kro_your_key_here", "KROVA_SPACE_ID": "your_space_id" } } } } ``` Restart the client afterwards — most read MCP configuration only at startup. `npx` fetches the package on first run, so the first start is slower than later ones. ## Step 4 — Check it connected Ask the client to list your Cubes. A working connection returns your real Cubes with their status, image and hourly cost. If instead you get a general answer about what Krova is, the tools are not connected and the model is answering from memory — check the client's MCP status panel rather than rephrasing the question. The server exposes tools across Cubes, domains, snapshots, TCP mappings, regions, images and pricing — enough to do most of what the dashboard does. ## What to be careful about The tool set includes destructive operations — `delete_cube`, `restore_cube`, `delete_domain`. An agent that can create a Cube can also remove one, and it is working with your permissions. - **Keep approval prompts on** for tool calls, at least until you trust the setup. Read what a call will do before allowing it. - **Use a separate space** for anything experimental, so the key cannot reach production Cubes at all. - **Revoke keys you are not using.** Deleting a key from Space settings takes effect immediately. ## Next steps - [MCP server reference](https://krova.cloud/docs/mcp) — the full tool list and their arguments. - [API keys](https://krova.cloud/docs/api-keys) — scopes, rotation, and the REST API behind all of this. - [CLI](https://krova.cloud/docs/cli) — the same operations from a terminal, if you would rather type than ask. ============================================================================== URL: https://krova.cloud/docs/sdk ============================================================================== # TypeScript SDK The official, fully-typed TypeScript SDK for Krova Cloud — provision and manage Cubes, browse the catalog, and reach every REST API operation from Node.js. `@krovacloud/sdk` is the official TypeScript client for Krova Cloud. Request bodies, responses, and path params are generated from the Krova Cloud OpenAPI spec, so you get end-to-end types and editor autocomplete for the whole API. Ergonomic helpers cover the Cube lifecycle and the catalog; a fully-typed escape hatch (`client.raw`) reaches every other operation. It's published on npm as [`@krovacloud/sdk`](https://www.npmjs.com/package/@krovacloud/sdk). ## Install Add it with your package manager. The only runtime dependency is `openapi-fetch`; TypeScript declarations are bundled (no `@types/*` needed). ``` npm i @krovacloud/sdk # or: pnpm add @krovacloud/sdk / yarn add @krovacloud/sdk ``` Requires **Node.js 18 or newer** (it uses the global `fetch`). It also works in any modern runtime with a WHATWG `fetch` — Deno, Bun, and edge — and you can pass a custom `fetch` if the global isn't available. ## Authenticate Create an API key per space from **Settings → API keys** in the dashboard (see [API keys](https://krova.cloud/docs/api-keys)). Keys are **scoped to a single space**, inherit the permissions of the membership that created them, and look like `kro_…`. Load the key from an environment variable or a secrets manager — never commit it or embed it in a browser bundle. ``` import { KrovaClient } from "@krovacloud/sdk"; const krova = new KrovaClient({ apiKey: process.env.KROVA_API_KEY!, // a "kro_..." token }); ``` By default the key is sent as the `X-API-KEY` header. If your gateway expects a bearer token, pass `authScheme: "bearer"`. ## Quickstart Every space-scoped call takes the `spaceId` as its first argument. Because an API key already belongs to one space, use the space id shown in your dashboard (or resolve it once and reuse it). ``` // List Cubes in a space const cubes = await krova.cubes.list("space_123"); // Create a Cube (sshPublicKey is required) const cube = await krova.cubes.create("space_123", { name: "web-server", image: "ubuntu-24.04", resources: { vcpu: 2, ramGb: 4, diskGb: 40 }, sshPublicKey: "ssh-ed25519 AAAA...your-key... you@host", }); console.log(`Created cube ${cube.id} (${cube.state})`); // Power it off, then start it again (both are asynchronous / enqueued) await krova.cubes.powerOff("space_123", cube.id); await krova.cubes.wake("space_123", cube.id); // Cold-restart in place — the only way to pick up a refreshed guest kernel await krova.cubes.restart("space_123", cube.id); ``` ## `new KrovaClient(options)` ``` new KrovaClient({ apiKey: string, // required — your "kro_..." token baseUrl?: string, // default: "https://krova.cloud/api/v1" authScheme?: "x-api-key" | "bearer", // default: "x-api-key" maxRetries?: number, // default: 2 — retries 429/503 (honors Retry-After); 0 disables fetch?: typeof fetch, // optional fetch override (proxy, tests) }); ``` Throws if `apiKey` is missing. Exposes `client.baseUrl`, `client.cubes`, `client.catalog`, and `client.raw`. Mutating `POST`/`DELETE` endpoints are rate-limited (10 requests / 60s per client IP); the client automatically retries `429` and `503` up to `maxRetries` times, honoring `Retry-After`. ## `client.cubes` — the Cube lifecycle Ergonomic helpers that unwrap the response body and throw a typed KrovaError on any non-2xx status. - `list(spaceId)` — every Cube in the space. - `get(spaceId, cubeId)` — one Cube. - `create(spaceId, body, opts?)` — the created Cube. - `update(spaceId, cubeId, body)` — update the Cube's SSH port (the only mutable field over the public API). - `powerOff` / `wake` / `restart` / `delete` `(spaceId, cubeId)` — asynchronous lifecycle transitions. `restart` is a *cold* restart: it re-reads the host kernel, which a `reboot` inside the Cube cannot do. ``` // create — sshPublicKey is required; region + userData (cloud-init) are optional. // opts.idempotencyKey (<=255 chars, per-space) makes retries safe. const cube = await krova.cubes.create( "space_123", { name: "web-server", image: "ubuntu-24.04", resources: { vcpu: 2, ramGb: 4, diskGb: 40 }, sshPublicKey: "ssh-ed25519 AAAA... you@host", region: "us", // optional — slug from catalog.regions() userData: "#cloud-config\n", // optional — cloud-init (max 16 KB) }, { idempotencyKey: "deploy-2026-07-01" }, ); // update — the only mutable Cube field over the public API is the SSH port await krova.cubes.update("space_123", cube.id, { cubePort: 2222 }); ``` The `Cube` type is exported for your own signatures: ``` import type { Cube } from "@krovacloud/sdk"; // { // id: string; name: string; // state: "pending" | "booting" | "running" | "stopped" | "stopping" | "error" | "deleted"; // publicIpv4: string | null; // resources: { vcpu: number; ramGb: number; diskGb: number }; // image: string; costPerHour: number; // createdAt: string; updatedAt: string; // } ``` ## `client.catalog` — regions, images, pricing Read-only catalog endpoints. Use these to discover the valid `image` and `region` slugs before creating a Cube. ``` const regions = await krova.catalog.regions(); // regions with available capacity const images = await krova.catalog.images(); // available OS images const pricing = await krova.catalog.pricing(); // per-resource hourly rates + volume tiers ``` ## Domains, snapshots & TCP mappings Typed helpers for a Cube's attached resources — each unwraps the response and throws `KrovaError` on failure. ``` // Custom domains const domain = await krova.domains.create("space_123", "cube_123", { domain: "app.example.com", port: 8080, }); await krova.domains.list("space_123", "cube_123"); await krova.domains.update("space_123", "cube_123", domain.id, { responseCompression: true }); await krova.domains.delete("space_123", "cube_123", domain.id); // Snapshots + restore const snap = await krova.snapshots.create("space_123", "cube_123", { name: "nightly" }); await krova.snapshots.list("space_123", "cube_123"); await krova.cubes.restore("space_123", "cube_123", snap.id); // replace the disk from a snapshot await krova.snapshots.delete("space_123", "cube_123", snap.id); // TCP port mappings (expose a Cube port on the host) const mapping = await krova.tcpMappings.create("space_123", "cube_123", { cubePort: 5432, whitelistIps: ["203.0.113.4/32"], }); await krova.tcpMappings.list("space_123", "cube_123"); await krova.tcpMappings.delete("space_123", "cube_123", mapping.id); ``` There are also `krova.imports` (create / get / complete / cancel a `.cube` import) and `krova.backups.download` for a time-limited backup URL, plus `krova.getSpace()` to resolve the space your key is scoped to and `krova.cubes.ssh()` for a Cube's SSH connection info. `Domain`, `Snapshot`, and `TcpMapping` are exported types. ## `client.raw` — every endpoint The helpers cover Cubes, the catalog, domains, snapshots, TCP mappings, imports, and backups. For anything else — e.g. Webhooks — use `client.raw`, the fully typed [openapi-fetch](https://openapi-ts.dev/openapi-fetch/) client. It returns `{ data, error, response }` and **never throws** — path, method, params, and body are all type-checked against the spec. ``` const { data, error } = await krova.raw.POST("/spaces/{spaceId}/webhooks", { params: { path: { spaceId: "space_123" } }, body: { url: "https://example.com/hook", events: ["cube.running"] }, }); if (error) { console.error("Webhook create failed:", error.error); } else { console.log(data); } ``` The generated `paths` and `components` types are also exported for advanced use: ``` import type { paths, components } from "@krovacloud/sdk"; type Domain = components["schemas"]["Domain"]; ``` ## Error handling The `cubes.*` / `catalog.*` helpers throw a `KrovaError` on any non-2xx response. (`client.raw` never throws — it returns the error in `{ error }`.) The error carries the HTTP `status`, the API `message`, an optional error `code`, and a `requestId` — quote the request id when contacting support. ``` import { KrovaError } from "@krovacloud/sdk"; try { await krova.cubes.get("space_123", "cube_missing"); } catch (err) { if (err instanceof KrovaError) { console.error(`[${err.status}] ${err.message}`); if (err.code) console.error("code:", err.code); if (err.requestId) console.error("request id:", err.requestId); } else { throw err; } } ``` ## Point at a different base URL Target a staging environment or a proxy by passing `baseUrl`: ``` const krova = new KrovaClient({ apiKey: "kro_...", baseUrl: "https://gateway.internal/krova/api/v1", }); ``` ## Next steps - [API keys](https://krova.cloud/docs/api-keys) — create and scope the key the SDK authenticates with. - [CLI](https://krova.cloud/docs/cli) — the same API from your terminal, plus SSH and port forwarding. - [Webhooks](https://krova.cloud/docs/webhooks) — receive and verify the events the API emits. - [REST API reference](https://krova.cloud/docs/api) — the interactive OpenAPI spec every helper is built on. ============================================================================== URL: https://krova.cloud/docs/cli ============================================================================== # CLI Install and use the krova CLI — authenticate, manage Cubes, SSH in, forward ports, and stream webhooks from your terminal. `krova` is the official command-line interface for Krova Cloud. It talks to the same public REST API as the SDK, so anything you can do in the dashboard you can also do from your terminal: list and create Cubes, SSH in, forward a port to a service running inside a Cube, and verify webhook deliveries locally. It is open-source and published on npm as [`@krovacloud/cli`](https://www.npmjs.com/package/@krovacloud/cli). ## Install Install globally with npm (or pnpm / yarn / bun). This puts a `krova` command on your `PATH`. It's a pure Node.js CLI (requires Node.js 20 or newer) — no native binary and no extra toolchain to install. ``` npm install -g @krovacloud/cli ``` Verify the install and check your version: ``` krova version ``` Upgrade the same way you installed — re-run `npm install -g @krovacloud/cli` to move to the latest release. ## Authenticate Every command runs against a **context** — a named bundle of an API key, a space, and (optionally) a base URL, stored in `~/.config/krova/config.json` (written with owner-only `0600` permissions). There are two ways to create one. ### Browser login (recommended) `krova login` uses the OAuth 2.0 Device Authorization flow: it opens Krova Cloud in your browser, you approve a short code, and the CLI stores the resulting key — no copy-pasting secrets. ``` krova login # On a headless machine, print the URL instead of opening a browser: krova login --no-browser ``` ### Paste an API key If you already have an API key (created per space from **Settings → API keys** in the dashboard — see [API keys](https://krova.cloud/docs/api-keys)), store it directly: ``` krova auth login --api-key kro_xxxxxxxx # Check what's currently in effect and where it came from: krova auth status ``` An API key is scoped to a single space, so the CLI resolves your space automatically — you never have to paste a space ID. ## Managing Cubes The `cubes` command group covers the full lifecycle. The two most common read verbs also have top-level shortcuts, so `krova list` and `krova get` work without the `cubes` prefix (matching `krova ssh`). ``` krova list # list every Cube (alias: krova ls, krova cubes list) krova get my-api # show one Cube by name or ID (krova cubes get) krova cubes power-off my-api # stop compute billing (data is preserved) krova cubes wake my-api # start a stopped Cube krova cubes restart my-api # cold-restart (picks up a refreshed kernel) krova cubes delete my-api # permanently delete a Cube krova cubes ssh-port my-api --port 2222 # port INSIDE the Cube sshd listens on ``` Cubes can be referenced by **name or ID** anywhere a `` argument is expected. ### Creating a Cube `--name`, `--image`, and `--ssh-key` are required. The SSH key is your **public** key — its contents are written to the Cube's `authorized_keys` at boot, so keep the matching private key handy (see SSH into a Cube below). ``` krova cubes create \ --name my-api \ --image ubuntu-24.04 \ --region us \ --ssh-key "$(cat ~/.ssh/id_ed25519.pub)" \ --vcpu 1 --ram 2 --disk 20 ``` Run `krova images` and `krova regions` to see the valid slugs. `--vcpu`, `--ram` (GB), and `--disk` (GB) default to `1`, `1`, and `10`. Optional: `--user-data` (a cloud-init script) and `--idempotency-key` (a token that dedupes retried creates for 24 hours, so a network hiccup can't create two Cubes). ## SSH into a Cube `krova ssh ` looks up the Cube's SSH host and port from the API and hands off to your system `ssh`. It uses your own SSH keys — the CLI never sees or transmits your private key. ``` krova ssh my-api # interactive shell krova ssh my-api -- uptime # run one command and exit krova ssh my-api -i ~/.ssh/my-key # pick a specific private key krova ssh my-api -L 5432:localhost:5432 # forward a local port to a service in the Cube krova ssh my-api -R 8080:localhost:80 # reverse-forward a port back to the Cube ``` Everything after `--` runs as a remote command instead of opening a shell. `-L`/`-R` are repeatable and map straight to `ssh -L`/`-R` — for example, forward Postgres out of a Cube with `-L 5432:localhost:5432` and then connect a local client to `localhost:5432` over the encrypted channel, without exposing the database publicly. **Host-key checking** stays on. When Krova Cloud returns a Cube's host keys, the CLI pins them and uses strict verification. Until then it falls back to normal SSH trust-on-first-use — you approve the fingerprint on the first connection, and it's remembered afterward. ### "Permission denied (publickey)" This is an SSH-key mismatch, not a CLI error: the Cube reached you fine, but the key you offered isn't in its `authorized_keys`. Cube only accepts the **public key you set when it was created**. Fix it by pointing `ssh` at the matching private key: ``` krova ssh my-api -i ~/.ssh/the-key-you-created-it-with # or load it into your agent once, then plain 'krova ssh my-api' works: ssh-add ~/.ssh/the-key-you-created-it-with ``` Note that plain `ssh` only auto-offers default key names (like `~/.ssh/id_ed25519`). If your key has a custom name and isn't loaded into your agent, always pass `-i`. ## Catalog Inspect what's available to build with. These are read-only and don't require picking a Cube. ``` krova regions # regions with available capacity krova images # OS image slugs you can pass to --image krova pricing # per-resource hourly pricing ``` ## Domains, snapshots & TCP mappings Manage a Cube's attached resources. Each takes a Cube name or ID and supports `--json`. ``` # Custom domains krova domains list my-api krova domains add my-api --domain app.example.com --port 8080 krova domains rm my-api # Snapshots + restore krova snapshots list my-api krova snapshots create my-api --name nightly krova snapshots restore my-api # replaces the Cube's disk krova snapshots rm my-api # TCP port mappings (expose a Cube port on the host) krova tcp list my-api krova tcp add my-api --port 5432 --whitelist 203.0.113.4/32 krova tcp rm my-api ``` ## Contexts (multiple accounts & spaces) Contexts work like `kubectl` / `aws` profiles: one per API key (and therefore per space). Switch between a personal space and a team space, or between prod and a test space, without re-authenticating each time. Both `krova login` and `krova auth login` create a context (named after your space by default, or pass `--context `). ``` krova context list # all contexts (alias: krova ctx ls) krova context current # the active one krova context use team-prod # switch krova context rename old new krova context delete team-prod krova whoami # current context, space, key, and base URL ``` Override the active context for a single command with `--context `. ## Webhooks `krova webhooks listen` runs a local HTTP receiver that verifies each delivery's signature and pretty-prints the event — handy for developing against Krova Cloud webhooks without deploying. ``` krova webhooks listen --secret "$KROVA_WEBHOOK_SECRET" # customize the bind address and path: krova webhooks listen --addr 127.0.0.1:4666 --path /hooks --secret "$KROVA_WEBHOOK_SECRET" ``` The signing secret can also come from the `KROVA_WEBHOOK_SECRET` environment variable. Deliveries with a bad or missing signature are rejected and reported, so you can trust every event you see. ## Scripting & automation Pass `--json` to any command to get machine-readable output instead of a table — pipe it into `jq` or a script. ``` krova list --json | jq -r '.[] | select(.state=="running") | .name' ``` For CI and headless environments, configure the CLI entirely from the environment — no interactive login needed: - `KROVA_API_KEY` — the API key to use. - `KROVA_SPACE_ID` — the default space (usually auto-resolved from the key). - `KROVA_CONTEXT` — select a stored context by name. - `KROVA_BASE_URL` — override the API base URL. - `KROVA_WEBHOOK_SECRET` — default secret for `webhooks listen`. The equivalent per-command flags — `--api-key`, `--space`, `--context`, `--base-url`, `--json`, and `--timeout` (default `30s`) — are global and work on every command. Precedence is flag → environment variable → stored context. ## Troubleshooting - **Permission denied (publickey)** — SSH key mismatch. See SSH into a Cube — pass `-i` with the key the Cube was created with. - **"SSH info isn't available on this server yet"** — your CLI is newer than the server. Nothing to do on your end; it resolves once Krova Cloud is on a current release. - **401 / request rejected** — the API key is missing, revoked, or scoped to a different space. Run `krova auth status` to see what's in effect, or `krova login` again. - **Command not found** — run `krova --help` (or just `krova`) to list the exact subcommands; not every group has a `list` (for example, webhooks only has `listen`). ## Next steps - [API keys](https://krova.cloud/docs/api-keys) — create and scope the key the CLI authenticates with. - [Cubes](https://krova.cloud/docs/cubes) — sizing, power off/start, and how billing works. - [REST API reference](https://krova.cloud/docs/api) — the same API the CLI is built on, for when you want raw HTTP or another language. - [Developer tools](https://krova.cloud/developers) — the SDK, MCP server, webhook verifier, and n8n node. ============================================================================== URL: https://krova.cloud/docs/mcp ============================================================================== # MCP server Run the Krova Cloud MCP server so Claude, Cursor, and any MCP client can provision and manage Cubes in natural language. `@krovacloud/mcp` is a [Model Context Protocol](https://modelcontextprotocol.io) server that exposes Krova Cloud as a set of tools an AI agent can call. Ask Claude to "spin up a 2-vCPU Ubuntu cube in us", "list my running cubes", or "power off the idle ones", and it drives the Krova Cloud API for you. It's a thin, fully typed bridge over the [TypeScript SDK](https://krova.cloud/docs/sdk), published on npm as [`@krovacloud/mcp`](https://www.npmjs.com/package/@krovacloud/mcp). ## Quickstart The fastest way to try it — no install, no clone. The server speaks MCP over **stdio**, so you normally don't run it by hand; your MCP client launches it with this command. ``` KROVA_API_KEY=kro_... npx -y @krovacloud/mcp ``` You need a Krova Cloud API key — create one per space from **Settings → API keys** in the dashboard (see [API keys](https://krova.cloud/docs/api-keys)). Set `KROVA_SPACE_ID` too if you want the Cube tools to default to one space. ## Configuration The server is configured entirely through environment variables. - `KROVA_API_KEY` **(required)** — your `kro_…` key, scoped to a space. - `KROVA_SPACE_ID` — a default space id, so Cube tools can omit `spaceId`. - `KROVA_BASE_URL` — override the API base URL (defaults to the Krova Cloud production API). ## Connect your client Every client uses the same launch command (`npx -y @krovacloud/mcp`) and the same environment variables. ### Claude Desktop Open **Settings → Developer → Edit Config** (or edit `claude_desktop_config.json` directly) and add: ``` { "mcpServers": { "krova": { "command": "npx", "args": ["-y", "@krovacloud/mcp"], "env": { "KROVA_API_KEY": "kro_your_api_key_here", "KROVA_SPACE_ID": "space_optional_default" } } } } ``` Restart Claude Desktop; the Krova Cloud tools appear under the tools (🔨) menu. ### Claude Code Add the server with one command: ``` claude mcp add krova \ --env KROVA_API_KEY=kro_your_api_key_here \ --env KROVA_SPACE_ID=space_optional_default \ -- npx -y @krovacloud/mcp ``` Or check a `.mcp.json` into your project root (shared with your team) using the same `mcpServers` shape as above, then verify with `claude mcp list`. ### Cursor Create `.cursor/mcp.json` in your project (or `~/.cursor/mcp.json` for all projects) with the same `mcpServers` config, then enable the **krova** server in **Cursor Settings → MCP**. ### Any other MCP client Any client that speaks MCP over stdio works — launch `npx -y @krovacloud/mcp` with the environment variables set. The config shape above is portable across VS Code (Copilot), Windsurf, Zed, and custom agents built on the MCP SDK. ## Tools 19 tools cover the Cube lifecycle, the catalog, and a Cube's attached resources. Every tool's `spaceId` is optional when `KROVA_SPACE_ID` is set. - **Cubes** — `list_cubes`, `get_cube`, `create_cube`, `power_off_cube`, `wake_cube`, `restart_cube`, `delete_cube`, `restore_cube`. - **Catalog** — `list_regions`, `list_images`, `get_pricing`. - **Domains** — `list_domains`, `create_domain`, `delete_domain`. - **Snapshots** — `list_snapshots`, `create_snapshot`, `delete_snapshot`. - **TCP mappings** — `list_tcp_mappings`, `create_tcp_mapping`, `delete_tcp_mapping`. Every tool advertises MCP **annotations**: the read tools are marked read-only, while the billable/irreversible ones — `create_cube`, all the `delete_*` tools, and `restore_cube` (which replaces a Cube's disk) — are marked **destructive**. Most clients prompt for confirmation before a destructive tool — **keep that confirmation on**, since an LLM driven by untrusted content could be induced to call one. ## Security Your API key is scoped to a single space and never leaves your machine — the server runs locally and talks directly to the Krova Cloud API. Never commit the key or paste it into logs, issues, or chats; rotate any key you believe has been exposed. ## Next steps - [API keys](https://krova.cloud/docs/api-keys) — create the key the server authenticates with. - [TypeScript SDK](https://krova.cloud/docs/sdk) — the typed client this server is built on. - [Cubes](https://krova.cloud/docs/cubes) — what the tools create, and how power-off billing works. ============================================================================== URL: https://krova.cloud/docs/webhooks ============================================================================== # Webhooks Receive Krova Cloud webhook events and verify signatures with @krovacloud/webhook — HMAC-SHA256, constant-time comparison and replay protection. Krova Cloud can deliver **outbound webhooks** to a URL you control when things happen to your Cubes (for example `cube.running` or `cube.created`). Every delivery is **signed**, so you can prove it genuinely came from Krova Cloud and was not tampered with or replayed. The [`@krovacloud/webhook`](https://www.npmjs.com/package/@krovacloud/webhook) package performs that verification for you — HMAC-SHA256, constant-time comparison, and a replay window, with **zero runtime dependencies** (built on `node:crypto`). ## Install ``` npm install @krovacloud/webhook # or: pnpm add @krovacloud/webhook / yarn add @krovacloud/webhook ``` Requires Node.js 18 or newer. Ships both ESM and CommonJS, types bundled. ## Create a webhook endpoint Register the endpoint over the API (or with the SDK's [`client.raw`](https://krova.cloud/docs/sdk#raw)), choosing which events to receive. Krova Cloud returns a **signing secret** — store it as an environment variable; you'll need it to verify deliveries. ``` const { data } = await krova.raw.POST("/spaces/{spaceId}/webhooks", { params: { path: { spaceId: "space_123" } }, body: { url: "https://example.com/webhooks/krova", events: ["cube.running"] }, }); ``` Prefer to develop locally without deploying? The [CLI](https://krova.cloud/docs/cli)'s `krova webhooks listen` runs a local receiver that verifies each delivery and pretty-prints the event. ## How a delivery is signed On every delivery, Krova Cloud sends these headers alongside the raw JSON body: - `X-Krova-Signature` — e.g. `t=1700000000,v1=3f8a…` (signed timestamp + HMAC-SHA256). - `X-Krova-Event` — the event name, e.g. `cube.created`. - `X-Krova-Delivery` — a unique id for this delivery. The signature is computed as: ``` timestamp = floor(Date.now() / 1000) signed = `${timestamp}.${rawBody}` // "t.body", literal dot separator v1 = HMAC_SHA256(secret, signed) // lowercase hex X-Krova-Signature: t=,v1= ``` Verification recomputes the HMAC, compares it to `v1` in **constant time**, and rejects the request if the timestamp is outside a **300-second** (5-minute) window in either direction — which stops replays. Unknown signature fields are ignored, so future `v2`/`v3` schemes stay backward compatible. **The raw body matters.** The signature is over the exact bytes Krova Cloud sent. If your framework parses the JSON and you re-serialize it, the bytes — and therefore the signature — will differ. Always verify against the **raw** request body. ## Express Mount `express.raw()` on the webhook route so the handler receives the raw `Buffer`, then use the `krovaWebhook` middleware. On a bad signature, stale timestamp, or missing header it responds `401` and does not call `next()`. ``` import express from "express"; import { krovaWebhook } from "@krovacloud/webhook"; const app = express(); app.post( "/webhooks/krova", express.raw({ type: "application/json" }), // REQUIRED: gives us the raw body krovaWebhook({ secret: process.env.KROVA_WEBHOOK_SECRET! }), (req, res) => { // Signature already verified. Now it's safe to parse. const payload = JSON.parse(req.body.toString("utf8")); const { event, delivery, timestamp } = req.krovaWebhook!; console.log(`Received ${event} (${delivery}) signed at ${timestamp}`); res.status(200).json({ received: true }); }, ); ``` ## Next.js Route Handler Read the raw body with `await req.text()` and pass the `Headers` straight to `verifyKrovaRequest`. ``` // app/api/webhooks/krova/route.ts import { verifyKrovaRequest } from "@krovacloud/webhook"; export async function POST(req: Request) { const rawBody = await req.text(); // raw, un-parsed body const result = verifyKrovaRequest({ payload: rawBody, headers: req.headers, // matched case-insensitively secret: process.env.KROVA_WEBHOOK_SECRET!, }); if (!result.valid) { return Response.json({ error: result.reason }, { status: 401 }); } const payload = JSON.parse(rawBody); // result.event / result.delivery / result.timestamp are verified return Response.json({ received: true }); } ``` ## Framework-agnostic verify Use `verifyKrovaWebhook` when you have the raw body and the signature header in hand (any framework, serverless, or a queue consumer). It never throws — it returns a result you branch on. ``` import { verifyKrovaWebhook } from "@krovacloud/webhook"; const result = verifyKrovaWebhook({ payload: rawBody, // string or Buffer — the raw body signature: req.headers["x-krova-signature"] ?? "", secret: process.env.KROVA_WEBHOOK_SECRET!, // toleranceSeconds: 300, // optional, defaults to 300 (5 min) }); if (!result.valid) { // result.reason: "invalid_signature" | "timestamp_out_of_tolerance" | "malformed_header" throw new Error(`Krova webhook rejected: ${result.reason}`); } // Safe to trust and process the payload now. ``` Prefer exceptions? `verifyKrovaWebhookOrThrow` throws a `KrovaWebhookError` (with a `.reason`) instead of returning a result. There's also a `verifyKrovaRequest` that accepts a whole request's `headers` (a `Headers` instance, a plain object, or anything with `.get()`) and pulls the event and delivery id out for you — ideal for Next.js, Fastify, and `node:http`. ## API summary - `verifyKrovaWebhook(options)` → non-throwing `{ valid, reason?, timestamp? }`. - `verifyKrovaWebhookOrThrow(options)` → throws `KrovaWebhookError` on failure. - `verifyKrovaRequest({ payload, headers, secret })` → framework-agnostic; returns the verified `event` / `delivery` too. - `krovaWebhook({ secret })` → Express middleware. - `parseSignatureHeader` / `computeSignature` → low-level helpers for tests and custom tooling. ## Next steps - [CLI](https://krova.cloud/docs/cli) — `krova webhooks listen` to test deliveries locally. - [TypeScript SDK](https://krova.cloud/docs/sdk) — register and manage webhook endpoints over the API. - [REST API reference](https://krova.cloud/docs/api) — the webhook endpoints and event payloads. ============================================================================== URL: https://krova.cloud/docs/n8n ============================================================================== # n8n node Provision and manage Krova Cloud Cubes from your n8n workflows with the n8n-nodes-krova community node — no glue code, no HTTP Request nodes. [`n8n-nodes-krova`](https://www.npmjs.com/package/n8n-nodes-krova) is the official [n8n](https://n8n.io) community node for Krova Cloud. It wraps the Krova Cloud REST API so you can create, power off, start, list, and delete Cubes, manage domains, snapshots, and TCP mappings, and query the catalog (regions, images, pricing) from a workflow — no glue code and no HTTP Request nodes. ## Install Install from within n8n — no CLI, no server restart: - Open **Settings → Community Nodes** and select **Install**. - Enter the package name `n8n-nodes-krova`. - Acknowledge the community-node risk prompt and select **Install**. The **Krova Cloud** node appears in the node panel immediately. For self-hosted or manual setups, see the official [community-nodes installation guide](https://docs.n8n.io/integrations/community-nodes/installation/). ## Add your credential Every operation authenticates with a **Krova Cloud API** credential. - Create an API key per space from **Settings → API keys** in the dashboard (see [API keys](https://krova.cloud/docs/api-keys)) — it looks like `kro_…`. - In n8n, add a new **Krova Cloud API** credential and paste the key into **API Key**. It's sent as the `X-API-KEY` header and stored encrypted by n8n. - Leave **Base URL** at `https://krova.cloud/api/v1` (override only for self-hosted or test endpoints). - Click **Test** — n8n calls `GET /space` (an authenticated endpoint) to confirm the key is valid and the endpoint is reachable. ## Operations ### Cube Cubes are scoped to a **space**, so every Cube operation takes a **Space ID**. - **List** — all Cubes in a space. - **Get** — a single Cube by ID. - **Create** — Space ID, Name, Image, SSH Public Key, vCPU, RAM (GB), Disk (GB); optional Region and User Data. - **Power off** — power off a running Cube (preserves data, stops compute billing). - **Start** — start a stopped Cube. - **Delete** — delete a Cube (asynchronous). **Create field notes:** *Image* is a slug or ID from **Catalog → Get Images**; *SSH Public Key* is written to the login user's `~/.ssh/authorized_keys` at boot (must start with `ssh-ed25519`, `ssh-rsa`, `ecdsa-sha2-*`, …); *vCPU / RAM / Disk* are sent as nested `resources`; *Region* is optional (leave empty to auto-select); *User Data* is an optional cloud-init script (max 16 KB). ### Domain Custom domains for a Cube (space-scoped). - **Create** — attach a custom domain to a Cube. - **List** — all domains in a space. - **Delete** — remove a domain. ### Snapshot Point-in-time Cube snapshots (space-scoped). - **Create** — take a manual snapshot of a Cube (counts against your tier's manual-snapshot cap). - **List** — snapshots for a Cube. - **Restore** — roll a Cube back to a snapshot. - **Delete** — remove a manual snapshot. ### TCP Mapping Expose a TCP port on a Cube through the edge (space-scoped). - **Create** — map a public port to a Cube port. - **List** — mappings in a space. - **Delete** — remove a mapping. ### Catalog Public read endpoints — the API key is sent but not required. - **Get Regions** — regions with available capacity. - **Get Images** — available OS images. - **Get Pricing** — per-resource hourly rates and volume tiers. Each operation returns the raw Krova Cloud API response, ready to reference downstream with n8n expressions. ## Example: provision by day, power off by night Pay only for the hours you use, driven entirely from n8n: - **Schedule Trigger** (`0 8 * * *`) → **Krova Cloud** (Catalog → Get Images) to resolve the image slug. - **Krova Cloud** (Cube → Create) with the Space ID, a Name, the image slug, your SSH Public Key, and vCPU / RAM / Disk. The response contains the new Cube's ID. - A second **Schedule Trigger** (`0 20 * * *`) → **Krova Cloud** (Cube → List) → **Filter** → **Krova Cloud** (Cube → Power off) on each idle Cube ID. Because a stopped Cube keeps its disk but stops compute billing, this pattern gives you an ephemeral-by-day, zero-compute-by-night box. Swap **Power off** for **Delete** to tear it down instead. ## Compatibility Requires an n8n instance with the community-nodes feature enabled. Built and tested against `n8n-workflow` 2.x and Node.js 20.15+. ## Next steps - [API keys](https://krova.cloud/docs/api-keys) — create the key the credential uses. - [Cubes](https://krova.cloud/docs/cubes) — sizing, power off/start, and billing. - [TypeScript SDK](https://krova.cloud/docs/sdk) — the same operations in code, for logic beyond what a workflow expresses.