You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, dstack supports issuing ACME certificates for gateways automatically via HTTP challenge (e.g. Lets Encrypt). This is not possible for internal-facing gateways. So, dstack supports http-only services for such gateways after #1171.
As the first option to enable https on gateways without public IPs, we decided to allow users to specify their AWS Certificate Manager (ACM) certificates when creating gateways. This approach should be familiar to AWS users and would not require permissions to manage DNS zones.
To support this, we'll provision such private gateways behind a load balancer with a certificate attached to the LB.
We focus on ACM support for internal-facing gateways, but we may also allow choosing ACM certificates instead of Lets Encrypt for public-facing gateways.
The text was updated successfully, but these errors were encountered:
Currently, dstack supports issuing ACME certificates for gateways automatically via HTTP challenge (e.g. Lets Encrypt). This is not possible for internal-facing gateways. So, dstack supports http-only services for such gateways after #1171.
As the first option to enable https on gateways without public IPs, we decided to allow users to specify their AWS Certificate Manager (ACM) certificates when creating gateways. This approach should be familiar to AWS users and would not require permissions to manage DNS zones.
To support this, we'll provision such private gateways behind a load balancer with a certificate attached to the LB.
We focus on ACM support for internal-facing gateways, but we may also allow choosing ACM certificates instead of Lets Encrypt for public-facing gateways.
The text was updated successfully, but these errors were encountered: