₹ INR
Open console

Blog

Standing up real infrastructure by talking to a coding agent

A full walkthrough of a Claude Code session driving the exc CLI to build a web box and a private Postgres box on Excloud — in plain English, with every command shown and a confirmation gate before anything billable.

16 June 2026 · updated 17 June 2026

Here is a thing you can do on Excloud that you can’t really do anywhere else: open a coding agent, describe the infrastructure you want in a sentence, and watch it build the actual thing — security groups, VMs, firewall rules, a web server — while showing you every command before it spends a rupee.

This isn’t a chatbot that writes you a Terraform file to run later. It’s an agent driving our exc CLI directly, against your real account, with a plan and a confirmation gate. The reason it works is boring and structural: exc is generated from a live API surface, and we publish a skills bundle that teaches agents which commands exist, what each flag means, and when to stop and ask before doing something destructive.

Setup, once

The CLI installer adds the skills for you:

curl -fsSL https://excloud.dev/install.sh | bash

That drops the excloud-cli skill into ~/.skills/, where any agent on the machine can find it — Claude Code, pi, or anything that speaks the skill spec. We also maintain the pi integration path, so pi users get the same Excloud-aware workflow instead of a generic shell prompt. Log the CLI in once with exc login and you’re done.

A real session

Below is a trimmed Claude Code transcript. I asked for a two-box setup: a public web server, and a Postgres box that only the web server can reach. Watch how it works rather than just what it produces.

Me: Stand up a small web tier on Excloud. One public box running nginx, reachable on 80 and 443 from anywhere, SSH only from my current IP. And one Postgres box with no public IP that only the web box can talk to on 5432. Use my existing SSH key. Tell me the URL when it’s up.

Claude: I’ll use the excloud-cli skill. Before I create anything billable I’ll check what’s already in your account — your subnet, your SSH key, and your current public IP — then show you a plan and wait for your OK.

It starts read-only. None of this costs anything or changes anything:

exc compute subnet list
exc compute image list | grep -i ubuntu
exc compute instancetype list
exc compute key list
curl -s https://api.ipify.org

Claude: Found it. Default subnet 1 in mum-1a (public IPv4 allowed), Ubuntu 24.04 is image 1, your key is named main, and your current IP is 203.0.113.42. Here’s the plan:

  1. Create security group web-sg: ingress 80 and 443 from 0.0.0.0/0, ingress 22 from 203.0.113.42/32, egress to anywhere.
  2. Create web-1 (t1a.medium, Ubuntu, public IPv4, web-sg, key main).
  3. Create security group db-sg: ingress 5432 from web-1’s private IP only, egress to anywhere. No SSH, no public IP.
  4. Create db-1 (m1a.large, Ubuntu, no public IPv4, db-sg, key main).
  5. Install nginx on web-1.

Steps 2 and 4 are billable — web-1 is ₹0.945/hr and db-1 is ₹1.889/hr, plus ₹0.3/hr for the one public IPv4. Roughly ₹3.13/hr in total. Shall I go ahead?

Me: go

This is the part that matters. It read my account, made a plan with the real hourly cost in it, and stopped. Now it builds:

exc securitygroup create --name web-sg --description "public web tier"
# SG id: sg-7af2

exc securitygroup rule create --security_group_id sg-7af2 --is_ingress=true  --protocol TCPv4 --port_range 80  --cidr 0.0.0.0/0
exc securitygroup rule create --security_group_id sg-7af2 --is_ingress=true  --protocol TCPv4 --port_range 443 --cidr 0.0.0.0/0
exc securitygroup rule create --security_group_id sg-7af2 --is_ingress=true  --protocol TCPv4 --port_range 22  --cidr 203.0.113.42/32
exc securitygroup rule create --security_group_id sg-7af2 --is_ingress=false --protocol IPv4  --port_range ANY --cidr 0.0.0.0/0
exc compute create \
  --name web-1 --subnet_id 1 --allocate_public_ipv4=true \
  --image_id 1 --instance_type t1a.medium --root_volume_size_gib 20 \
  --security_group_ids sg-7af2 --ssh_pubkey main --wait
 NAME   STATE     ZONE  SUBNET  PUBLIC_IPV4     INTERFACE_IPV4  INTERFACE_IPV6
 web-1  STARTING  1     1       210.79.129.61   10.1.0.40       2401:5420::...

Claude: web-1 is coming up with private IP 10.1.0.40. I’ll lock the database group to that address.

Notice it didn’t hard-code anything. It pulled web-1’s private IP out of the create output and used it to scope the database firewall, so Postgres is reachable from exactly one box:

exc securitygroup create --name db-sg --description "postgres, web tier only"
# SG id: sg-9c10

exc securitygroup rule create --security_group_id sg-9c10 --is_ingress=true  --protocol TCPv4 --port_range 5432 --cidr 10.1.0.40/32
exc securitygroup rule create --security_group_id sg-9c10 --is_ingress=false --protocol IPv4  --port_range ANY  --cidr 0.0.0.0/0

exc compute create \
  --name db-1 --subnet_id 1 --allocate_public_ipv4=false \
  --image_id 1 --instance_type m1a.large --root_volume_size_gib 40 \
  --security_group_ids sg-9c10 --ssh_pubkey main --wait

For lifecycle operations, the current CLI supports --wait, so the agent can block until the VM reaches the target state instead of guessing a fixed delay. If it is running against an older CLI or needs custom behavior, the skill can still fall back to polling compute get and keying off the STATE column:

until [ "$(exc compute get --id web-1 | awk 'NR==2{print $2}')" = "RUNNING" ]; do sleep 3; done

Then it installs the web server over the instance-connect transport — no SSH keys to shuffle, no IP to copy around:

exc compute exec --vm-id web-1 --command \
  "sudo apt-get update -qq && sudo apt-get install -y nginx && sudo systemctl enable --now nginx"

Claude: Done. web-1 is serving the default nginx page at http://210.79.129.61, reachable on 80/443 from anywhere and SSH only from your IP. db-1 is up on private 10.1.0.41 with no public address; only web-1 can reach 5432. Two boxes, about ₹3.13/hr while they run. Want me to tear it down when you’re finished testing?

That last question isn’t decoration. The skill treats terminate, delete, and release as actions that need explicit confirmation, so an agent won’t quietly destroy a database because it misread you.

Why this is the differentiator

Plenty of clouds have a CLI. A few have an MCP server you can point an agent at. What makes this work end to end is three things lining up:

  • The CLI tracks the API. exc is generated from a live OpenAPI surface, so an agent reading exc <command> --help is reading the truth, not a doc that drifted six releases ago.
  • The skill carries the judgment. It knows to check IDs against list before creating, to never invent an image or subnet ID, to scope a database to one host instead of the whole subnet, and to stop before anything billable or destructive.
  • Every command is shown. Nothing happens behind glass. You can halt the agent at any line and run the same exc command yourself, because there’s no private API it’s reaching for.

The result is that the distance between “I want a web box talking to a private database” and the running thing is one sentence and one “go.” For unattended use — CI, a routine, an agent running while you sleep — set EXCLOUD_API_KEY and EXCLOUD_ORG_ID and the same flow runs with no browser login.

Install the CLI, run exc login, and ask your agent for something. The whole bundle is open at git.excloud.dev/excloud-dev/excloud-skills if you want to read exactly what you’re handing it.