Quickstart

You can deploy a server with a single curl command and an API key.

One base, one format

Every endpoint lives under /api/v1, and every request and response body is JSON. Send your key as a bearer token in the Authorization header.

Deploy your first server

Create an API key

In the console, open Settings → API keys and create a key with the full scope (a read key can list but can't deploy). The token is shown once — copy it somewhere safe. Full details are in the Authentication guide.

Set your base URL and auth header

All calls go to the /api/v1 base path, with your key on every request. Export it once so the examples below just work:

export EKIRE_API_KEY="ek_your_key_here"
export EKIRE_API="https://console.ekire.net/api/v1"

Ekire keys are prefixed ek_. The Authorization: Bearer … header is the only auth you need; there are no cookies or sessions.

List your servers

Start with a read. GET /instances returns your servers as an items array:

curl "$EKIRE_API/instances" \
  -H "Authorization: Bearer $EKIRE_API_KEY"

A trimmed response:

{
  "items": [
    {
      "id": "b3f1c0a2-8e7d-4b21-9a6c-2f5e1d0a7c44",
      "vmid": 1042,
      "name": "web-01",
      "status": "running",
      "vcpus": 1,
      "memoryMb": 1024,
      "diskGb": 10,
      "osTemplate": "ubuntu-22.04",
      "planId": "nano",
      "monthlyCents": 500,
      "ipAddress": "203.0.113.42",
      "tags": [],
      "regionId": "de-fra",
      "regionName": "Frankfurt",
      "createdAt": "2026-07-19T09:14:22.000Z"
    }
  ]
}

Create a server

Deploy with POST /instances. Only two fields are required: planId (one of nano, small, medium) and name (letters, numbers, and hyphens). Your wallet needs at least an hour of runway for the plan you pick — below that the call returns 400 insufficient_balance:

curl -X POST "$EKIRE_API/instances" \
  -H "Authorization: Bearer $EKIRE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "planId": "nano",
    "name": "api-demo"
  }'

Everything else is optional — pass any of these to customize the deploy:

Field	Type	Purpose
`regionId`	`string`	Where to deploy — must be an open one. Omit to land in any open region with capacity.
`osImageId`	`string`	OS image to install. Omit for the default image.
`sshKey`	`string`	A public SSH key to install at first boot.
`sshKeyIds`	`string[]`	IDs of saved SSH keys to install.
`password`	`string`	Root password for console login (min 10 chars, letter + number).
`tags`	`string[]`	Labels for organizing and filtering servers.

A region that's listed but not open yet is refused with region_coming_soon or region_out_of_stock rather than silently placed elsewhere — see Region waitlist. GET /regions marks those with available: false.

A successful deploy returns 201 Created with the new server (it starts in provisioning):

{
  "id": "a91d7e60-1c4b-4d0e-8f2a-6b3c9e2d5f10",
  "vmid": 0,
  "name": "api-demo",
  "status": "provisioning",
  "planId": "nano",
  "vcpus": 1,
  "memoryMb": 1024,
  "diskGb": 10,
  "ipAddress": "203.0.113.57",
  "createdAt": "2026-07-19T10:02:57.000Z"
}

vmid is 0 here — the hypervisor assigns it during provisioning, so read it from a later GET /instances/{id} rather than the create response.

Poll for readiness

The IP is assigned immediately, but provisioning takes a moment. Re-fetch GET /instances/{id} until status flips to running, then you can SSH in.

Explore the rest

You've now read and written over the API. Every other resource — volumes, DNS, firewalls, backups, SSH keys — follows the same shape. Browse them all in the interactive API reference.

API reference

Every endpoint and field, generated from the live OpenAPI schema — try calls in the browser.

Authentication

What separates a read key from a full one, and how to store and rotate keys safely.

Deploy a server

Prefer the console? Walk through deploying your first server click by click.

Quickstart

Deploy your first server

Next