Developers often need to expose local services—whether for testing webhooks, integrating with a SaaS, or demoing in-progress features—but you don’t want them poking holes in your firewall or deploying shadow IT to get the job done. ngrok lets you define exactly how your peers can create these public developer environments, then apply policies like authentication across them consistently. With this setup, you can:
  • Give each developer their own public URL like bob.devtest.example.com to route public traffic or webhooks into their local development environment.
  • Route requests to the right internal service using domain-based matching.
  • Apply consistent policies like IP restrictions or mTLS to every developer endpoint from a single gateway.

​
What you’ll need

​
1. Let developers create endpoints for their services

Each developer can start their own Agent Endpoint using an internal URL that’s namespaced to your shared ngrok account, like bob.internal, replacing $PORT based on where their service listens. They can also use one of our SDKs or the Kubernetes Operator. 
ngrok http $PORT --url http://bob.internal

​
2. Reserve a domain

Navigate to the Domains section of the ngrok dashboard and click New + to reserve a custom wildcard domain like *.devtest.example.com. You’ll then need to set up CNAME records with your DNS provider.

​
3. Create a Cloud Endpoint

Navigate to the Endpoints section of the ngrok dashboard, then click New + and Cloud Endpoint. In the URL field, enter the wildcard domain you just reserved to finish creating your Cloud Endpoint.

​
4. Route traffic to developer environments with Traffic Policy

While still viewing your new cloud endpoint in the dashboard, copy and paste the policy below into the Traffic Policy editor. 
on_http_request:
  - actions:
      - type: forward-internal
        config:
          url: https://${req.host.split(".devtest.example.com")[0]}.internal
What’s happening here? This policy dynamically forwards every request to a specific internal endpoint based on the hostname of the request. For example, if someone sends a request to bob.devtest.example.com, this policy extracts bob from the hostname string and forwards it to bob.internal, which in turn connects to that developer’s local environment. You can extend this to any number of developer environments by having them create new Agent Endpoints on internal URLs like https://alice.internal and so on.

​
Try out your endpoint

Visit the domain you reserved either in the browser or in the terminal using a tool like curl. You should see the app or service at the port connected to your internal Agent Endpoint.

​
What’s next?