Just over a year ago, we launched the original version of Worktree Actions. It was based on an open source Actions runner, but even early on it was clear it would not be a long-term solution. To make Actions truly competitive, we needed to start from scratch.

The next generation of Worktree Actions, which we’re calling Actions 2.0, is a ground-up rewrite of the Actions orchestrator and VM runtime image. It uses a new custom runtime that provisions on-demand VMs based on an image we built in-house that more closely mimicks GitHub Actions’ environment.

“Actions 2.0” delivers significant improvements across the board:

• Faster job start times – we now keep a number of VMs “hot” under the hood, so most of the time there should be a runner ready to execute your job immediately.
• Updated runtime support – ubuntu-24.04 is now the default for ubuntu-latest, aligning our supported OS and tool versions with GitHub Actions’ state of the art.
• Better GitHub Action compatibility – we’ve completely rebuilt the execution environment to more closely align to the conventions and versions of tools in the official GitHub Actions environment. This should greatly improve wider ecosystem compatibility with Actions and pre-existing workflows.
• Larger runner VM sizes – workflow runs-on labels now can control the size of the VM that runs your Actions workflow, with two new options: ubuntu-latest-lg and ubuntu-24.04-lg, which offer twice the RAM and CPU vCores as the regular VMs (and consume 2x the minutes as regular instances). You can learn more about all the available labels in the documentation.

All of these improvements are immediately available to you and your workflows. If you have a Worktree subscription, you’re all set.

If you self-host your own Actions runner, nothing changes for you. The APIs and protocols integrating with Worktree itself have not changed. If you want to continue to use Gitea’s act_runner on your own infrastructure, you can continue to do so with no changes.

We plan on building a self-hosted shim to allow you to self-host a Worktree Actions runtime, but that is still a work-in-progress.

One thing to note: as we have made the new runtime more compatible with GitHub Actions, some previously-required workarounds may break as they are now unnecessary.

Notably, service ports now make themselves available on localhost, and the service hostname resolution only works in Docker-based actions. This aligns with the expected behaviour of GitHub Actions, but is a departure from the previous “always-Dockerized” runtime. If you reference services by their name instead of their port (eg., pg:5432 instead of localhost:5432), this may break your workflow.