v0.52.0

Workspace Management Rework

TL;DR

• Targets now have state (e.g. Daytona is aware of the state of the EC2 instance used by the AWS provider)
• Workspaces can be created/deleted on running targets (e.g. No more need to create an EC2 instance for every workspace. Keep one running and add workspaces to it)
• Remote runners can offload jobs to remote machines
• Use workspace labels to group workspaces and filter them with daytona ls --label
• If you want to help us test this major update, jump straight into the How to test section below

Description

Projects have been renamed to Workspaces.
Workspaces have been renamed to Targets
Targets have been renamed to Target Configs.

Project configs have also been renamed to Templates; e.g. daytona template list

Workspaces have been "detached" from targets - they can now be created inside and deleted from targets removing the
need to provision a new target whenever creating a workspace.

Resource state management issues have been resolved - new resource states regarding starting/stopping/deleting workspaces or e.g. running builds are introduced.

Issues for a "remote provisioner" and "remote image builder" have been solved by introducing Runners - a standalone mode/component in charge of asynchronously fetching and running workspace/target/build creation and other processes.
This allows users to e.g. create a remote VM, install Daytona and connect it to the existing Daytona Server to create workspaces. Local provisioning/building is managed by the Local Runner which can be disabled through the Daytona
Server configuration.

Runners are responsible for managing providers and each one has its own set of providers. When creating target configs, users are prompted to choose a runner to link it to.

If you want to add a remote runners, run:

daytona server runner create

You will get a command that you can run to configure and start a remote runner.

Introduced Workspace Labels allowing workspaces to be grouped and filtered by user-defined text fields.

It is now possible to SSH into targets and use the Daytona binary inside of them to view info and read logs.

Container registries are no longer managed through a CLI command and are now managed by environment variables instead

Purging Daytona now delegates removal of Resources (workspaces, targets, builds) to the user because they are now treated independently.

Telemetry has been updated/improved to match the changes.

CLI commands arguments and aliases have been made to be more consistent.

README.md has been redone to adhere to the changes and trimmed of a large amount of the content.

Other release changes

Features

• feat: add support for Positron IDE by @hunnywar in #1590
• feat: add support for VSCodium Insiders by @hunnywar in #1702
• feat: add install.ps1 for windows by @hunnywar in #1567
• feat: toolbox exec session management by @Tpuljak in #1732
• feat: default to single runner in prompt by @idagelic in #1735

Fixes

• fix: PR list pagination by @Tpuljak in #1709
• fix: daytona update command with elevated perms by @unsuman in #1713
• fix: fail cli await if deleting resource errors by @idagelic in #1742

Telemetry

• removed tracking API requests and responses
• improved telemetry events to track all resource changes

Samples

• samples: add Deno, Prolog, Racket, Zig by @s-celles in #1737

Chores and tests

• build(deps): bump github.com/compose-spec/compose-go/v2 from 2.1.3 to 2.4.1 by @dependabot in #1736
• build(deps): bump github.com/go-git/go-git/v5 from 5.12.1-0.20240617075238-c127d1b35535 to 5.13.0 by @dependabot in #1734

Breaking changes

Before updating, users will need to remove the entire Daytona configuration from your system with daytona purge or:

Linux:

rm -rf ~/.config/daytona

Mac:

rm -rf ~/Library/Application\ Support/daytona

Windows (PowerShell):

Remove-Item -Recurse -Force "C:\Users\<USERNAME>\AppData\Roaming\daytona"

Full Changelog: v0.51.0...v0.52.0