Documentation

LiteVPS — Platform Guide

LiteVPS gives AI agents and developers on-demand KVM virtual machines they can control directly via REST API. This page covers the concepts, quick-start, and links to the full API reference.

On this page

Concepts

VPS (Virtual Private Server) — a KVM virtual machine with its own OS, CPU slices, RAM, and disk. Each VM gets a private IP on your account's network and outbound internet access. VMs are managed entirely through the REST API or the web portal.

Plans — fixed-spec tiers (Nano through Large) that define vCPU, RAM, disk, and price. You select a plan at creation time and can change it later via the API or portal. See Pricing for the full plan table.

Templates — base OS images used to provision new VMs. The default template is a minimal Debian/Ubuntu image with the LiteVPS guest agent pre-installed.

Guest agent — a small process running inside each VM that receives /exec commands from the API host. It does not require SSH to be configured — commands are sent over an internal serial channel.

Quick start

Four REST calls get you from zero to running code inside a VM:

Step 1 — Authenticate
POST https://api.litevps.dev/api/auth/login
{ "email": "you@example.com", "password": "..." }
← { "token": "eyJ..." }

The returned JWT is valid for 30 days. Pass it as Authorization: Bearer <token> on all subsequent requests. You can also generate long-lived API tokens in the portal under API Tokens.

Step 2 — Pick a plan
GET https://api.litevps.dev/api/pricing
← { "plans": [{ "id": "...", "name": "Nano", "vcpus": 1, ... }] }

No auth required. Copy the id of the plan you want to use in step 3.

Step 3 — Create a VM
POST https://api.litevps.dev/api/vps
Authorization: Bearer eyJ...
{ "name": "my-task", "plan_id": "<id from step 2>" }
← { "id": "d4e1...", "state": "running", "customer_ip": "10.0.4.7" }

The VM is ready in roughly 8–15 seconds. The response includes the VM's id — save it for the next steps.

Step 4 — Run code, then destroy
POST https://api.litevps.dev/api/vps/d4e1.../exec
{ "command": "python3 -c 'print(2+2)'" }
← { "stdout": "4\n", "exit_code": 0, "duration_ms": 312 }

DELETE https://api.litevps.dev/api/vps/d4e1...
← 204 No Content  (billing stops, resources released)

Running commands with /exec

POST /api/vps/:id/exec runs a shell command inside the VM and returns its output synchronously. Commands run as root by default. No SSH key setup or port exposure is needed.

Request body:

{
  "command": "apt-get install -y python3 && python3 script.py",
  "timeout_seconds": 120   // optional, default 30
}

Response:

{
  "stdout": "result: 42\n",
  "stderr": "",
  "exit_code": 0,
  "duration_ms": 1823
}

Commands run in a bash shell. You can chain commands with &&, pipe output, install packages, download files, write to disk — everything a normal root shell supports. State persists across exec calls within the same VM's lifetime.

Billing

Usage is metered per minute. Every minute a VM exists in running or stopped state, one minute of time is charged at the plan's hourly rate ÷ 60. A stopped VM still holds its disk allocation and a reserved slot on the host, so charges continue. Destroy the VM to stop billing entirely. Daily usage is rolled up into a single ledger entry so your billing history stays clean.

The monthly price shown on the Pricing page is the hard cap — it is the cost of running that VM non-stop for 30 days. Short-lived workloads cost proportionally less.

Accounts use a prepaid balance. Top up via credit card from the Billing page. Enable Auto top-up to automatically recharge when your balance falls below a threshold — useful for long-running agents.

Check your current balance and transaction history at any time via GET /api/billing/balance and GET /api/billing/history.

Network & connectivity

Each VM gets a private IP address (customer_ip field) on your account's internal network. VMs within the same account can reach each other over this network.

Outbound internet access is included on all plans — your VMs can reach external APIs, download packages, clone repos, etc.

Inbound SSH is available on every VM via a dedicated port on the host's public IP. The port is shown in your portal dashboard (ssh_port field). Connect with: ssh -p <ssh_port> root@<host_ip>.

Inbound HTTP/HTTPS is available via a unique proxy subdomain automatically assigned to each VM: <proxy_subdomain>.proxy.tlp.computer. Requests on port 80/443 are forwarded to your VM's internal IP. VMs do not get a dedicated public IPv4 — all inbound access is via SSH port forwarding or the proxy subdomain.

Snapshots

Snapshots capture the full disk state of a running VM. Use them to:

  • Checkpoint an agent's environment mid-task and restore it after a failure.
  • Branch execution — restore the same snapshot into multiple VMs to run parallel experiments.
  • Preserve a configured environment so you don't have to re-install dependencies each run.

Manage snapshots via POST /api/vps/:id/snapshots, GET /api/vps/:id/snapshots, and POST /api/vps/:id/snapshots/:name/restore. See the API reference for full details.

API reference

The full API reference documents every endpoint with request/response schemas, examples, and error codes. It is designed to be read by both humans and language models.

View full API reference →