If you drive infrastructure from code rather than a control panel, the only latency that matters is the gap between POST /instances and a box that answers SSH. On our fleet that gap runs a 47-second median. This is a NOC note on how we deploy a VPS via API in seconds at NODED.CLOUD, how hourly billing to the second changes what "cheap" means, and the Terraform and CLI workflow that turns ephemeral boxes from a novelty into a habit.
The API surface: one call to a running box
The API lives at api.noded.cloud/v1. You authenticate with a token, pick a plan and one of 41 OS templates, hand us your SSH public key, and we hand back an instance ID plus an IPv4 and IPv6 address. There is no ticket, no manual approval, no "provisioning" state that sits for ten minutes. Every instance is a real KVM guest with root, not a container pretending to be one, so the box you script against behaves exactly like the box you would have clicked into on our VPS hosting plans.
The lifecycle is deliberately small: create, read, power, destroy. That is the whole point of programmatic provisioning — the fewer verbs, the fewer ways your automation can wedge. A create returns immediately with the instance record; you poll status (or watch for the SSH port to open, which is what most of our customers actually do) and you are in. Median time from create to a box that answers SSH is 47 seconds across our POPs.
Why "deploy in seconds" and "hourly" belong in the same sentence
Sub-minute deploys are a party trick unless the billing model rewards you for tearing things down. Ours does. VPS instances are billed hourly, to the second, starting at EUR 0.006/hr for the 2GB tier. A box you spin up for a 20-minute integration run costs you 20 minutes — not a rounded-up hour, not a daily minimum, not a monthly commit you forgot to cancel. That is the mechanic that makes a 47-second deploy pay for itself: fast up plus honest-down is what lets you treat compute as disposable.
Concretely, the pattern we see from IaC shops looks like this: a CI job creates three boxes at the start of a test matrix, runs the suite in parallel, and destroys all three when the runner exits. Total wall-clock is maybe 15 minutes. Billed to the second, that is a rounding error, and there is nothing left running overnight to surprise you on the invoice. Wiring it into a pipeline is two calls — a create at the start of the job, a destroy by instance ID when the runner tears down — and the hourly meter does the rest.
The Terraform and CLI workflow
You do not need to hand-roll HTTP calls. The two workflows we recommend:
- CLI / shell for one-offs. A single
curlagainstapi.noded.cloud/v1with a JSON body creates a box; a second call by instance ID destroys it. Good for scratch work, reproduction environments, and "I need a clean Debian box for ten minutes." - Terraform for anything that outlives one command. Model the instance as a resource, keep the SSH key and OS template as variables, and let
terraform apply/terraform destroyown the lifecycle. Because our create call is synchronous and fast, plans converge quickly instead of sitting in a "still creating" loop.
The rule we give people building Terraform on a European footprint: keep your state describing the box (plan, region, template, key) and let the hourly meter handle the economics. You are never punished for a destroy, so aggressive teardown is the correct default, not a risk.
What you get on every instance
| Property | What the API gives you |
|---|---|
| Deploy time | 47s median, create call to answering SSH |
| Billing | Hourly, to the second, from EUR 0.006/hr |
| OS templates | 41, selectable at create time |
| Access | Root SSH on a real KVM guest |
| Networking | IPv4 + IPv6 per instance, 1 Gbps unmetered symmetric |
| Storage | NVMe |
| DDoS | 1 Tbps mitigation, always on, no toggle |
Every instance sits on our own network — AS60982, 13 European POPs, sub-5ms intra-EU — so a box you provision in code is on the same backbone as everything else we run. The network page has the carrier and IX detail if latency budgets matter to your placement decisions.
Where the API stops being the right tool
Honesty from the rack: not everything wants to be ephemeral. If you are running a stateful database, a persistent build cache, or anything where the box is the workload rather than a disposable runner, hourly churn is the wrong pattern and a longer-lived instance is cheaper and calmer. And if you have outgrown virtualization entirely — you want dedicated cores, your own /29, or BGP on AS60982 — that is a dedicated server conversation, not an API-churn one. The API is for elastic, disposable capacity; use it where elasticity is the actual requirement.
How Noded Can Help
We built the VPS API for people who never wanted to see a dashboard. Point your Terraform provider or your CLI at api.noded.cloud/v1, pass a plan and one of our 41 templates, and you have root on a KVM box in a median of 47 seconds — billed hourly to the second so aggressive teardown costs you nothing. It is all on our own AS60982 network with 1 Tbps of DDoS protection on every instance by default. Browse the tiers on our VPS hosting page, grab a token, and script your first create. If you are wiring it into a pipeline, the loop is just a create call at job start and a destroy by instance ID when the runner exits.
FAQ
How fast can I deploy a VPS via API?
Our median is 47 seconds from the create call to a box that answers SSH. You get an instance ID back immediately and poll status (or watch for the SSH port) while the KVM guest boots.
How is API-provisioned VPS billing calculated?
Hourly, billed to the second, starting at EUR 0.006/hr for the 2GB tier. A box you create and destroy inside 20 minutes costs you 20 minutes — there is no daily minimum and no monthly commitment, which is what makes fast teardown worthwhile.
Can I use Terraform to provision VPS instances in Europe?
Yes. Model the instance as a Terraform resource pointed at api.noded.cloud/v1, keep your SSH key and OS template as variables, and let apply and destroy own the lifecycle. Because our create call is synchronous and fast, plans converge quickly instead of hanging in a "creating" state.
Do API-created instances get root access and their own IPs?
Every instance is a real KVM guest with root SSH, an IPv4 and an IPv6 address, NVMe storage, and 1 Gbps unmetered symmetric networking. There is no difference between a box you create by API and one you order any other way.
Which operating systems can I choose at create time?
41 OS templates are selectable in the create call. You pass the template identifier in the request body alongside the plan and your SSH key.