Create Secure Public Developer Environments
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
- A production pay-as-you-go account for creating wildcard domains
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.
Loading…
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.
Loading…
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?
- Read our best practices for developer productivity guide for ways to improve this example with developer-specific authtokens and custom connect URLs.
- Explore other examples of using the
forward-internal
Traffic Policy actions.