> ## Documentation Index > Fetch the complete documentation index at: https://ngrok.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Connect Services the Internet Can't Reach > Learn when to use the ngrok agent to reach services behind firewalls, NAT, and private networks—and what it gives you once they're connected. The services you need to reach are not always reachable. They sit behind a corporate firewall, on a device you shipped to a customer, inside a private cluster, or on a laptop that joins a different network twice a day. None of them can accept an inbound connection, and giving them one usually means a VPN, a port forward, or a public IP address you would rather not hand out. The ngrok agent reverses the direction instead. You run it next to your service, it dials out to ngrok's network over TLS, and traffic addressed to your endpoint travels back down that same connection. Your service stays exactly where it is, and nothing about its network has to change. ## When you need an agent Run an agent whenever the thing receiving traffic cannot be reached from ngrok's network on its own: * **Behind NAT or a firewall.** Home networks, guest Wi-Fi, corporate networks, and double NAT all work, because the connection is outbound on port 443. * **On hardware in the field.** Devices with no fixed address, no inbound ports, and no one on site to configure a router. * **Inside a private network.** A VPC, a Kubernetes cluster, or a customer's datacenter that you reach without peering or a VPN. * **On a developer machine.** A laptop that moves between networks and still needs a stable public URL. You may not need an agent at all. If what you are routing to is already reachable at a stable address, a [Cloud Endpoint](/docs/gateway/endpoints/cloud-endpoints/) can route to it directly and stays up whether or not any process of yours is running. Endpoints an agent creates are [Agent Endpoints](/docs/gateway/endpoints/agent-endpoints), and they exist only while that agent does. ## What you get once it's connected * **Any protocol your service speaks.** HTTP, HTTPS, TCP, and TLS, so databases, SSH, and RDP work the same way web apps do. * **Many services from one agent.** Run several endpoints at once and [define them all in a configuration file](/docs/gateway/agent/config/) instead of a shell command. * **Something that stays running.** [Install it as a native OS service](/docs/gateway/agent/#running-ngrok-in-the-background) for automatic startup and crash recovery, then [stop, restart, or upgrade it remotely](/docs/gateway/agent/#remote-management) from the API or dashboard. * **No runtime dependencies.** A single standalone executable on every major operating system. ## Working with the agent Start endpoints, manage configuration, and interact with the ngrok API from the command line. Define multiple endpoints and manage complex setups in YAML rather than command-line flags. Authenticate the agent with credentials scoped to your account. Terminate TLS at the agent so traffic stays encrypted end to end. Connect using SSH public key authentication instead of installing the agent. Point agents at your own branded hostname for white-label deployments. Manage endpoints, domains, and other resources through the ngrok API without leaving the agent. ## What people build with it Bridge localhost development with the public internet for AI coding tools, webhook testing, and real authentication flows. Give each developer their own public URL to route traffic and webhooks into their local development environment. Centralize webhook validation and routing from third-party providers to secure your integrations. Create an API gateway with internal Agent Endpoints and centralized traffic management policies. ## What's next? * [Install the agent](/docs/gateway/endpoints/agent-cli-quickstart/) and connect your first service. * [Configure multiple endpoints](/docs/gateway/agent/config/) and run the agent as a service.