> ## 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.

# Create Secure Public Developer Environments

> Use a shared wildcard endpoint to control how your developers expose their services, route requests to the right local service, and apply centralized Traffic Policies like auth or IP restrictions.

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](/pricing-limits/) account for creating [wildcard endpoints](/pricing-limits/#wildcard-endpoints)

## 1. Let developers create endpoints for their services

Each developer can start their own [Agent Endpoint](/gateway/agent-endpoints) 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 the [SDKs](/agent-sdks) or the [Kubernetes Operator](/k8s).

```bash theme={null}
ngrok http $PORT --url http://bob.internal
```

## 2. Reserve a domain

Navigate to the [**Domains** section](https://dashboard.ngrok.com/domains) of the ngrok dashboard and click **New +** to reserve a [wildcard domain](/gateway/custom-domains/) 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](https://dashboard.ngrok.com/endpoints?sortBy=updatedAt\&orderBy=desc) of the ngrok dashboard, then click **New +** and **Cloud Endpoint**.

In the **URL** field, enter the wildcard endpoint pattern (using the domain you just reserved) to finish creating your [Cloud Endpoint](/gateway/cloud-endpoints/).

## 4. Route traffic to developer environments with Traffic Policy

While viewing your new Cloud Endpoint in the dashboard, copy the policy below and paste it into the Traffic Policy editor.

```yaml theme={null}
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?

* Read the [best practices for developer productivity](/guides/security-dev-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/forward-internal/#examples) Traffic Policy actions.