Shared Endpoints

HTTP(S) endpoints can be configured to share their underlying load balancer with other endpoints on the stack, reducing the cost of the endpoint. The main limitations of shared endpoints are:

• Clients using the endpoint must support Server Name Identification (SNI). SNI was first implemented in 2004 and has been nearly universally supported by clients since 2014 so only obscure or legacy clients will have issues connecting.
• Wildcard domains are not supported. Shared endpoints require a fully qualified domain name. A wildcard certificate can be used in conjunction with providing a domain (see Configuration for details).

Creating Shared Endpoints

Shared endpoints can be created:

• By checking the “Shared” box when creating an HTTP(S) endpoint using the Aptible Dashboard.
• By using the --shared flag when creating an HTTP(S) endpoint using the aptible endpoints:https:create CLI command.

Similarly, a dedicated endpoint can be converted to a shared endpoint:

• By checking the “Shared” box when updating a HTTP(S) endpoint using the Aptible Dashboard.
• By using the --shared flag when updating an HTTP(S) endpoint using the aptible endpoints:https:modify CLI command.

Converting to a Dedicated Endpoint

Shared endpoints cannot be converted back to dedicated. To go back to using a dedicated endpoint, create a new dedicated endpoint with the same configuration then delate the shared endpoint when it’s no longer needed.

Configuration

Shared endpoints support the same configuration options as dedicated HTTP(S) endpoints. The only exceptions of note are:

• Shared endpoints using a Custom Certificate must specify a fully qualified domain when creating or migrating to a shared endpoint. This is the --managed-tls-domain option for CLI commands.
• Shared endpoints do not support managed wildcard domains, a fully qualified domain name must be used with Managed TLS.