Atuin Desktop: Runbooks That Run – Now Open Source
Posted3 months agoActive3 months ago
blog.atuin.shTechstoryHigh profile
excitedpositive
Debate
40/100
DevopsProductivityOpen-Source
Key topics
Devops
Productivity
Open-Source
Atuin Desktop, a tool for creating and managing runbooks, has been open-sourced, sparking discussion on its potential uses and comparisons to similar tools like Jupyter notebooks.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
57m
Peak period
33
0-3h
Avg / period
9.6
Comment distribution77 data points
Loading chart...
Based on 77 loaded comments
Key moments
- 01Story posted
Sep 30, 2025 at 4:44 PM EDT
3 months ago
Step 01 - 02First comment
Sep 30, 2025 at 5:41 PM EDT
57m after posting
Step 02 - 03Peak activity
33 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 2, 2025 at 4:55 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45431001Type: storyLast synced: 11/20/2025, 5:36:19 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
BUT it does also make a nice environment for rich text, with markdown support, so can easily replace internal docs in general
In my infrastructure repo the README and playbook files have executable org babel scripts for common debugging activities.
Last week I was trying to `find` something in some directories, failed, `cd`d to my home directory and instinctively hit up-arrow+return to run the search again. At some time prior to this, Atuin had stopped recording new entries without my notice. Want to guess the last entry that Atuin did record?
Go on. Guess.
Yep.
`rm -rf *`
In my home directory.
Luckily I have backups of everything important and didn't actually lose anything, and I'm mainly posting this here as a funny anecdote. But - still - after getting myself set up again I have yet to reinstall Atuin.
Behavior of any system should be just one of: 1. Fully determinate 2. Have enough latency before confirmation (for example, block input for 1 second after displaying a command)
This should apply to history, any fuzzy searching, autocomplete etc
You could also make a mistake by executing command #101 instead of #102.
1) This is why you never type rm -rf * but the absolute path.
2) Furthermore, the command flag -f implies never prompt (taken from a recent GNU coreutils man page):
"-f, --force ignore nonexistent files and arguments, never prompt"
3) This is merely unlinking; the data is still there, not overwritten.
4) You should have backups of your homedir. A filesystem with versioning like ZFS could be of help here, too.
5) Agree with you and add a blacklist to the history, with rm being a primary contender.
6) Instead of rm, use a system where you move files into a trash bin (ie. abstract the unlinking in a user-friendly interface such as the trash bin or recycle bin concept). Examples: https://github.com/imnyang/tsh https://github.com/Byron/trash-rs
Now, I think you could do #5 or #6 (and add `mv` and `dd` as well, but where does the list end?), but I think #1 (using the absolute path) is the easiest to avoid the worst PEBCAK.
It requires you to think about that when doing it ... but, well... I dunno. I really don't ever write `rm -rf *` even in that state of mind. That's like the most evil command one can type into a machine! Who knows what it will do!
I can’t guarantee we never will, but I am only interested in such things if they are genuinely useful
If we won’t use it internally, and no significant % of users will, then it won’t happen
Let us know if you try it and have any feedback or questions at all
It’s definitely baked into the approach here. You could just write a bullet point list of what needs doing. Then maybe sprinkle some blocks on top so the user can do things faster. Then in the end, work towards the whole thing being automated
No all or nothing, no YAML needed ;)
If I press run at the top, then it doesn't stop for me to do 3 before executing 4. Should I run each step individually for this usecase? Will changing the directory in step 1 apply to steps 2 and 4 if I don't hit run at the top?
Despite the goal of homogenizing each clients environment to simplify support, there will always be uniqueness amongst them. Having documentation that can be collaboratively edited, versioned, that is also runnable to perform management tasks would be a HUGE deal.
I understand this isn't the target audience, but its exciting to imagine the possibilities of other uses.
We're aiming to be flexible enough, so that if you can do it in a terminal then you can _also_ do it with a runbook
https://github.com/atuinsh/desktop/blob/main/CLA.md
Happy to answer any questions
We don’t yet support full remote execution, but should do soon!
---
The runbook files are just YAML (for now). They're more verbose than I'd like, but do convey a lot of information - both rich text and executable.
There's an example here: https://github.com/atuinsh/desktop/blob/8ebed35d7efe68a92363...
I'm aware this isn't ideal, and longer term we want something that looks much more like markdown. A key requirement for us here is that it's easy + convenient to type - just like normal markdown - so putting everything as a code block annotation isn't ideal.
The current sketch of what that could be looks like this: https://forum.atuin.sh/t/desktop-devlog-markdown-vim-local-f...
Would love to know if you have any thoughts!
There's an example here: https://github.com/atuinsh/desktop/blob/8ebed35d7efe68a92363...
I'm aware this isn't ideal, and longer term we want something that looks much more like markdown. A key requirement for us here is that it's easy + convenient to type - just like normal markdown - so putting everything as a code block annotation isn't ideal.
The current sketch of what that could be looks like this: https://forum.atuin.sh/t/desktop-devlog-markdown-vim-local-f...
Would love to know if you have any thoughts!
we already support execution of script + terminal blocks over SSH, but want much tighter integration. Parallel execution is certainly a part of that too. anything else you'd want to see?
issue: https://github.com/atuinsh/desktop/issues/47
It's noob friendly. Even the installation process. No need to manage python. Just use the app.
> Besides this seemingly needs an account with Atuin to work.
You don't need an account to use it.
so you run like this:
And all the commands can be listed by running: If I wanted a chart the command could spit out a png somewhere and tell you about it.There are no dependencies to run the script, and if any of the commands needed dependencies you could just put them in setup and call setup from a commmand.
You could keep the content of your bash functions close to intact by adding the ".ONESHELL:" target (and some \$).
https://github.com/casey/just
Also, I noticed there's only 60+ Atuin sponsors (at Github), so added myself. Been using Atuin for some while now. Hopefully their work is sustainable.
I would pay you guys for E2EE syncing, but I think it’s free at the moment. Charge me!
Here's an article on how to accomplish this: https://howardism.org/Technical/Emacs/literate-devops.html
I love Warp Notebooks. And I'm definitely interested in At in Desktop, although, if they are run books, the naming isn't quite matching up for me.
#NamingIsHard
Glad to see that this is now open from closed beta!
On first glance, I kind of like it - bash scripts are often ideal due to being largely universal and can minimize dependancies.
I find and if this can be an in between to let anyone access configs, or processes, that might be bearable.