Repository navigation
Tags: dstackai/dstack
Tags
Resend gateway config before re-registering services (#4388) The running gateway replica pipeline re-registers services after a gateway loses its state, e.g. when the gateway is reinstalled, but it never resends the global config. Certificates for the re-registered services are then requested from certbot's default ACME server instead of the configured one (staging, or an EAB CA). Only a server restart resent the config, through init_gateways. Submit the config before any service registration. The call is idempotent and happens only on ticks that register services. If it fails, skip the sync until the next tick rather than issue a certificate from the wrong server. Co-authored-by: Claude Opus 5.5 <[email protected]>
Add OCI `experimental_instance_types` setting (#4329) Add an OCI backend setting that accepts a list of shape names to allow provisioning in addition to the standard supported instance families. Only works for shapes included in `dstack`'s pricing catalog (`gpuhunt`). This setting can be used to test various shapes that were not yet tested internally at `dstack`. ```yaml experimental_instance_types: [BM.GPU.RTXPRO.8] ```
Support ALB for GCP gateways (#4279) `dstack` now creates and manages an Application Load Balancer for GCP gateways when `load_balancer` is set to `{ type: alb }`. ```yaml type: gateway name: gcp-gateway backend: gcp region: europe-west9 domain: example.com load_balancer: type: alb replicas: 2 certificate: null public_ip: false ``` This allows you to have more than one GCP gateway replica, with load balancing handled automatically by `dstack`. ```shell $ dstack gateway list NAME BACKEND HOSTNAME DOMAIN DEFAULT STATUS gcp-gateway 10.200.0.53 example.com ✓ running replica=0 gcp (europe-west9) 10.200.0.54 running replica=1 gcp (europe-west9) 10.200.0.55 running ``` GCP ALB is supported for both `public_ip: false` and `public_ip: true` gateways. Currently, it is only supported with `certificate: null` (no HTTPS).
Support in-place update for service `gateway` (#4221) The `gateway` property in service configurations can now be updated in-place. ```shell $ dstack apply -f my-service.dstack.yml Active run my-service already exists. Detected changes that can be updated in-place: - Configuration properties: - gateway Update the run? [y/n]: y NAME BACKEND GPU PRICE STATUS SUBMITTED my-service aws (us-east-2) - $0.0005 (spot) running 09:22 my-service provisioning completed (running) Service is published at: http://my-service.second-gateway.example.com ``` This allows you to reassign a service to a different gateway without stopping the service. ```shell $ dstack event [2026-08-27 09:28:33] [run my-service, gateway second-gateway] Service assigned to gateway [2026-08-27 09:28:33] [👤admin] [run my-service] Run updated. Deployment: 1. Changed fields: configuration.gateway [2026-08-27 09:28:39] [run my-service, gateway-replica first-gateway-0] Service unregistered [2026-08-27 09:28:39] [job my-service-0-0, gateway-replica first-gateway-0] Service replica unregistered [2026-08-27 09:28:41] [run my-service, gateway-replica second-gateway-0] Service registered [2026-08-27 09:28:41] [job my-service-0-0, gateway-replica second-gateway-0] Service replica registered ``` Migrating between gateways would typically result in service downtime while you are rerouting your client traffic to the new gateway. During reassignment, the service may also be unavailable on both gateways for a brief period (several seconds). Migration from a gateway to running without a gateway (`gateway: false`) and vice versa is also supported.
PreviousNext