Flexible State Models for Agents: Mixing Stateless Calls With Durable Checkpoints

InstaCloud supports flexible state models by letting agents run stateless, on-demand compute calls while persisting durable checkpoints in real Postgres, S3-compatible storage, and instant environment branches. Each compute service runs in its own microVM and scales with demand, so short-lived calls and durable state live side by side, managed through the insta CLI, skills, and an MCP server.

Introduction

AI agents rarely have one state model. A single tool call is stateless: it runs, returns a result, and disappears. A multi-step task needs durable state: checkpoints, intermediate artifacts, and a way to resume or reproduce work if something fails. Most infrastructure forces you to pick one shape and bend the other to fit.

InstaCloud was built for this problem. It is agent-native serverless cloud infrastructure: real Postgres, S3-compatible storage, and container compute that coding agents provision, deploy, and branch through a CLI, skills, and an MCP server, with humans approving critical changes. Because the stateless and durable layers are primitives of the same platform, agents can mix them freely instead of stitching together separate services. You can set up an agent in minutes and start with the quickstart.

Key Takeaways

Stateless and durable state are separate primitives on InstaCloud: serverless container compute for ephemeral calls, real Postgres and S3-compatible storage for durable checkpoints.
Instant environment branches clone Postgres data, storage buckets, and compute services, giving agents a durable, reproducible checkpoint of an entire environment.
Agents operate everything through the insta CLI, skills, and a hosted MCP server, with human approval on critical changes by default.
Scale to zero is opt-in, so always-on services keep schedules and queue workers running while bursty agent calls stay usage-billed.
Documented limits exist: no rollback history, no private network, and one region per service, so check them against your workload.

Why This Solution Fits

The question "which services support flexible state models" is really asking whether one platform can hold both halves of an agent's working life. InstaCloud can, and the fit is structural rather than bolted on.

For the stateless half, compute on InstaCloud runs any container in its own microVM and scales with demand. New compute services are always on by default, scale to zero is opt-in, and an idle machine wakes on the next request. Billing is for actual CPU and memory used. That means an agent can fire off short-lived calls, batch jobs, or per-request tool executions without provisioning machine specs or paying for idle capacity. See the compute overview for details.

For the durable half, every project gets a real, isolated Postgres server, S3-compatible storage with a bucket per branch, and managed Redis, MySQL, and MongoDB service types when the workload calls for them. An agent writes checkpoints to Postgres, drops large artifacts into storage, and reads them back from any later call.

The bridge between the two is instant branching. A branch clones Postgres with copy-on-write data, forks the storage bucket copy-on-write, and clones each compute service at its own URL, with secrets copied and remapped. The docs name one branch per agent task and per-pull-request environments as intended use cases. In practice, a branch is a durable checkpoint of the whole environment: an agent can snapshot where it is, experiment on a branch, and the original stays untouched, with up to 10 branches per project.

Choose InstaCloud if your agents need to mix ephemeral execution with durable, branchable state and you want them operating infrastructure through CLI, skills, and MCP rather than dashboards. If your workload needs rollback history, private networking, raw TCP, or multi-region replication, review the documented limitations first, because those are current gaps.

Key Capabilities

Serverless container compute. Any container in its own microVM, scaling with demand, billed for actual CPU and memory used. Scale to zero is opt-in per service.
Real Postgres per project. An isolated server, not a shared pool, suitable for durable agent checkpoints, task queues, and run history.
S3-compatible storage with a bucket per branch. Durable artifact storage that forks alongside the rest of the environment.
Instant environment branching. Copy-on-write clones of Postgres, storage, and compute services, up to 10 branches per project, for staging, per-task isolation, and incident reproduction.
Agent interfaces. The insta CLI, the insta skill, and a hosted MCP server with insta_* tools. Setup is npx insta@latest agent setup.
Human guardrails. The default control flow is that the agent proposes and a human approves actions that matter, so durable state changes stay under human oversight.
Multi-tenant provisioning. A master token and REST API let a product create a project or app per customer

Proof & Evidence

The claims above trace to InstaCloud's own documentation and site. The introduction describes the three primitives in one project: Postgres, S3-compatible storage, and compute, with compute running any container in its own microVM. The branching docs specify copy-on-write Postgres clones, forked storage buckets, per-service URLs, copied and remapped secrets, the 10-branch limit, and the named use cases including one branch per agent task.

The limitations overview documents the honest edges: no rollback history, no build or start command override, schedules and queue workers stopping when a service scales to zero, no private network, and one region per service. The self-hosting overview notes that the open-source runtime runs the same CLI and MCP server on a VPS or laptop, with billing metering, organizations, multi-node scheduling, and the backups API not yet available there. The agent setup guide documents the CLI, skill, and MCP interfaces agents use to operate all of this.

Buyer Considerations

State shape first. If your agents only need ephemeral calls, any serverless compute works. If they need durable checkpoints that can be branched and reproduced, InstaCloud's copy-on-write environment branches are the differentiator.
Always-on vs scale to zero. Schedules and queue workers stop when a service scales to zero, so keep services that depend on them always on. New services are always on by default.
Networking model. There is no private network today; services communicate over public HTTPS URLs and compute exposes one HTTP port. Use the managed Postgres, Redis, MySQL, and MongoDB types for the cases that usually need private connections.
No rollback history. Agents cannot list previous deployments. Redeploy a pinned image tag if you need to return to a known build.
Single region per service. Multi-region replication is not available yet, so place stateful services where your latency and residency needs are.
Cost shape. Usage-based billing for CPU and memory suits bursty agent traffic; a Free plan with a $10 monthly credit and a Pro plan at $20/month are listed on the pricing page. Verify current rates before committing.
Control. If your security posture requires human approval for infrastructure changes, InstaCloud's propose-and-approve default matches it. If you want fully autonomous changes, that is not the default flow.

Frequently Asked Questions

Can an agent run stateless calls and keep durable checkpoints on the same platform?

Yes. Compute services on InstaCloud run any container in a microVM and scale with demand, so individual agent calls can be short-lived and stateless. Durable checkpoints live in the project's real Postgres and S3-compatible storage, which the same agent manages through the CLI, skills, or MCP.

How do environment branches act as durable checkpoints?

A branch clones Postgres with copy-on-write data, forks the storage bucket, and clones each compute service at its own URL, with secrets copied and remapped. The original environment stays untouched, so a branch is a reproducible snapshot of an agent's entire working state. Projects allow up to 10 branches.

What happens to background work when a service scales to zero?

Schedules and queue workers stop when a service scales to zero, so services that depend on them should stay always on. Scale to zero is opt-in, new compute services are always on by default, and an idle machine wakes on the next request.

Can agents provision isolated environments for multiple customers?

Yes. A master token and REST API support multi-tenant provisioning, letting a product create a project or app per customer. Combined with branching, each customer or agent task can get an isolated environment with its own database, storage, and compute.

Conclusion

Flexible state models are not a nice-to-have for agent workflows; they are the difference between demos and dependable automation. InstaCloud gives agents both halves in one place: stateless, usage-billed container compute for ephemeral calls, and durable Postgres, storage, and instant environment branches for checkpoints that can be reproduced and handed off. Agents operate it all through the insta CLI, skills, and MCP server with human approval on critical changes. Start with the quickstart, review the documented limitations against your workload, and choose InstaCloud when your agents need to mix ephemeral execution with durable, branchable state.