Configuring Endpoints and Paths for Apps Deployed to a Private Space | MuleSoft Documentation
# Configuring Endpoints and Paths for Apps Deployed to a Private Space
CloudHub 2.0 supports customizing endpoints only for apps that are deployed to private spaces, not shared spaces.   
---  
A private space routes requests from clients to apps deployed to the private space.
When you deploy an app to a private space, two types of _endpoints_ are created:
  * **Endpoint** : A URL used to reach the app deployed to the public space. In this context, it is accessible externally and enables clients outside of the network to reach the app. You can delete this endpoint to prevent external traffic from reaching the app.
  * **Internal endpoint** : A URL used to reach the app deployed to the public space, but it is accessible only within the private network, VPN, or transit gateway (TGW). This type of endpoint cannot be modified or deleted.


An example endpoint URL is `https://my-app.example.com/`. Endpoints enable clients outside of the network to reach the app. Internal endpoints are accessible only within the private network, a VPN, or transit gateway (TGW). To ensure an app is accessible only within the network, use internal endpoints.
You can customize how requests from clients reach the app by configuring:
  * Multiple custom endpoints
The administrator specifies the domains that you can use for the endpoints by configuring the TLS context in the private space settings. For information, see Configuring Domains and Certificates (TLS Context) for a Private Space.
  * Different paths for the app and the endpoint URL
The _path_ is the base path expected by the HTTP Listener in your app, for example `my-app.example.com/v1/api`.
For information, see HTTP Listener Reference - Mule 4.


You can also remove the endpoint to ensure clients outside of the private network cannot make requests to the app.
## Before You Begin
The administrator must set up the TLS contexts for the private space before you can configure the endpoints and paths for the app.
For information, see Configuring Domains and Certificates (TLS Context) for a Private Space.
## Configure Multiple Endpoints
You can enable your app to be reached via multiple endpoints, for example, `my-app.example.com` and `my-old-app.oldname.com`.
To ensure that each endpoint name is unique, use the `app-name` placeholder in the subdomain, or the path if the domain doesn’t include a wildcard.   
---  
To configure multiple endpoints:
  1. When deploying an app to a private space, click the **Ingress** tab.
See Deploying Apps to Private Spaces.
If the app is already deployed:
    1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
    2. Click the app name.
    3. In the navigation menu, click **Settings**.
    4. Click the **Ingress** tab.
  2. Configure the first endpoint:
    1. Select the first domain from the **Domain** drop-down list, for example `*.example.com`.
If the domain includes a wildcard, the **Subdomain** field becomes available.
    2. Enter the subdomain, or enter the `my-app` placeholder in the **Subdomain** field to use the name of the app that you specified in the **Application Name** field as the subdomain.
For information, see placeholders.
    3. Enter the path where the HTTP Listener in the app is listening, for example `v1/api`.
  3. If you want to configure additional endpoints, click **Add Endpoint** and repeat steps 2.1 through 2.3.
  4. Depending on the deployment status, choose either:
     * If you’re ready to deploy the application, click **Deploy**.
     * If this application is deployed, click **Apply Changes**.
  5. Verify that the app can be reached at each configured endpoint.


### Placeholders
The subdomain and path support the following optional lowercase placeholders:
Placeholder | Resolves to  
---|---  
Name of the app that you specified in the **Application Name** field when you deploy the app  
`business-group-id` | Business group ID associated with the app  
`environment-id` | Environment that you deploy the app to  
## Configure a Different Path for the App and the URL Endpoint
You can configure different paths for the app and the URL endpoint. For example, if the app is listening on `my-app.example.com/v1/api` and you want the app to be reachable from the internet using `my-app.example.com/api`. When you rewrite the path URL, the new path applies to all endpoints.
To configure different paths:
  1. Deploy the app to a private space.
  2. Click the **Ingress** tab.
  3. In the **Path** field, enter the path where you want the app to be reachable, for example, `/api`.
  4. In the **Path Rewrite** field, enter the base path expected by the HTTP Listener in your app, for example, `/v1/api`.
This field is available only for apps deployed with custom TLS context.
  5. Click **Apply Changes** to create a new configuration for your application.


## Remove an Endpoint
To remove an endpoint:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Settings**.
  4. Click the **Ingress** tab.
  5. In the endpoint link row, click **X** (**Delete**).


## View the Internal Endpoint for an App
An internal endpoint is accessible from inside the same private space or through the VPN or transit gateway connection for the private space. You cannot make changes to the path or domain for an internal endpoint.
To view or copy the URL for the internal endpoint:
  1. From Anypoint Platform, select **Runtime Manager** > **Applications**.
  2. Click the app name.
  3. In the navigation menu, click **Settings**.
  4. Click the **Ingress** tab.
  5. Hover over **internal endpoint**.


## Send Application-to-Application Requests within a Private Space
In a private space, every application replica exposes an endpoint inside the private space. When you enable inbound traffic, that endpoint is exposed externally.
Every application has a DNS record in the private space internal domain. For example, the DNS record for the application `helloch2` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is:
```
helloch2.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local
```

Because application replicas first search DNS records in the same domain before searching the parent domain, you need only the application name to send a request to another application in the same private space. If both applications are in the same namespace, you need only the application name:
```
http://helloch2:8081/hello
```

If required, replace `http` with `https`.
You can’t send traffic between applications in different namespaces by using `svc.cluster.local` endpoints.   
---  
### Application-to-Application Communication
An application communicates with another application via:
  * The default public DNS name: `app.sxjsip.aus-s1.cloudhub.io`
  * The default internal DNS name (in private spaces only): `app.internal-sxjsip.aus-s1.cloudhub.io`
  * The custom domain name (if configured): `acme.example.com`
  * The cluster local DNS: `app` or `app.envid.svc.cluster.local`


If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, you can use the application’s internal endpoint for internal traffic.
If you use the cluster local endpoint, the traffic doesn’t leave the cluster. However, the cluster local endpoint isn’t highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable.
During disaster recovery, the cluster local DNS endpoint can fail if an application migrates to a new cluster. This is because traffic routed through the local DNS endpoint doesn’t traverse the ingress load balancer, which is essential for directing traffic to the new cluster. However, using other available endpoints forces traffic to pass through the ingress load balancer. The ingress load balancer detects if a disaster recovery event is happening. It also knows if an application linked to a certain endpoint has moved to a new cluster. It then routes traffic to the new cluster if needed.
During node upgrades and scaling, cluster local DNS endpoints remain reachable as long as you deploy multiple application replicas.
The cluster local endpoint allows traffic within the same environment only.
## See Also
  * Deploying Apps to Private Spaces
  * Configuring Domains and Certificates (TLS Context) for a Private Space
  * HTTP Listener Reference - Mule 4