For anyone emacs-curious, you can do a similar thing with org-babel
You can have a plaintext file which is also the program which is also the documentation/notebook/website/etc. It's extremely powerful, and is a compelling example of literate programming.
When you have executable code in the documentation, folks want to follow PR-review workflow with the docs as well - which is a bit more team investment than editing a wiki.
This is exactly what I wanted for our team when I was at AWS. There are so many versions of operations which are just slightly too dangerous to automate, and this provides a path to iteratively building that up. Congratulations!
We recently started using https://marimo.io/ as a replacement for Jupyter notebooks, as it has a number of great improvements, and this seems like a movement in a similar direction.
If it's local-first then it's already subject to rot. Unless they're running it all in containers? In which case local doesn't matter.
If you want to record a runbook, then record a runbook. You can do that a million ways. Text file, confluence doc, screen recording, shell script, etc. People already don't do that; they're not gonna suddenly start doing it more because your UI is fancier.
Personally, I don't want to sit around all day writing code (or docs) to try to get the system to be like X state. I want to manually make it have X state, and then run a tool to dump the state, and later re-run the tool to create (or enforce) that state again. I do not want to write code to try to tell the computer how to get to that state. Nor do I want to write "declarative configuration", which is just more code with a different name. I want to do the thing manually, then snapshot it, then replay it. And I want this to work on any system, anywhere, without dependence on monitoring a Bash shell for commands or something. Just dump state and later reapply state.
My dream tooling is for every tool to have an terminal interface so that I can create comprehensive megabooks to get all the context that lives in my head. i.e. jira, datadog, github etc, all in one pane.
The poor man's version of this - write your runbooks as text files in your source code. And set your editor to "Send to Terminal". I use vim-slime in nvim, vscode has similar functionality.
Document it, version control it, share it, and (semi)automate it. There's no reason to type or copy-paste important commands directly into the terminal.
This post reminded me how much I enjoy doodling with notebooks and UIs like observable and hacks like this -- https://gist.github.com/kahole/651990b888c19b84d5700422daa96.... In a really roundabout way, notebooks take me back to using crouton on my Chromebook and opening a terminal in a browser tab. Also just discovered Deno's Jupyter kernel and feel rather set for good times ...
Congratulations on the launch! I've been following Atuin for a bit and, while I'm not necessarily the intended audience for this runbook feature, love seeing people build fun new things.
Using C# as main language this allowed us to have runbooks using code shared as nuget package and so being able to interact with our own APIs and applications as any other code that runs in production.
Not the best experience to review but it worked for us.
It's kind of sad the direction they took. The last thing I want is my runbooks being held hostage by my desktop with proprietary and possibly paid software.
Kinda related but just the other day I was thinking of the notebook/runbook workflow and wonder if there is a tool like this that also incorporates git checkpoints (either commit or stash) into it. Like top to bottom, associate all the blocks and resulting artifacts with a commit hash. Might be something to vibe code over the weekend.
i think lots of tools try to solve the same mess and i always end up just wanting my stuff all in one place with less hassle, so seeing more takes on this is cool
I'm really confused by products like this and Warp Drive[0]. What does this add over a shell script?
There is a response elsewhere in comments[1] which claims that this is trying to fix the problem of bad documentation, but this has the same fundamental problem. If you a) are responsible for fixing something, b) are unfamiliar with it, and c) the "fixing resources" - whether those are scripts, documentation, or a Runbook/Workflow - you were provided with by the experts are out-of-date; you're SOL and are going to have to get to investigating _anyway_. A runbook and a script are just different points along the spectrum of "how much of this is automated and how much do I have to copy-paste myself?"[2] - both are vulnerable to accuracy-rot.
Atuin Desktop: Runbooks That Run
(blog.atuin.sh)565 points by freetonik 22 April 2025 | 149 comments
Comments
You can have a plaintext file which is also the program which is also the documentation/notebook/website/etc. It's extremely powerful, and is a compelling example of literate programming.
A good take on it here: https://osem.seagl.org/conferences/seagl2019/program/proposa...
The idea has a lot of merit. We even gave a talk about it in JupyterCon Paris 2023 - https://www.youtube.com/watch?v=TUYY2kHrTzs
When you have executable code in the documentation, folks want to follow PR-review workflow with the docs as well - which is a bit more team investment than editing a wiki.
Good luck!
Genuine question. Not familiar with this company or the CLI product.
We recently started using https://marimo.io/ as a replacement for Jupyter notebooks, as it has a number of great improvements, and this seems like a movement in a similar direction.
If you want to record a runbook, then record a runbook. You can do that a million ways. Text file, confluence doc, screen recording, shell script, etc. People already don't do that; they're not gonna suddenly start doing it more because your UI is fancier.
Personally, I don't want to sit around all day writing code (or docs) to try to get the system to be like X state. I want to manually make it have X state, and then run a tool to dump the state, and later re-run the tool to create (or enforce) that state again. I do not want to write code to try to tell the computer how to get to that state. Nor do I want to write "declarative configuration", which is just more code with a different name. I want to do the thing manually, then snapshot it, then replay it. And I want this to work on any system, anywhere, without dependence on monitoring a Bash shell for commands or something. Just dump state and later reapply state.
Document it, version control it, share it, and (semi)automate it. There's no reason to type or copy-paste important commands directly into the terminal.
Using C# as main language this allowed us to have runbooks using code shared as nuget package and so being able to interact with our own APIs and applications as any other code that runs in production.
Not the best experience to review but it worked for us.
There is a response elsewhere in comments[1] which claims that this is trying to fix the problem of bad documentation, but this has the same fundamental problem. If you a) are responsible for fixing something, b) are unfamiliar with it, and c) the "fixing resources" - whether those are scripts, documentation, or a Runbook/Workflow - you were provided with by the experts are out-of-date; you're SOL and are going to have to get to investigating _anyway_. A runbook and a script are just different points along the spectrum of "how much of this is automated and how much do I have to copy-paste myself?"[2] - both are vulnerable to accuracy-rot.
[0]: https://www.warp.dev/warp-drive
[1]: https://news.ycombinator.com/item?id=43766842
[2]: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...