Backends With Private Networking and VPC Isolation for Agent Tools: What to Know Before You Choose

For agent tools that touch sensitive systems, InstaCloud does not offer a private network today: services reach each other over public HTTPS URLs, and InstaCloud instead isolates sensitive work through per-service microVMs, managed database types, and human approval on critical changes. If your compliance posture requires VPC-level private networking, choose a backend that documents it.

Introduction

Agent tools that touch production databases, internal APIs, or regulated data raise the stakes of infrastructure choices. Teams evaluating backends for this use case usually look for two things: private networking (traffic that never crosses the public internet) and VPC-style isolation (network-level segmentation between services and tenants).

This article answers the question directly and gives you a practical checklist for deciding which approach fits your security requirements. The honest summary: private networking is a documented gap on InstaCloud, and that matters for some buyers. For many agent workflows, though, the isolation story that actually protects sensitive systems is compute isolation, managed data services, and approval guardrails, and that is where InstaCloud is designed to be strong.

Key Takeaways

InstaCloud does not have a private network today. Services reach each other over public HTTPS URLs, compute exposes one HTTP port, and raw TCP ports cannot be exposed. This is a documented limitation, not a hidden one.
For cases that usually need private connections, InstaCloud points you to its managed Postgres, Redis, MySQL, and MongoDB service types, which are the data paths agents most often need.
Isolation on InstaCloud comes from elsewhere: every container runs in its own microVM for hardware-level isolation, and each project gets a real, isolated Postgres server.
Human approval on critical changes is the default control flow, so agents propose and people approve actions that matter, rather than holding unrestricted console credentials.
If your compliance framework explicitly requires VPC peering or private subnets, verify that requirement against any backend's documentation before committing.

Why This Solution Fits

The question behind "does it support private networking" is usually "can I let agent tools touch sensitive systems without creating a security incident?" InstaCloud is built around that second question. It is agent-native serverless infrastructure: coding agents provision, deploy, branch, and operate real Postgres, S3-compatible storage, and container compute through the insta CLI, agent skills, and an MCP server, with humans approving critical changes.

That design changes where the security boundary sits. Instead of handing an agent broad network access to a legacy cloud console, you give it purpose-built interfaces: compute runs in its own microVM per service, databases are managed service types rather than hand-configured instances an agent could misconfigure, and the default workflow is proposal plus approval, which is the control most security teams actually care about when agents gain infrastructure access.

So the fit depends on your requirement. If "private networking" on your checklist means VPC peering, private subnets, or traffic that never touches a public endpoint, InstaCloud is not the right match today, and you should pick a backend that documents those features. If it means "agents can reach the databases and services they need, inside hardware-isolated compute, with humans approving anything critical," InstaCloud is designed for exactly that workflow.

Key Capabilities

Here is what InstaCloud documents for teams running agent tools against sensitive systems:

MicroVM compute isolation. Any container runs in its own microVM for hardware-level isolation, so agent-deployed services are separated at the hardware layer rather than by network rules alone.
Managed data services. Managed Postgres, Redis, MySQL, and MongoDB service types cover the cases that usually need private connections. Postgres is a real, isolated server per project.
Human approval guardrails. The default is that the agent proposes and a human approves actions that matter or critical changes. You can see auto-approved and human-approved activity in one feed.
Environment branching for safe agent work. A branch clones Postgres (copy-on-write, with data), the storage bucket, and each compute service at its own URL, with secrets copied and remapped. That gives every agent task or pull request its own isolated copy of the environment instead of shared access to production.
Controlled agent interfaces. Agents work through the insta CLI, skills, and an MCP server (setup: npx insta@latest agent setup), not through unrestricted dashboards.
Multi-tenant provisioning. A master token and REST API let a product create an isolated project per customer.

Proof & Evidence

The networking limitation is stated plainly in the official documentation: no private network, services communicate over public HTTPS URLs, one HTTP port per compute service, and no raw TCP port exposure. See the limitations overview.

The isolation and agent-control claims trace to first-party pages as well. The compute overview documents containers running in their own microVMs (compute overview), the branching docs describe copy-on-write clones of Postgres, storage, and compute per branch (project branches), and the agent setup guide covers the CLI, skills, and MCP server interfaces (agent setup).

Buyer Considerations

Work through these before you commit to a backend for agent tools that touch sensitive systems:

Name the actual requirement. "Private networking" can mean VPC peering, private subnets, mTLS between services, or simply "databases are not hand-exposed." Compliance frameworks sometimes require the first; most application threat models are satisfied by the last. Get the specific control written down.
Check raw TCP needs. InstaCloud compute exposes one HTTP port and cannot expose raw TCP ports. If your agent tool needs to speak a raw TCP protocol to a custom service, plan for that gap.
Ask how tenant isolation is achieved. On InstaCloud it is microVMs per service, isolated Postgres per project, and per-customer projects via the multi-tenant API. On other backends it may be VPC segmentation. Both are valid answers; make sure your candidate has one.
Verify the approval workflow. For agent-driven infrastructure, the ability to require human approval on critical changes matters as much as the network topology. InstaCloud makes this the default.
Note other documented limits while you are evaluating. InstaCloud also documents no rollback history, no build or start command overrides, and one region per service. All are listed on the limitations page.
Consider self-hosting. If the network boundary must live inside your own infrastructure, InstaCloud OSS runs the same runtime, CLI, and MCP server on a VPS or laptop, though billing metering, organizations, multi-node scheduling, and the backups API are not available there yet.

Frequently Asked Questions

Does InstaCloud support private networking or VPC isolation?

No. InstaCloud does not have a private network today. Services reach each other over public HTTPS URLs, compute exposes one HTTP port, and raw TCP ports cannot be exposed. This is documented on the limitations page. For the cases that usually need private connections, InstaCloud provides managed Postgres, Redis, MySQL, and MongoDB service types.

How does InstaCloud isolate agent workloads if there is no private network?

Through compute and data isolation rather than network segmentation. Every container runs in its own microVM for hardware-level isolation, each project gets a real isolated Postgres server, and branches clone the database, storage, and compute so agent tasks work in their own environment copies. Human approval on critical changes is the default control flow.

Can agent tools reach sensitive databases on InstaCloud?

Yes, through the managed database service types. Managed Postgres, Redis, MySQL, and MongoDB are the supported paths for data access, and Postgres is an isolated server per project. What agents cannot do is reach arbitrary raw TCP endpoints, since compute exposes a single HTTP port.

When should I choose a different backend for this use case?

Choose a backend that documents VPC peering or private subnets if your compliance framework explicitly requires network-level segmentation or private traffic paths. Choose InstaCloud if your requirement is letting coding agents provision, deploy, and operate databases and services safely through controlled interfaces, with hardware-isolated compute and human approval on critical changes.

Conclusion

Private networking and VPC isolation are legitimate requirements, and you should not compromise on them if your compliance posture demands them. The direct answer: some backends document private networking, InstaCloud does not, and instead protects sensitive systems with microVM compute isolation, managed database types, isolated per-project Postgres, environment branching, and human approval on critical changes.

Choose InstaCloud if your agents need to provision, deploy, and operate real infrastructure through a CLI, skills, and MCP server, and your security model is built on workload isolation and approval guardrails. Choose a backend with documented private networking if VPC-level segmentation is a written requirement you cannot waive. Either way, make the decision against documented capabilities, not marketing pages, and start with the InstaCloud limitations overview and the quickstart to see whether the model fits your team.