HTTP(S) Endpoints
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
--sharedflag when creating an HTTP(S) endpoint using theaptible endpoints:https:createCLI command.
- By checking the “Shared” box when updating a HTTP(S) endpoint using the Aptible Dashboard.
- By using the
--sharedflag when updating an HTTP(S) endpoint using theaptible endpoints:https:modifyCLI 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-domainoption for CLI commands. - Shared endpoints do not support managed wildcard domains, a fully qualified domain name must be used with Managed TLS.