All posts

Deploying an Agent in a Private Subnet with a Proxy

The network was up, but nothing moved. The agent sat in a VPC, inside a private subnet, waiting for a path that didn’t exist. No internet access. No public IP. Only a proxy could break the isolation. Deploying an agent in a private subnet begins with understanding the terrain. Security groups, route tables, and NACLs shape the boundaries. The private subnet provides the wall. The proxy becomes the gatekeeper. The goal: connect without cracking open the perimeter. Start with the proxy deploymen

Free White Paper

Database Proxy (ProxySQL, PgBouncer) + Just-in-Time Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

The network was up, but nothing moved. The agent sat in a VPC, inside a private subnet, waiting for a path that didn’t exist. No internet access. No public IP. Only a proxy could break the isolation.

Deploying an agent in a private subnet begins with understanding the terrain. Security groups, route tables, and NACLs shape the boundaries. The private subnet provides the wall. The proxy becomes the gatekeeper. The goal: connect without cracking open the perimeter.

Start with the proxy deployment. Whether you run it inside the same VPC or in a connected network, the proxy handles outbound requests and inbound responses. Choose a trusted proxy server, authenticate strongly, and bind only what is needed. Minimize the attack surface.

Then configure the agent. Set environment variables for proxy host, port, and credentials. Ensure the agent’s runtime is allowed to speak to the proxy through security groups. Test with minimal scopes to verify connectivity without risking exposure. Keep logs turned on but limit verbosity to avoid leaking secrets.

Continue reading? Get the full guide.

Database Proxy (ProxySQL, PgBouncer) + Just-in-Time Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

For AWS, confirm that your route table sends outbound traffic from the private subnet to a NAT gateway or NAT instance if the proxy resides outside. When the proxy is inside, keep routes constrained to that proxy’s private IP. Avoid 0.0.0.0/0 if you can. For Kubernetes workloads in private subnets, deploy the proxy as a service with tight network policies, then point agents via init containers or sidecars.

Observe latency and throughput. A private subnet can choke if the proxy endpoint is overloaded or in the wrong AZ. Place the proxy close to the agents. Scale horizontally if load spikes. Always encrypt end-to-end, even inside the VPC—there’s no safe assumption in network trust models.

Agent configuration in private networks is not guesswork. It’s precise, layered steps: define the boundaries, place the proxy, route only what’s needed, and keep a tight handle on credentials. The best setups are invisible when running and painless to tear down.

If you want to see a complete VPC private subnet proxy deployment running now instead of diagramming it for a week, check out hoop.dev. You can watch the whole thing go live in minutes without losing control of your network boundaries.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts