Atuin Desktop: Runbooks That Run
76 comments
·April 22, 2025pm90
turtlebits
Not sure what you mean- github and datadog already have official CLI tools.
tecleandor
Maybe something like wtfutil? (Although wtf development has been stuck for a year, but I guess that's the general idea...)
buremba
You might like MCP then.
x-complexity
> You might like MCP then.
That's entirely different to what's being desired by GP.
> > 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.
My perspective on this is essentially having jira/datadog/github/etc be pluggable into the CLI, and where standard bash commands & pipes can be used without major restrictions. (Something akin to Yahoo Pipes)
MCP is highly centered around LLMs analyzing user requests & creating queries to be run on MCP servers. What's being desired here doesn't centralize around LLMs in any sense at all.
omneity
It’s actually not too far off. Yes MCP is designed for LLM interactions, but we observed that it’s an invocation API that’s pretty generic. So we built a package format that encapsulates computations and makes them accessible from any of MCP, REST, JSON-RPC over WS (the generic cousin of MCP)..
We build logic once and make it automatically accessible from any of these consumption methods, in a standardized way to our clients, and I am indeed piping some of these directly in the CLI to jq and others for analysis.
janwandersun
[dead]
gyrovagueGeist
All the problems of reproducibility in Python notebooks (https://arxiv.org/abs/2308.07333, https://leomurta.github.io/papers/pimentel2019a.pdf) with the power of a terminal.
milkshakes
what are the problems you're talking about? your references seem to refer to reproducing scientific publications, dependency issues, and cell execution ordering.
this project appears to be intended for operational documentation / living runbooks. it doesn't really seem like the same use case.
rtpg
I mean it feels pretty obvious to me that cell execution order is a pretty real issue for a runbook with a bunch of steps if you're not careful.
I do think that given the fragile nature of shell scripts people tend to write their operation workflows in a pretty idempotent way, though...
ellieh
agreed - we actually have a dependency system in the works too!
you can define + declare ordering with dependency specification on the edges of the graph (ie A must run before B, but B can run as often as you'd like within 10 mins of A)
noodletheworld
I mean, is it worse than having it:
- in excel
- in a confluence document
- in a text file on your desktop
The use case this addresses is 'adhoc activites must be performed without being totally chaotic'.
Obviously a nice one-click/trigger based CI/CD deployment pipeline is lovely, but uh, this is the real world. There are plenty of cases where that's simply either not possible, or not worth the effort to setup.
I think this is great; if I have one suggestion it would just be integrated logging so there's an immutable shared record of what was actually done as well. I would love to be able to see that Bob started the 'recover user profile because db sync error' runbook but didn't finish running it, and exactly when that happened.
If you think it's a terrible idea, then uh, what's your suggestion?
I'm pretty tired of copy-pasting commands from confluence. I think that's, I dunno, unambiguously terrible, and depressingly common.
One time scripts that are executed in a privileged remote container also works, but at the end of that day, those script tend to be specific and have to be invoked with custom arguments, which, guess what, usually turn up as a sequence of operations in a runbook; query db for user id (copy-paste SQL) -> run script with id (copy paste to terminal) -> query db to check it worked (copy paste SQL) -> trigger notification workflow with user id if it did (login to X and click on button Y), etc.
null
shadowgovt
Agreed. The problem with reproducing Jupyter runbooks in academia is that someone thought a Jupyter runbook is a way to convey information from one person to another. Those are an awful model for that.
As an on-the-fly debugging tool, they're great: you get a REPL that isn't actively painful to use, a history (roughly, since the state is live and every cell is not run every time) of commands run, and visualization at key points in the program to check as you go your assumptions are sound.
theLiminator
Give marimo a try, it's much better for reproducibility.
packetlost
This is more like literate programming (but for shells) than jupyter notebooks.
mananaysiempre
Literate programming really needs the ability to reorder, otherwise it’s just sparkling notebooks. (Except for Haskell, which is order-independent enough as it is that the distinction rarely matters.)
0xbadcafebee
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.
LinXitoW
So you then have binary blobs of state without any documentation of how or why it is the way it is? That doesn't seem maintainable.
Dockerfiles are basically this, but with a file documenting the different steps you took to get to that state.
dewey
That’s not what they are saying. They are saying that the system where you have to declare everything manually is annoying (which it is), ideally it would record the changes while you make changes and then deduplicate them, remove unnecessary ones to arrive at the final playbook that can be replayed if needed.
pram
Sounds like you want autoexpect!
jimbokun
That was the Docker manifesto.
x-complexity
> That was the Docker manifesto.
It essentially still is.
Unless the Dockerfiles are kept secret, any container can be replicated from the given Dockerfile. Barring extreme (distro/system/hardware)-level quirks, a Docker container should be able to run anywhere that Linux can.
spott
A container can very rarely be reproduced by a dockerfile.
I imagine with a lot of discipline (no apt update, no “latest” tag, no internet access) you can make a reproducible docker file…. But it is far from normal.
manquer
You are mixing build time reproduction with run time ones.
Docker images (not files) help with the run time consistency .
Docker (files) barely scratch the surface of build reproducibility. Most applications depend on the distribution package manager ( apt, apk etc) and language package manager (npm, cargo, etc), both sets of them have various challenges in consistent dependency resolution.
In addition build steps might have ordering challenges RPC calls to remote services no longer running and so on.
Anyone trying to to build a docker image from 10 years back experiences this problem
milkshakes
what happens when you want to tweak something you did in the middle of this process? do you have to go through the whole flow again manually to make a single change?
0xbadcafebee
I imagine you could either A) just modify the dumped state, B) paramaterize it, C) have the program split up the state into transactions and modify those. The program will probably have to take more than one step, in order, in order to accomplish everything. If it fails, you'd want it to try to undo it, ala transactions. And since it can do all that, it can stop, start, or resume at specific steps.
Like, Terraform has always sucked because there was no way to dump existing resources as new code. So a team at Google made a tool to do it (Terraform-er). If Terraform had already had that feature, and if it didn't rely on having pre-existing state to manage resources, that would be like 90% of the way to what I'd want. Just dump resources as code, then let me re-run the code, and if I want I can modify the code to ask me for inputs or change things. (People think of Terraform as only working on Cloud resources, but you could (for example) make an Ubuntu Linux provider that just configures Ubuntu for you, if you wanted)
kiitos
Any notion of state that satisfies requirements like
> Just dump state and later reapply state
is necessarily declarative.
> Just dump resources as code,
What is the code for this resource?
VM foo1
Memory 16GiB
Network mynet1
floathub
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.
A good take on it here: https://osem.seagl.org/conferences/seagl2019/program/proposa...
spudlyo
Thanks for the shout-out! I think org-babel is really well suited for this task, and can make some really great documentation. You can check out the video[0] from the talk and a git repo[1] with a more advanced demonstration.
kstrauser
Similar with BBEdit's Shell Worksheets, which mingle prose with commands you can run with a keypress.
ymarketing
[dead]
dheerkt
How is this different from a local Jupyter notebook? Can we not do this with ! or % in a .ipynb?
Genuine question. Not familiar with this company or the CLI product.
RestartKernel
Jupyter Notebooks have always felt a bit hacky for terminal purposes to me, so I'm excited to give this a shot.
elAhmo
Looks interesting!
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.
huntaub
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!
account-5
I can't say I see the point in this. Can someone explain what I'm missing? Why would I use this over a simple shell script?
joh6nn
My experience with runbooks has been:
- I am on a team that oversees a bunch of stuff, some of which I am very hands-on with and comfortable with, and some of which I am vaguely aware exists, but rarely touch
- X, a member of the latter category, breaks
- Everyone who actually knows about X is on vacation/dead/in a meeting
- Fortunately, there is a document that explains what to do in this situation
- It is somehow both obsolete and wrong, a true miracle of bad info
So that is the problem this is trying to solve.
Having discussed this with the creator some[1], the intent here (as I understand it) is to build something like a cross between Jupyter Notebooks and Ansible Tower: documentation, scripts, and metrics that all live next to each other in a way that makes it easier to know what's wrong, how to fix it, and if the fix worked
[1]Disclosure: I help mod the atuin Discord
BLanen
If the fix/solution would be easily describable and automate-able, it wouldn't/shouldn't be a problem anyway. I don't see how this solves anything.
mmooss
> It is somehow both obsolete and wrong, a true miracle of bad info
How does Atuin solve that problem? It seems to me that inaccurate and obsolete information can be in an Atuin document as easily as in a text document, wiki, etc., but possibly I'm not seeing something?
joh6nn
I'm just a community mod, not a dev on the project, so take this with a grain of salt:
I believe the intent is that you get bidirectional selective sync between your terminal and the docs, so that if what's in the docs is out of date or wrong, then whatever you did to actually fix things can be synced back to the docs to reduce the friction of keeping the docs updated.
roblh
To me, it seems like it's because the thing you're fixing is actually the "runbook" that's being run. Instead of separating the documentation from the code, they're married together so it's easier to keep them in sync because you aren't having to remind yourself to go edit this secondary location when you make a quick change.
I'm cautiously curious about something like this, although I haven't tried it personally.
johnQdeveloper
Well, what is the purpose of deployments being built in ansible or deployer or whatever tooling as a general rule? And then packaging, say, extra python scripts to perform common tasks then dumping it all in a git repo?
Some people just like a particular workflow or tooling flow and build it really. Maybe it works for enough people to have a viable market, maybe not.
I am just using a PHP deployment process for no reason other than feeling like it for personal projects and it handles 60% of the work without me needing to do anything. But any runbooks for it are tasks built into the tool and in the same git repo for the entire server deployment. I'm not gonna put it in some random place or a shell script that I need to remember separate commands for.
Code, for programmers, is inherently self-documenting if you keep a simple functional style without any complexity with comments on the occasional section that isn't just "Create a MySQL user, roll the MySQL user's password, update the related services with the new password/user combination, remove the old user that the fired employee has credentials to on the off chance we failed to block them at the VPN" kind of stuff.
jimbokun
Seems like this is literate programming for shell scripts.
Thus “Runbooks That Run.”
freedomben
Will this be open source like Atuin CLI and the sync server are? Is this going to be productized?
gniting
Most likely not free. Regardless, happy to see this be announced!
stevelacy
Have been following along with the development, glad to see it announced!
celera
This looks super similar to https://runme.dev
scubbo
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.
[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-...
brunoqc
> I'm really confused by products like this and Warp Drive[0]. What does this add over a shell script?
Because everything is a start-up now.
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.