Use Case
Programmatic VM provisioning — infrastructure via API, not config files.
Traditional infrastructure-as-code tools were designed for human operators managing long-lived environments. They require browser-based auth, state files, plan/apply cycles, and provider plugins. AI agents need something simpler: a single REST API call that goes from zero to running VM.
Agent Cloud is a programmatic VM provisioning API built for exactly this. No signup forms, no Terraform state, no human authentication — just HTTP requests and JSON responses.
What programmatic provisioning means
Programmatic provisioning is the ability to create, configure, and destroy infrastructure entirely through code — no dashboards, no manual steps, no interactive wizards. The entire lifecycle is controlled by API calls that any script, CI pipeline, or AI agent can make.
For AI agents, this is essential. An agent cannot click through a cloud console or paste a 2FA code. It needs an API that accepts a POST request and returns a usable machine. Agent Cloud provides that API with a purpose-built flow: sign up programmatically, receive an API key instantly, and provision VMs with a single call.
The full provisioning flow
Five steps, all programmatic, all via REST. Here is each step with the exact API call.
Step 1: Sign up
The agent creates its own account. No email verification, no OAuth redirect, no human approval. The response includes a sandbox API key with safe default limits.
# 1. Agent signs up — no browser, no OAuth, no human
curl -X POST https://api.asiagent.cloud/v1/agent/signup \
-H "Content-Type: application/json" \
-d '{"agent_name": "ci-runner-bot"}'
# Response:
# {
# "api_key": "sk-sandbox-abc123...",
# "tier": "sandbox",
# "limits": { "max_instances": 2, "expires_hours": 4 }
# }Step 2: Provision a VM
One POST request. Specify the OS, size, and optional region. The API returns an instance ID and SSH connection details immediately.
# 2. Provision a VM — one POST, no Terraform plan/apply cycle
curl -X POST https://api.asiagent.cloud/v1/instances \
-H "Authorization: Bearer sk-sandbox-abc123..." \
-H "Content-Type: application/json" \
-d '{
"os": "ubuntu-22.04",
"size": "micro",
"region": "nz-hlz-1"
}'
# Response:
# {
# "id": "inst_7xKq2...",
# "status": "provisioning",
# "ssh_host": "inst-7xkq2.asiagent.cloud",
# "ssh_user": "agent"
# }Step 3: Poll until ready
The instance takes around 60 to 120 seconds to provision. Poll the instance endpoint until the status changes to "running".
# 3. Poll until ready
curl https://api.asiagent.cloud/v1/instances/inst_7xKq2... \
-H "Authorization: Bearer sk-sandbox-abc123..."
# Response (after ~90 seconds):
# {
# "id": "inst_7xKq2...",
# "status": "running",
# "ssh_host": "inst-7xkq2.asiagent.cloud",
# "ssh_user": "agent",
# "ssh_port": 22
# }Steps 4 and 5: Use, then delete
SSH in and run your workload. When done, delete the instance with a single DELETE call. Sandbox instances also auto-expire, so forgotten VMs do not accumulate cost.
# 4. Use it — SSH in, run workloads
ssh agent@inst-7xkq2.asiagent.cloud "uname -a && apt-get update"
# 5. Tear down when done — one DELETE
curl -X DELETE https://api.asiagent.cloud/v1/instances/inst_7xKq2... \
-H "Authorization: Bearer sk-sandbox-abc123..."
# Response:
# { "id": "inst_7xKq2...", "status": "deleting" }Complete flow in one script
Here is the entire lifecycle — signup through teardown — in a single shell script that any agent or CI job can run.
# Complete programmatic provisioning — five HTTP calls, zero config files
signup=$(curl -s -X POST https://api.asiagent.cloud/v1/agent/signup \
-H "Content-Type: application/json" \
-d '{"agent_name": "my-bot"}')
API_KEY=$(echo "$signup" | jq -r '.api_key')
instance=$(curl -s -X POST https://api.asiagent.cloud/v1/instances \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"os": "ubuntu-22.04", "size": "micro"}')
INST_ID=$(echo "$instance" | jq -r '.id')
SSH_HOST=$(echo "$instance" | jq -r '.ssh_host')
# Poll until running
while [ "$(curl -s https://api.asiagent.cloud/v1/instances/$INST_ID \
-H "Authorization: Bearer $API_KEY" | jq -r '.status')" != "running" ]; do
sleep 10
done
# Use the VM
ssh agent@$SSH_HOST "echo 'Hello from programmatic provisioning'"
# Delete when done
curl -s -X DELETE https://api.asiagent.cloud/v1/instances/$INST_ID \
-H "Authorization: Bearer $API_KEY"How Agent Cloud compares to traditional IaC
Terraform, Pulumi, and similar tools are powerful for human-managed infrastructure. But they carry assumptions that break down when an AI agent is the operator.
| Traditional IaC (Terraform, Pulumi) | Agent Cloud API | |
|---|---|---|
| Account creation | Human signs up via browser, verifies email, sets up MFA | Single POST request, instant API key |
| Authentication | OAuth tokens, SSO, browser-based login flows | Bearer token from signup response |
| State management | State files (.tfstate) must be stored, locked, and shared | No state files — the API is the source of truth |
| Provisioning steps | Write HCL/code, init, plan, apply (4+ steps) | One POST request |
| Provider plugins | Download, version-pin, and configure provider binaries | No plugins — plain HTTP |
| Cleanup | terraform destroy (requires state file access) | One DELETE request, plus auto-expiry as a safety net |
| Agent-friendliness | Designed for human operators with terminal access | Designed for any HTTP client, including AI agents |
| Time to first VM | Hours (account setup + IaC authoring + apply) | Minutes (signup + provision + poll) |
Traditional IaC excels at managing complex, long-lived environments with many resources. Agent Cloud excels at the use case agents actually need: spin up one VM fast, use it, tear it down.
Use cases for programmatic provisioning
- CI/CD runners. Provision a clean VM for each pipeline run. No shared runner contamination, no Docker-in-Docker hacks. The VM is purpose-built for the job and deleted when the pipeline finishes.
- Ephemeral dev environments. An agent spins up a VM, clones a repo, installs dependencies, and hands the SSH connection to a developer — or uses it directly for automated code review and testing.
- Agent-provisioned test infrastructure. QA agents that need to test against a real Linux environment can provision isolated VMs per test suite, run tests in parallel, and tear down everything afterward.
- Batch processing. Data pipelines that need burst compute can programmatically scale out by provisioning multiple VMs, distributing work, collecting results, and cleaning up — all through API calls.
- Security sandboxing. Run untrusted code, suspicious downloads, or experimental builds in an isolated VM that is destroyed after inspection. No risk to the host environment.
- Multi-agent orchestration. A coordinator agent provisions separate VMs for sub-agents, each with its own isolated environment. The coordinator manages lifecycle via the API while sub-agents work independently.
Why "API to provision VM without signup" matters
Every major cloud provider requires a human-verified account before you can provision anything. That is a hard wall for autonomous agents. Agent Cloud removes that wall: the agent creates its own account via API, gets sandboxed credentials, and provisions immediately. The human only enters the picture when the agent needs to move beyond sandbox limits — and even that is a single Stripe checkout link, not a multi-step onboarding flow.
This design reflects a core principle: infrastructure APIs should serve whoever is calling them, whether that is a human with a browser or an agent with an HTTP client.
Get started
The sandbox tier is free, requires no credit card, and takes one API call to activate. Start provisioning VMs programmatically in minutes.
Read the quickstart guide to go from zero to running VM, or explore the full API reference for every endpoint, parameter, and response format.