Provision cloud servers from your own code with our VPS API.
The NODED.CLOUD Customer API is REST over HTTPS with JSON in and out. Order VPS and dedicated servers, pass cloud-init at order time, capture images and pay from credit, all from a script. Bind a key to one project and your staging jobs can never touch production. It is a public beta: stable enough to build on, but endpoints and response shapes may still change.
Two calls to your first answer.
Create a key in the client panel under Profile → API Keys. It is shown once, so put it in your secret store before you close the dialog.
Send it as Authorization: Bearer fbk_… to https://my.noded.cloud/api/v1. Every response is JSON in a { success, data } envelope.
Make GET / your first call. It tells you who the key belongs to, which scopes it carries and which project it is bound to, so a misconfigured deploy fails at start-up instead of halfway through.
# 1 · who is this key? (the right first call)
curl -s https://my.noded.cloud/api/v1/ \
-H "Authorization: Bearer fbk_…"
# → { "success": true, "data": { "version": "1",
# "key": { "scopes": ["read", "services"], "project": null },
# "rate_limit": { "limit": 1000, "remaining": 999, … } } }
# 2 · list your VPS
curl -s https://my.noded.cloud/api/v1/vps \
-H "Authorization: Bearer fbk_…"Production and staging, never in the same blast radius.
Group your services into projects: production, staging, one per client, whatever your environments are. Then bind a key to one project when you create it. That key sees and changes only its own project, so a staging pipeline cannot list, reboot or delete a production server, whatever it decides is an orphan.
Billing does not split. The account still gets one invoice and one credit balance, however many projects you run.
- In scope
- Services, orders, custom images and SSH keys
- Binding
- Chosen when the key is created, in Profile → API Keys
- Outside it
- Invisible to the key: a production server does not exist from staging’s point of view
Order a cloud server once, even when CI retries.
Idempotency-Key on orders
Send your own key with POST /orders. Retry the same create and you get the original order back instead of a second server.
cloud-init at order time
Pass first-boot user-data (a script or a #cloud-config document) and SSH keys in the order itself, so the server comes up already configured.
Availability per location
Ask whether a product can be built right now, and where, before you place the order.
Hourly or monthly
Hourly services are charged hourly from your credit. Monthly orders create an invoice or proforma that you pay from credit with one more call.
# can this product be built right now, and where?
curl -s https://my.noded.cloud/api/v1/products/<id>/availability \
-H "Authorization: Bearer fbk_…"
# order it, once, with first-boot config
curl -s https://my.noded.cloud/api/v1/orders \
-H "Authorization: Bearer fbk_…" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: ci-run-4821" \
-d '{
"productId": "<id from GET /products>",
"billingCycle": "hourly",
"hostname": "runner-4821.example.com",
"configOptions": {
"os_image_id": "<id from GET /products/{id}>",
"user_data": "#cloud-config\npackages: [docker.io]",
"ssh_key_ids": ["<id from GET /ssh-keys>"]
}
}'
# same Idempotency-Key again → the same order back, never a second oneReal paths, no hand-waving.
https://my.noded.cloud/api/v1Limits you can read before you hit them.
- Scopes
- read, services, orders, billing, destructive. Chosen at creation, never widened later
- Per key
- Optional IP allowlist and expiry
- Team keys
- Limited by the member’s own permissions, checked again on every request
- Rate limit
- 1,000 requests per hour per key by default, in X-RateLimit-* headers, Retry-After on 429
- Cool-downs
- Per server: power 10/min, reinstall 1 per 5 min, password reset 1 per 10 min. Orders 30 per 15 min
Refusals carry a machine-readable code, for example RATE_LIMITED, PAYMENT_REQUIRED or CONFLICT.
HTTP/1.1 429 Too Many Requests
Retry-After: 1834
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
{ "success": false, "code": "RATE_LIMITED", "error": "…" }No official SDKs. A contract and a guide instead.
We would rather say it plainly: there are no official SDKs and no Terraform provider. What you get is an OpenAPI 3.0 contract to generate a client from, and a plain-Markdown guide written so that coding assistants and AI agents can read it and drive the API correctly.
- Rendered docsmy.noded.cloud/api/v1/docs
- OpenAPI 3.0 specmy.noded.cloud/api/v1/openapi.json
- Markdown guidemy.noded.cloud/api/v1/guide.md
# hand the guide to your coding assistant or agent
curl -s https://my.noded.cloud/api/v1/guide.md -o NODED_API.md
# or generate a typed client from the contract
curl -s https://my.noded.cloud/api/v1/openapi.json -o openapi.jsonYour own servers, or your customers’?
Automate your own account
Everything on this page: order, run and pay for your own servers from scripts, CI and agents.
- AuthBearer fbk_…
- KeysProfile → API Keys
- Isolationproject-bound keys
- Statuspublic beta
Sell servers under your brand
For platforms that sell VPS and dedicated servers to their own customers, at wholesale, under their own name.
- AuthBearer rsk_… + HMAC
- Keyscustomer-bound
- Eventssigned webhooks
- Accessby application
Things people ask.
Get a key and ask it who it is.
Profile → API Keys in the client panel. Pick the smallest scopes that do the job, bind it to a project, and start with GET /.