InstaCloud is a new cloud platform built on a bold premise: that the coding agents now writing much of the world’s software should also deploy it and run the cloud infrastructure beneath it, without a developer clicking through dashboards or a DevOps engineer writing configuration. On Tuesday 29 September 2026, Hang Huang, co-founder and chief executive of the Y Combinator start-up InsForge, introduced it as “the agent-native serverless cloud” and said the company had raised an $8 million seed round.
Huang did not undersell it. “We just raised an $8M seed round to kill AWS, GCP, and Azure,” his post on X began. The product itself is narrower than that line suggests. InstaCloud gives agents such as Claude Code, Codex and Cursor serverless compute that scales to zero, Postgres databases that branch in seconds, and a set of guardrails that decide which infrastructure changes need a human to approve them.
This article sets out what was launched, who is behind it, how its branching and guardrails work, what it costs, what it cannot do yet, and whether a development team should try it now or wait.
Table of contents
- What InstaCloud Launched
- Who Is Behind the Platform
- How InstaCloud Works for Coding Agents
- Branching: How Production Stays Safe
- Human Guardrails for Agents
- Tokens, SSH and Access for Agents
- InstaCloud Pricing
- A Month of Releases
- What InstaCloud Cannot Do Yet
- Can InstaCloud Really Take On AWS?
- Should Your Team Try InstaCloud?
- InstaCloud FAQs
- References
What InstaCloud Launched
InstaCloud describes itself as “cloud infrastructure built from the ground up for agents to provision and operate directly. Serverless by default, with human guardrails built in.” Its homepage makes the pitch in one line: “Agents don’t just write code. They operate the infrastructure.”
| Item | Detail | Source |
|---|---|---|
| Announced | 29 September 2026, 15:01 UTC, on X | Hang Huang |
| Funding | $8 million seed; investors and valuation not disclosed | Hang Huang; RuntimeWire |
| Company | InsForge, Y Combinator Spring 2026, San Francisco | Y Combinator |
| Core services | Serverless compute, Postgres, storage buckets, environment branching | Product docs |
| Agent access | The insta CLI, agent skills and an MCP server | Product docs |
| Price | Free tier; Pro from $20 a month; Team $499 a month plus usage | Pricing page |
| Self-hosting | An open-source edition under the Apache 2.0 licence | GitHub |
The pitch in Huang’s own words
“Your team is shipping code like never before. But you’re getting caught up in manual, tedious DevOps work trying to deploy it,” Huang wrote. The service “provides the serverless compute that lets your services autoscale, with all the infrastructure managed for you,” and “agents branch into complete replica environments when working, keeping prod safe and iteration speed high.” His post had drawn about 235,000 views within hours.
What is new and what is not
Serverless compute, managed Postgres and preview environments all exist elsewhere. What InstaCloud changes is the intended user. Every command, error and log is designed to be read and acted on by an agent first, with a human reviewing the moves that matter, rather than the other way round.
Who Is Behind the Platform
InstaCloud is made by InsForge, whose Y Combinator profile lists it as “InsForge (InstaCloud)” in the Spring 2026 batch. The founders are Hang Huang, the chief executive, a former Amazon product manager who played League of Legends professionally, and Tony Chang, the chief technology officer, a former network infrastructure engineer at Databricks.
From an open-source backend to a cloud
InsForge’s first product was an open-source backend for agentic coding, giving an agent a database, authentication, storage, compute, hosting and an AI gateway. Its GitHub repository, created in July 2025, has passed 13,000 stars. The new cloud extends the same idea from a backend to the infrastructure underneath it, and the docs include a migration guide from InsForge projects.
Why the founders built it
In their Y Combinator launch post, the founders said they had tried connecting agents to existing platforms through MCP servers and hit the same problems: “tools bloated the context window, payloads came back at 10K+ tokens,” and core backend state such as telemetry, configuration and logs “still wasn’t accessible in a way agents could reliably use.” The new platform is their answer: structured outputs, readable errors, and actions an agent can undo.
The funding, and what is missing
RuntimeWire notes that the $8 million figure is Huang’s own claim and that his post named no investors, valuation or traction figures. The company’s previous public round, per Huang’s LinkedIn announcement cited by RuntimeWire, was a $1.5 million pre-seed in 2025 led by MindWorks Capital with Baidu Ventures participating.
How InstaCloud Works for Coding Agents
Setting up takes one command. Running “npx insta@latest agent setup” installs the insta CLI, the insta skill and the MCP server, and wires them into any coding agents it finds on the machine. The developer completes a one-time login and the agent drives the rest.
Which agents it supports
InstaCloud’s agent directory lists seven: Anthropic’s Claude Code, OpenAI’s Codex, Google’s Antigravity, Cursor, OpenCode, OpenClaw and Cline. Most can use all three routes into the platform, the CLI, the skill and the MCP server. The directory also offers a single prompt to paste into an agent, which tells it to fetch the platform’s setup instructions and follow them.
Compute in microVMs
Each compute service runs a container inside its own microVM, which the docs describe as “hardware-level isolation rather than a shared-kernel container, which is what makes it safe to run agent-built code next to everything else.” New services are always-on by default. A service can opt into scale-to-zero, where an idle machine suspends and wakes on the next request “in seconds”.
What an agent can deploy
The docs list deployment from a directory, a Dockerfile, a prebuilt image or a GitHub repository. Alongside compute, a project can run Postgres, an S3-compatible storage bucket, and managed Redis, MySQL and MongoDB. Templates, including one the homepage suggests for deploying an AI agent, let an agent stand up a known stack in one step.
Branching: How Production Stays Safe
Branching is the feature InstaCloud leans on hardest. A branch is “a full, isolated clone of your environment”, and the docs recommend one branch per agent task, so several agents can work in parallel without touching production or each other.
| Piece of the environment | On a new branch |
|---|---|
| Postgres | Copy-on-write clone with the parent’s data and its own connection string |
| Storage bucket | Copy-on-write fork of the objects |
| Compute | A clone of each app at its own URL, running the parent’s image |
| Secrets | Copied, with bindings remapped to the branch’s own services |
| Managed Redis, MySQL, MongoDB | A fresh, empty instance; no data cloned |
| Compute volume | Same size, but empty |
Real data, contained mistakes
Because the branch’s Postgres opens with the parent’s data, an agent can test a migration against real records. If the migration breaks, it breaks on the branch. The docs call this “real data, zero risk”, and it answers the most common fear about letting agents near infrastructure: a bad write hitting the live database.
Promotion is a migration, not a copy
Merging a branch is structural and additive. Services the branch added are created on the target, empty, and “data never merges”. To promote a change, the team merges the code in git, runs the migration files against the main database, and deploys. That keeps a human-reviewed step between an agent’s experiment and production data.
A cap on sprawl
Each project can hold ten branches. The docs frame that as a feature: “Ten branches per project caps how far a fleet can sprawl.” Teams running many agents in parallel will hit it quickly, and will need to delete branches as tasks finish. Our report on agent sprawl explains why an unmanaged fleet of agents becomes a security problem of its own.
Human Guardrails for Agents
The company added project-level agent governance policies on 15 September. They decide which operations an agent can run, which need human approval, and which are blocked. The same policy applies to agent-mode CLI requests and MCP tools, while human users keep their normal role-based permissions.
| Policy | What the agent can do |
|---|---|
| Full access (default) | Any classified operation within the user’s own permissions |
| Read-only | Reads, including sensitive credentials; mutations blocked |
| Branch-specific | Develop on unprotected branches; writes to protected branches blocked; approval for actions such as deleting services or changing capacity |
| Custom | Each eligible action set to Allow, Approve or Deny |
How approval works
When an operation needs approval, it pauses for a human admin. “Approval authorizes one exact request once,” the changelog says. The agent then retries the unchanged command; any change to the resource or parameters needs a new approval. Agents cannot approve their own requests, and in the restricted modes they cannot change their own policy.
Read the small print
Two caveats matter. First, the default is full access, and “main is not protected automatically”, so a team has to switch branch protection on. Second, the changelog warns that “read-only mode and branch protection do not enforce SQL-level isolation”: SQL is not parsed for writes, and database credentials can permit direct access. An agent in read-only mode that can read credentials could, in principle, write to the database with them. Our account of a Claude Code session that deleted 48,000 files shows why that gap deserves attention.
Tokens, SSH and Access for Agents
Agents need credentials, and how a platform hands them out decides how much damage a confused agent can do. That makes it a cybersecurity question, not just a convenience. Several September releases deal with exactly that, and they are worth reading alongside the governance policies.
Scoped API tokens
Since 25 September, teams can mint API tokens to drive the platform from scripts and CI jobs: create a project, add services, deploy, run SQL. The dashboard, CLI and MCP server all sit on the same REST API, so a token can do anything they can. A token is bound to an account, to one organisation and its projects, or to a single project, and the scope is fixed at creation. Access is either full or read-only, and a read-only token can list and inspect but cannot run SQL or change anything.
Expiry and revocation
Tokens expire after 90 days by default, or never for a token the owner rotates by hand. “A token never exceeds its owner,” the changelog says: the owner’s organisation role still applies, and leaving an organisation revokes the tokens minted there. A revoked key stops working immediately, and a request outside a token’s scope is refused with a 403 error. For agent work, a short-lived, project-scoped, read-only token is the sensible default, widened only when a task needs it.
SSH and the browser console
SSH access arrived on 18 September, using short-lived certificates rather than passwords, and a browser console followed on 22 September. The company draws a clear line between the two audiences: “Console is for people. An agent that needs to run commands still uses insta compute exec.” Keeping agents on the audited command path, rather than an interactive shell, makes their actions easier to review afterwards.
InstaCloud Pricing
InstaCloud bills “only for active CPU and memory”, metered per second, with a monthly platform plan on top.
| Plan | Monthly price | Included | Limits per service |
|---|---|---|---|
| Free | $0 | $10 usage credit; projects pause when it runs out | 4 vCPU, 4 GB RAM, 1 GB volume; 5 services of each type per environment |
| Pro | $20 minimum usage | $20 usage credit; pay for extra usage, projects keep running | 8 vCPU, 8 GB RAM, 10 GB volume; 25 services; replicas |
| Team | $499 plus usage | HIPAA as a paid add-on; dedicated Slack channel | 8 vCPU, 8 GB RAM, 50 GB volume; 100 services |
| Enterprise | Custom | SOC 2 and SSO, HIPAA BAAs, SLA-backed support | Custom |
What the per-second rates mean
The published resource rates are $0.00000772 per vCPU-second, $0.00000386 per GB of memory per second, $0.05 per GB of egress and fractions of a cent for volume and object storage. Multiplied out, one vCPU plus one GB of memory costs about $0.042 an hour while awake. The chart shows what that means for one such service at three levels of use.
The arithmetic is ($0.00000772 + $0.00000386) × 3,600 seconds × hours. It leaves out storage, egress and the plan fee, and it assumes the service really sleeps when idle, which new services do not do unless switched to scale-to-zero.
Where scale-to-zero pays off
The gap between the first and last bars is the case for serverless. Preview environments, internal tools and agent branches sit idle most of the day, and on InstaCloud they cost little while they do. A busy production API that never sleeps gains nothing from it, and should be priced like any always-on server.
A Month of Releases
The public changelog shows eleven releases in September alone, before the funding announcement. For a seed-stage infrastructure company, that pace is part of the pitch: gaps listed today may close within weeks.
| Date | Release |
|---|---|
| 4 September | Multiple compute replicas |
| 8 September | Deploy a template from any GitHub repository |
| 11 September | Docker inside compute, which now runs as full Linux VMs |
| 15 September | Agent governance policies |
| 17 September | Buy and attach a domain from the dashboard or CLI |
| 18 September | SSH into compute, with short-lived certificates |
| 22 September | Browser terminal for each compute service |
| 23 September | Cron jobs per branch (5 on Free, 100 on Pro, 1,000 on Team and Enterprise) |
| 24 September | Choose where a compute volume mounts |
| 25 September | Scoped API tokens for scripts and CI, 90-day default expiry |
| 26 September | Outbound traffic keeps a scale-to-zero service awake |
The fix that matters most for agents
The 26 September change is small but telling. Until then, a scale-to-zero service judged idleness from inbound traffic only, so an agent on a long task that was calling a model but receiving nothing could be suspended mid-job. Outbound traffic now counts as activity. It is the kind of problem that only shows up when agents, not people, are the main users.
What InstaCloud Cannot Do Yet
The docs include an unusually frank limitations page, and it is worth reading before moving anything important.
No rollback
“Every deploy replaces the one before it, and there is no list of previous deployments to go back to.” A team that deployed a pinned image can redeploy that tag; a team that deployed a directory cannot get the old build back. For a platform that invites agents to deploy, the lack of rollback is the biggest gap on InstaCloud today.
No private network, one region
Services reach each other over public HTTPS URLs, and a raw TCP port cannot be exposed, so internal traffic crosses the public internet. Each service lives in one region, and multi-region replication “is not here yet.” Build and start commands also cannot be overridden without a Dockerfile.
Can InstaCloud Really Take On AWS?
Not in the sense Huang’s post implies, and RuntimeWire makes the same point. AWS, Google Cloud and Azure sell hundreds of services to every kind of workload. InstaCloud’s immediate rivals are developer platforms that package compute, databases and deploys for application teams; its docs include migration guides from three of them, Render, Railway and Fly.io.
Where it could win
The opening is a change in who operates infrastructure. If more code is written and shipped by agents, a platform whose every surface is built for agents has an advantage over one retrofitted with an MCP server. Our comparison of Kubernetes, serverless and virtual machines sets out where serverless fits and where it does not.
What would prove it
The launch offered no customer, revenue or usage numbers. The evidence to watch is whether teams move production workloads onto InstaCloud, not just agent experiments, and whether the gaps on its limitations page close at the pace its changelog suggests.
Should Your Team Try InstaCloud?
For prototypes, internal tools and agent-built side projects, InstaCloud is cheap to try: the free tier includes $10 of usage a month, and the setup takes one command. For production systems, the missing rollback and private networking argue for waiting.
A sensible first project
Pick a self-contained internal app with its own database. Let the agent deploy it on InstaCloud, turn on branch-specific governance and protect main, and run one migration through a branch. That tests the three claims that matter, agent operation, branching and guardrails, without putting customers at risk.
Keep a human in the loop
Whatever platform a team chooses, agent-operated infrastructure needs clear rules on who approves what. Our DevOps services team helps businesses set those rules, from branch protection to deployment approvals, before agents are given production access.
InstaCloud FAQs
What is InstaCloud?
An agent-native serverless cloud from Y Combinator start-up InsForge, launched on 29 September 2026, that lets AI coding agents provision, deploy and operate infrastructure through a CLI, skills and an MCP server.
How much did InsForge raise?
Chief executive Hang Huang said the company raised an $8 million seed round. He did not name investors or disclose a valuation.
How much does InstaCloud cost?
There is a free tier with $10 of monthly usage credit, a Pro plan with a $20 monthly minimum, a Team plan at $499 a month plus usage, and custom Enterprise pricing.
Which coding agents are supported?
Its directory lists Claude Code, Codex, Antigravity, Cursor, OpenCode, OpenClaw and Cline.
Can I self-host it?
Yes. InstaCloud OSS runs the runtime on your own machine under the Apache 2.0 licence, with the same CLI.
References
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
