Skip to content

Releases: dstackai/dstack

0.18.31

18 Dec 11:55
@r4victor r4victor
0.18.31
cc96bf4
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.31 Latest
Latest

Assigning service account to GCP VMs

Like all major clouds, GCP supports running a VM on behalf of a managed identity using a service account. Now you can assign a service account to a GCP VM with dstack by specifying the vm_service_account property in the GCP config:

type: gcp
project_id: myproject
vm_service_account: [email protected]
creds:
  type: default

Assigning a service account to a VM can be used to access GCP resources from within runs. Another use case is using firewall rules that rely on the service account as the target. Such rules are typical for Shared VPC setups when admins of a host project can create firewall rules for service projects based on their service accounts.

$HOME improvements

Following support for non-root users in Docker images, dstack improves handling of users' home directories. Most importantly, the HOME environment variable is set according to /etc/passwd, and the home directory is created automatically if it does not exist.

The update opens up new possibilities including the use of an empty volume for /home:

type: dev-environment
ide: vscode
image: ubuntu
user: ubuntu
volumes:
  - volume-aws:/home

AWS Volumes with non-Nitro instances

dstack users previously reported AWS Volumes not working with some instance types. This is now fixed and tested for all instance types supported by dstack including older Xen-based instances like the P3 family.

Deprecations

  • The home_dir and setup parameters in run configurations have been deprecated. If you're using setup, move setup commands to the top of init.

What's Changed

Full Changelog: 0.18.30...0.18.31

Contributors

un-def, r4victor, and 2 other contributors
Assets 2
Loading

0.18.30

12 Dec 11:09
@r4victor r4victor
0.18.30
8d82a35
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.30

AWS Capacity Reservations and Capacity Blocks

dstack now allows provisioning AWS instances using Capacity Reservations and Capacity Blocks. Given a CapacityReservationId, you can specify it in a fleet or a run configuration:

type: fleet
nodes: 1
name: my-cr-fleet
reservation: cr-0f45ab39cd64a1cee

The instance will use the reserved capacity, so as long as you have enough, the provisioning is guaranteed to succeed.

Non-root users in Docker images

Previously, dstack always executed the workload as root, ignoring the user property set in the image. Now, dstack executes the workload with the default image user, and you can override it with a new user property:

type: task
image: nvcr.io/nim/meta/llama-3.1-8b-instruct
user: nim

The format of the user property is the same as Docker uses: username[:groupname], uid[:gid], and so on.

Improved dstack apply and repos UX

Previously, dstack apply used the current directory as the repo that's made available within the run at /workflow. The directory had to be initialized with dstack init before running dstack apply.

Now you can pass --repo to dstack apply. It can be a path to a local directory or a remote Git repo URL. The specified repo will be available within the run at /workflow. You can also specify --no-repo if the run doesn't need any repo. With --repo or --no-repo specified, you don't need to run dstack init:

$ dstack apply -f task.dstack.yaml --repo .
$ dstack apply -f task.dstack.yaml --repo ../parent_dir
$ dstack apply -f task.dstack.yaml --repo https://github.com/dstackai/dstack.git
$ dstack apply -f task.dstack.yaml --no-repo

Specifying --repo explicitly can be useful when running dstack apply from scripts, pipelines, or CI. dstack init stays relevant for use cases when you work with dstack apply interactively and want to set up the repo to work with once.

Lightweight pip install dstack

pip install dstack used to install all the dstack server dependencies. Now pip install dstack installs only the CLI and Python API, which is optimal for use cases when a remote dstack server is used. You can do pip install "dstack[server]" to install the server or do pip install "dstack[all]" to install the server with all backends supported.

Breaking changes

  • pip install dstack no longer install the server dependencies. If you relied on it to install the server, ensure you use pip install "dstack[server]" or pip install "dstack[all]".

What's Changed

New Contributors

Full Changelog: 0.18.29...0.18.30

Contributors

un-def, solovyevt, and 4 other contributors
Assets 2
Loading

0.18.29

04 Dec 10:45
@r4victor r4victor
0.18.29
c10b1fe
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.29

Support internal_ip for SSH fleet clusters

