All posts

Why Lnav in a Private Subnet Just Works

The network was dark. No inbound routes. No outbound leaks. Just a single CLI blinking back at me from a private subnet deep inside a VPC. Getting debug logs from that space used to mean hair-pulling workarounds: SSH tunnels, bastion hosts, custom scripts that broke the second a security group changed. Every step slowed down the deployment cycle and risked introducing gaps in security. That’s where deploying Lnav inside a VPC private subnet with a proxy changes the game. It keeps logs close to

Free White Paper

Just-in-Time Access + Virtual Private Database: The Complete Guide

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

Free. No spam. Unsubscribe anytime.

The network was dark. No inbound routes. No outbound leaks. Just a single CLI blinking back at me from a private subnet deep inside a VPC.

Getting debug logs from that space used to mean hair-pulling workarounds: SSH tunnels, bastion hosts, custom scripts that broke the second a security group changed. Every step slowed down the deployment cycle and risked introducing gaps in security.

That’s where deploying Lnav inside a VPC private subnet with a proxy changes the game. It keeps logs close to the workloads. It routes through locked-down network paths. And it lets you inspect, search, and parse production logs without opening public ports or punching dangerous holes in firewalls. The result is off-the-grid visibility with almost zero attack surface.

Why Lnav in a Private Subnet Just Works

Lnav is built for local-first log analysis. When placed inside a private subnet, it thrives. You can tail multi-source logs from containers, ECS tasks, or EC2 instances without sending raw data over the public internet.

Pair that with a proxy—HTTP CONNECT, SOCKS5, or an internal TLS termination point—and you get tight control over every byte of communication. Proxies map access from your secure zone to wherever you need to push processed results, notifications, or dashboards. The logs stay in the subnet. The insights move out. Nothing else crosses.

Continue reading? Get the full guide.

Just-in-Time Access + Virtual Private Database: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Deployment Pattern

The simplest pattern:

  1. Deploy Lnav as a lightweight container or binary to the private subnet.
  2. Launch a minimal proxy endpoint in a public subnet or peered network.
  3. Allow traffic only from Lnav’s internal IPs to the proxy port.
  4. Lock down IAM roles so Lnav reads only the log sources you define.
  5. Route analytics or filtered output via the proxy—never the raw data.

No bastions. No internet gateways. No persistent tunnels. This setup is both faster to deploy and far more secure than manual log extraction. It also survives scaling and redeploys because it’s built into the deployment spec—not your laptop.

Security Wins Without Losing Speed

Traditional remote logging often forces you to open doors you later have to close. By combining a VPC private subnet with a proxy, the surface area shrinks to almost nothing. Lnav then gives you grep-level speed, SQL-like queries, and live views without storing sensitive logs anywhere they shouldn't be.

Going from Concept to Live in Minutes

The real breakthrough is realizing you don’t need weeks to set this up. With the right tooling, you can watch it live before your coffee cools. hoop.dev makes it possible to tunnel into private subnets, deploy Lnav, route over a secure proxy, and see everything working—fast. No compromises. No drama.

Try it. Stand it up. See your private-subnet logs, parsed and searchable, in minutes.

Get started

See hoop.dev in action

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

Get a demoMore posts