This is a huge change, the first big step towards making runbooks a core automation primitive.
If you ever encountered flaky references, missing state, or inconsistent execution, this release fixes it. Runbooks now maintain their state, behave predictably, and do not require constant re-runs to get back to where you were. We’re laying the foundation for advanced real-time collaboration and CLI-based execution.
What’s new?
persistent
Runbooks remain exactly as you left them. No reconstruction. No replay blocks. No friction.
Previously, when you closed a tab or restarted iTunes desktop, all execution state was lost. With the new execution engine, your runbooks Context – which stores all execution related state – now persists even across app restarts and tab closes.
In practice, this means that if you run a command like mktemp -d By creating a tempflory directory and saving it to a template variable, that output is now saved locally with your runbook. Close the tab or restart the app, and the context is still there – no need to re-execute the block to recreate your working environment.
reproducible
The runbook behaves as you expect, every time.
The new engine establishes a clear, predictable flow of context through your runbooks. Each block in your document can only affect the block below it. This means that, for example, setting a template variable in a block will not affect the use of the same variable in any blocks above it.
With the basics nailed down, we took the template system further:
templates everywhere
We now run all user input through our template system. This means you can use templates in variable names, context blocks like directory and ssh, and any other block that accepts input.
If you find any input that doesn’t behave this way, it’s a bug and we’d love to know about it!
self-referential variable
Since all inputs move through the template system and variables do not affect the context above them, it is possible for a variable to refer to itself. For example, you can trim the newline from a named variable output by using { var.output } and hand it back output again. You can go as deep as you want with variable metaprogramming:
Two types of execution context
The new engine offers two types of references:
passive context Set automatically when your document is updated. This also includes:
- change working directory
- environment variable definitions
- ssh host connection
- Explicit template variable assignment
This context persists even when you are not actively running the block.
active context The block is set during execution and represents the output and runtime state of the actively running block. When you run a block again, its active context is cleared and recreated.
The active context contains data that we store locally with your runbook, and persists even across app restarts. A new button in the runbook header allows you to clear all active references to a runbook if you want to start with a clean slate.
Foundation for Future Collaboration
Atuin Desktop already supports real-time collaboration for editing runbook content, but the new architecture lays the groundwork to take this even further, preparing us for true collaborative execution. Imagine sharing not just documents, but the entire running environment – including environment setup, terminal output, and database query results – all in real time!
What has changed?
no more global references
Because this update changes the way blocks affect each other, you may need to adjust any runbooks that depend on the old, global context (for example, setting a template variable in a block and using that variable in the block). Above the block that set it).
editor variable sync
In the old execution system, the editor block contained a toggle that kept the value in the editor in sync with a variable in the context. Whenever a variable changes anywhere in the document, the editor will update to reflect that change.
This behavior does not work well with new architecture, where the context is no longer global. For this reason, we’ve removed the toggle, and replaced it with a UI element that allows you to manually set the editor content to the value of any defined template variable.
No standard errors in script variables
Script output variables now only capture stdout, not stderr. This prevents error messages and diagnostics from getting mixed up with your actual output data, making the variables cleaner and more reliable. You will still see both stdout and stderr in the block’s terminal output.
under the hood
For those interested in the technical details, this update involves rewriting our entire block execution system, moving it from our old front-end system written in TypeScript to an existing Rust backend. We have migrated each block to the new system, making the execution of each block more portable and reliable.
Each block implements a BlockBehavior Attribute, defining some key methods:
passive_context– Returns any references that should be set passively any time changes are made to the documentexecute– executes the block by sending a message to the client to update the active context and any other relevant data
There are other useful properties as well, such as QueryBlockBehaviorWhich allows to quickly define a block that queries the data source and returns a table of results.
combined with qualities like MessageChannel (to facilitate sending messages to the customer) and BlockContextStorage (for saving and loading reference data), the new architecture has allowed us to completely extract the runtime system from the desktop application, paving the way for runbooks to be executed in any environment.
For all the interesting details, see the execution system documentation in the repository.
What will happen next?
cli runner
Run your runbook from any terminal, even if Atuin Desktop is not installed. The new runtime is designed to be environment-agnostic, making it possible to execute runbooks in CI/CD pipelines, deployment scripts, or automated workflows.
better serial performance
Running a runbook from top to bottom – what we call “serial execution” – depends on the runbook currently being open in your editor. Thanks to the new runtime, we will be able to overcome this bottleneck, and introduce better tooling to monitor and control runbook execution inside and outside the app.
secret management
Secrets are one of the most important aspects of infrastructure management, and runbooks are no exception. We’ll add first-class support for storing and retrieving end-to-end encrypted secrets both locally and in the cloud.
Markdown-based runbook
Markdown is ubiquitous in modern development. It is lightweight, easy to read and can be edited in any text editor. We’re working on storing runbooks as pure Markdown files with embedded metadata, making them more portable and easier to write, review, and version control.
try it out
The new execution engine is now available in v0.2.0. Update your iTunes desktop installation and experience the difference yourself.
discord: discord
Forum: Forum
<a href