It's now possible to specify instance IP addresses used for communication inside SSH fleet clusters using the internal_ip property:

type: fleet
name: my-ssh-fleet
placement: cluster
ssh_config:
  user: ubuntu
  identity_file: ~/.ssh/dstack/key.pem
  hosts:
    - hostname: "3.79.203.200"
      internal_ip: "172.17.0.1"
    - hostname: "18.184.67.100"
      internal_ip: "172.18.0.2"

If internal_ip is not specified, dstack automatically detects internal IPs by inspecting network interfaces. This works when all instances have IPs belonging to the same subnet and are accessible on those IPs. The explicitly specified internal_ip enables networking configurations when the instances are accessible on IPs that do not belong to the same subnet.

UX enhancements for dstack apply

The dstack apply command gets many improvements including more concise and consistent output and better error reporting. When applying run configurations, dstack apply now prints a table similar to the dstack ps output:

✗ dstack apply
 Project                main                                 
 User                   admin                                
 ...                                  

Submit a new run? [y/n]: y
 NAME           BACKEND          RESOURCES       PRICE     STATUS   SUBMITTED 
 spicy-tiger-1  gcp              2xCPU, 8GB,     $0.06701  running  14:52     
                (us-central1)    100.0GB (disk)                               

spicy-tiger-1 provisioning completed (running)

What's Changed

New Contributors

Full Changelog: 0.18.28...0.18.29

Contributors

un-def, olgenn, and 3 other contributors
Assets 2
Loading

0.18.28

26 Nov 11:32
@un-def un-def
0.18.28
de0ff48
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.28

CLI improvements

  • Added alias -R for --reuse with dstack apply
  • Shorten model URL output
  • dstack apply and dstack attach no longer rely on external tools such as ps and grep on Unix-like systems and powershell on Windows. With this change, it's now possible to use dstack CLI client in minimal environments such as Docker containers, including the official dstackai/dstack image

What's Changed

Full Changelog: 0.18.27...0.18.28

Contributors

un-def, jvstme, and peterschmidt85
Assets 2
Loading

0.18.27

22 Nov 09:42
@jvstme jvstme
0.18.27
d8b6ccb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.27

UI/UX improvements

This release fixes a login issue in the control plane UI and introduces other UI/UX improvements.

What's Changed

Full Changelog: 0.18.26...0.18.27

Contributors

olgenn, jvstme, and peterschmidt85
Assets 2
Loading

0.18.26

20 Nov 16:02
@un-def un-def
0.18.26
b26d4ed
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.26

Git

Previously, when you called dstack init, Git credentials were reused between users of the same project and repository.

Starting with this release, to improve security, dstack no longer shares Git credentials across users.

Warning

If you submitted credentials earlier with dstack init, they will continue to work. However, it is recommended that each user call dstack init again to ensure they do not reuse credentials from other users.

Deleting legacy credentials

To ensure no credentials submitted earlier are shared across users, you can run the following SQL statements:

UPDATE repos SET creds = NULL;

UI

This update brings a few UI improvements:

  • Added Delete button to the Volumes page
  • Added Refresh button to all pages with lists: Runs, Models, Fleets, Volumes, Projects
  • Improved Code button on the model page

What's changed

  • Implement per-user repo creds storage by @un-def in #2004
  • [UI] Add Refresh button to all pages with lists by @olgenn in #2007
  • [UI] Include base URL and authentication token in the code snippets by @olgenn in #2006
  • [UI] The Code button improvements on the Model page by @olgenn in #2001
  • [UI] It's not possible to select and delete volumes by @olgenn in #2000
  • [UI] [Bug]: Services without model mapping are displayed in Models UI by @olgenn in #1993
  • Ensure sshd privsep dir in container is properly set up by @un-def in #2008
  • [Docs] Many minor improvements to docs and examples by @peterschmidt85 in #2013
  • [Docs] Services without a gateway by @jvstme in #2011
  • [Docs] Add deployment section with vLLM, TGI and NIM. Remove alignment handbook by @Bihan in #1990
  • [Docs] Updated Installation and Server deployment guides to include CloudFormation by @peterschmidt85
  • [Docs] Update services docs to reflect that gateway is now optional by @peterschmidt85 in #2005
  • [Examples] Add a CloudFormation template showing how to deploy dstack server to AWS by @peterschmidt85 in #1944
  • [Examples] Add Airflow example by @r4victor in #1991

Full changelog: 0.18.25...0.18.26

Contributors

un-def, olgenn, and 4 other contributors
Assets 2
Loading

0.18.25

13 Nov 10:40
@r4victor r4victor
0.18.25
e8aebe8
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.25

Multiple volumes per mount point

It's now possible to specify a list of volumes for a mount point in run configurations:

...
volumes:
  - name: [my-aws-eu-west-1-volume, my-aws-us-east-1-volume]
    path: /volume_data

dstack will choose and mount one volume from the list. This can be used to increase GPU availability by specifying different volumes for different regions, which is desirable for use cases like caching. Previously, it was possible to specify only one volume per mount point, so if there was no compute capacity in the volume's region, provisioning would fail.

DSTACK_NODES_IPS environment variable

A new DSTACK_NODES_IPS environment variable is now available for multi-node tasks. It contains a list of internal IP addresses of all nodes in the cluster, e.g. DSTACK_NODES_IPS="10.128.0.47\n10.128.0.48\n10.128.0.49". This feature enables cluster workloads that require configuring IP addresses of all the nodes.

What's Changed

Full Changelog: 0.18.24...0.18.25

Contributors

un-def, r4victor, and deep-diver
Assets 2
Loading

0.18.24

08 Nov 09:43
@jvstme jvstme
0.18.24
537b43b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.24

Backward compatibility

This update includes a hotfix for a backward compatibility issue that prevented CLI v0.18.23 from working with older versions of the dstack server.

What's changed

  • Fix backward compatibility broken in 0.18.23 by @jvstme in #1974

Full changelog: 0.18.23...0.18.24

Contributors

jvstme
Assets 2
Loading

0.18.23

07 Nov 20:54
@jvstme jvstme
0.18.23
2912670
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.23

Gateway is optional

Previously, running any service required setting up a gateway. With this update, a gateway is no longer needed to run a service for development purposes.

Service endpoint

  • If no gateway is created, the service’s endpoint will be accessible at <dstack server URL>/proxy/services/<project name>/<run name>/.
  • If a service has a model mapping, the model will be accessible via the OpenAI-compatible endpoint at <dstack server URL>/proxy/models/<project name>/.

Note

While this change makes it much easier to use services for development, you will still need a gateway if you want to use a custom domain, enable HTTPS, or use auto-scaling.

Gateway property

If a gateway is created but isn’t needed for a service, set the gateway property to false. If you have multiple gateways, you can choose one by setting gateway to the name of the gateway.

Model mapping

If the model is in OpenAI format, you can now use a shorter syntax for model mapping—simply set the model property to the model's name.

type: service

image: ollama/ollama
commands:
  - ollama serve &
  - sleep 3
  - ollama pull llama3.1
  - fg
port: 11434

model: llama3.1

The longer syntax with more settings remains available.

Updating running services

Previously, updating a service’s configuration required restarting it. Now, you can update the replicas and scaling properties in place. Just run dstack apply, and the changes will take effect. New replicas will be created while the old ones continue running.

What's changed

New contributors

Full changelog: 0.18.22...0.18.23

Contributors

un-def, olgenn, and 5 other contributors
Assets 2
Loading

0.18.22

31 Oct 15:00
@jvstme jvstme
0.18.22
19cd2fd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
0.18.22

Custom OS images on AWS

You can now configure your own AMIs for the AWS backend.

projects:
- name: main
  backends:
  - type: aws
    creds:
      type: default
    os_images:
      cpu:
        name: my-cpu-ami
        user: admin
      nvidia:
        name: my-nvidia-ami
        user: ubuntu

This can be used as an alternative way to bring your software or data to the AWS instance and mount it into your runs using Instance volumes.

See the AWS backend reference for details on configuring OS images. Support for custom OS images in other backends is coming in future releases.

What's Changed

Full Changelog: 0.18.21...0.18.22

Contributors

un-def, olgenn, and 3 other contributors
Assets 2
Loading