Bringing Atuin to the Desktop  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: Bringing Atuin to the Desktop - Category: #podcasts - URL: https://share.snipd.com/episode/31dff32c-85aa-4878-b3b7-977d6d67706e ## Document Notes ## Highlights - **Moving Sparks New Momentum** - Ellie moved from London to San Francisco recently and bought a new motorcycle days after arriving. - She uses the change in location to iterate on both lifestyle and product focus. Transcript: Jerod Santo Well, I'm joined once again by Ellie Huxtable with A2N, which has been making my show magical for years now. Ellie, welcome back to the ChangeLog. Ellie Huxtable Hi, great to be here. Jerod Santo Great to have you. You sound closer. You were so far away last time. I think we had a schedule around our different time zones, but now you're in the States. What happened? What changed? Ellie Huxtable I moved to San Francisco. That's been very recent, just like a month ago, but it's been good so far. Jerod Santo Good so far. And where were you before? Somewhere in the UK, right? I was in London. In London. Okay. And you were often on a motorcycle. I remember that part. Ellie Huxtable All the time. Yeah, still am. I bought one like four days after moving here. So that's it. Jerod Santo Did you upgrade? Did you downgrade? ([Time 0:04:47](https://share.snipd.com/snip/7baafd41-3d08-4258-af8c-a878a7709da2)) - **Docs That Actually Execute** - Atuin Desktop treats runbooks as executable documentation, not just static notes. - Embedding terminal and script blocks makes docs both readable and runnable in one place. Transcript: Ellie Huxtable Yeah, sure. So the CLI records every shell command you run, that's kind of the whole point. It makes it really easy to recall them. But what is trickier with that is sort of recording whole workflows. So if you're looking for an individual command, it's great. It's really easy. But if I was looking for, like, how do I set up a new staging environment? How do I onboard a new developer? How do I do something that's a long sequence of steps and maybe needs annotations and various other things? The CLI helped, but didn't solve the problem. We had a whole bunch of discussion over years to be honest, like I've had this idea for a really long time of like how can we solve this essentially documentation problem and Atom and Desktop's The answer there at least didn't in my opinion. So what it is is it's essentially a runbook editor and what I mean by that is we started off by just building something that was good for recording notes and documentation. You can just write English words down and share them with people. But where it gets really powerful is the executable blocks we added. So we have things like terminal blocks, which are, if you imagine Notion with its like database blocks, instead of a database, we have an embedded terminal that you can actually execute A command. And this sort of takes it from a Confluence page that goes stale to something that you can actually run and read in the same place. A lot of people have asked how this is relevant to the CLI, and I can kind of see that it might not be immediately obvious. However, where it does become quite powerful with the CLI is all of the data you've been recording in your case over years in the CLI is accessible in the desktop app too. So you can screw around on your machine, figure something out locally in your terminal. And then when you go to document it later on, you can write down what you did and you can pull in your shell history into the executable blocks. ([Time 0:07:02](https://share.snipd.com/snip/b3856b45-0384-4b88-a83e-4a5e0e7bf0df)) - **Tauri + Rust: Lightweight Native Power** - Atuin Desktop uses Tauri and Rust to combine a lightweight web UI with a performant native backend. - This design prioritizes system integration and speed over shipping a full Chromium bundle. Transcript: Ellie Huxtable Talk about that more if you want later. But we essentially launched a web app locally in Tauri, and it contains an editor called BlockNote, which is a really cool open source project built on top of TipTap and ProseMirror That provides like a block style editor. And we extended that with all of our custom blocks. So to start off with, you're just editing. You have a choice between a local file, which is currently essentially JSON. We're working on that. YAML, sorry, but again, working on that. Or you can use our hub, which you sign up for. You can create an organization or single player, and it provides automatic syncing, offline first, editing, and the idea of that being collaborative style features. Can have multi-cursors with people all zooming around, which we can see being really useful for incidents or helping someone figure something out. As much of it as possible is implemented in Rust. So right now we can't, again, we released this as a beta, there's still a lot of right now it doesn't, but it will going on. But a lot of the execution is written in Rust. ([Time 0:10:48](https://share.snipd.com/snip/9315584e-405d-46c9-941f-17b5dc217059)) - **Design For Collaborative Incident Workflows** - Make the editor and execution environment collaborative and offline-first for incident workflows. - Add multi-cursor and real-time sync to let teams explore and act together during incidents. Transcript: Ellie Huxtable As much of it as possible is implemented in Rust. So right now we can't, again, we released this as a beta, there's still a lot of right now it doesn't, but it will going on. But a lot of the execution is written in Rust. And the idea there is we can bring it to be a runtime, which is embedded in the desktop app that runs in a CLI all over the place for executing runbooks. My kind of long term vision there, I guess, is that current automation is kind of an all or nothing approach. You start off with, you know, someone might maybe have documented something and that's that that alone is a stretch. Or you kind of have to write a million lines of YAML and have it 100% automated. And we find that there's very little in the middle. There's no like happy medium. ([Time 0:11:39](https://share.snipd.com/snip/be1af0d4-4cec-4243-bec1-23e9ca984330)) - **Runbooks Handle Diverse Tasks** - Runbooks cover a wide range: sequential steps, DB operations, local dev, and remote SSH tasks. - Blocks can be powered by command output to make runbooks dynamic and context-aware. Transcript: Ellie Huxtable A bunch of use cases. It could start off just being super simple, almost like what you might write a readme for in our system anyway. So, you know, go install these dependencies, run this migration command, run this command to generate some fixtures, et cetera, et cetera. So it can be very sequential, run this, do this, do that. But we also find that people use them a lot for like database operations. So maybe you need to run a whole bunch of SQL to set up a new schema or migrate from one system to another. And we've made it flexible enough to make that easier too. So our dropdowns, you can power with the output of a shell command to select like an environment you might want to run in or a URI that you might want to use in a query. So there's a lot of database use cases too, but also we use them a lot for our local development. So there's like a collection of maybe values in a local database you need to tweak or files that need generating. You can use them a lot. So you might have a home lab somewhere that has a bunch of setup required and things can run over ssh too so it can show you yeah you can use it for setting up a remote system too so right maybe You need to set up your zfs and then you need to install k3s or docker compose or however you're running things and it can help you with that too. ([Time 0:13:49](https://share.snipd.com/snip/caade0aa-629f-4e98-8f22-b8a4454fa57e)) - **Mitigate Environment Drift Pragmatically** - Consider container integration to reduce environment drift, but weigh developer UX tradeoffs. - Offer contextual blocks (SSH, containers) so steps run where expected across machines. Transcript: Ellie Huxtable Don't currently, but it's something I'm really actively thinking about. We find a lot of people right now just have like a dependency step that does its best to set up the dependencies that you might need. But obviously, like you say, someone else might have a completely different local system than you. The only approach I can think of so far is having a container integration. So we have the concept of contextual blocks, which you would use for specifying that something needs to run over SSH. Currently thinking of doing something similar for containers where I can say, you know, this should run in my local development container, and it will sort of transparently make that Work. I'm not a huge fan of it as an answer. I find containers for local dev to be clunky, especially on Mac when they're on a VM. But I'm also not sure there's actually anything better. ([Time 0:15:52](https://share.snipd.com/snip/032aaec9-4dac-4a67-92ed-a1ca858b7e52)) - **GUI Complexity Beats CLI Variance** - Desktop apps face varied graphical environments, making consistent UX on Linux challenging. - Building a terminal and a text editor together multiplies complexity compared with a CLI tool. Transcript: Ellie Huxtable With the CLI, the hard parts realistically have been the sheer amount of data people have. So if we ever want to change anything with database schemas, it's a migration which like, you know, professionally when we run a really big database migration, it's like, let's really Pay attention to what's going on here. Whereas when we release something, there's like hundreds of thousands of database migrations going on. And if one of them goes wrong, that's someone who's lost data and we have to figure out how to recover that. So it's very like mistakes I might have made a few years ago are sticking around. Right. With the desktop app, it's a different set of challenges. I think it's very, the CLI is quite simple. The command line environment is, it is very varied, but it's still a terminal. You still have command control sequences and various other things. With the graphical app, it's a bit different. People running it on macOS, it's reasonably a consistent experience. But people on Linux, who I really want to support as best we can, the graphical environments differ hugely. So making sure things run consistently for different people has been kind of hard. ([Time 0:19:03](https://share.snipd.com/snip/169070b2-eb8e-41c4-92c6-59ef40541243)) - **Open Client, Guard The Backend** - Open source the desktop client but be cautious about open-sourcing critical sync backends immediately. - Use a closed hub initially to avoid licensing and support traps, then consider opening later. Transcript: Ellie Huxtable So the CLI was, I mean, I could definitely charge people for hosting. I've had a number of people say, oh, let me pay you single digit dollars a month for shell history hosting. And that was nice. However, like the way I looked at it was, I don't want to work on shell history by myself forever. So it needs to have the potential to do more. And it also has to have the potential for it to be more than just me. And we have something like 26,000, 27,000, maybe people syncing their shell history. And I worked out that realistically, 100% of them are not going to sign up to pay. It's going to be quite a low amount. And we can't charge very much for it. So it's quite a niche, realistically. It also really doesn't cost very much in terms of infrastructure to run. I self-host the Postgres on a Hetzner machine. It's cheap, it's really performant, and other than my time, it's not a big sync. Desktop, I think, has a lot more potential in terms of business project. There's a very direct organization use case, potentially even stronger than the single player use case, really. And there's a lot more scope to do really interesting and flexible things with it. It is open source. It's Apache 2. What is not yet open source is the hub for syncing. ([Time 0:27:12](https://share.snipd.com/snip/d44c9bf3-e823-4045-8ff5-d8e7b461ef6b)) - **Companies Pay, Individuals Rarely Do** - Many CLI users won't pay for a low-cost sync service, so product-market fit for hosting is limited. - Companies, not individuals, are the likeliest long-term customers for mature org features. Transcript: Ellie Huxtable Desktop, I think, has a lot more potential in terms of business project. There's a very direct organization use case, potentially even stronger than the single player use case, really. And there's a lot more scope to do really interesting and flexible things with it. It is open source. It's Apache 2. What is not yet open source is the hub for syncing. So we have two types of workspace. You can have an offline workspace, gives you local files on your disk. You can put them in Git, like whatever you want, basically. But the hub is the synchronizing real-time back end and it's not open source right now basically we haven't figured out what to do with it yet and i would very much rather have something Closed source and then six months from now decide to open source it then open source something realize i've backed myself into a corner and then have to do a horrible license change and Jerod Santo It's it's a nightmare right um so yeah we say around these parts is rug pull not cool so definitely keep your cards close to your chest and then if you want to flip one over and show that you Ellie Huxtable Get the ace of spades later fine go ahead and do that but i feel very strongly that if you're running it on your machine it should be open source like if it's a desktop app you should be able To see what's going on you should be able to change it that's a good distinction everything else that's a ([Time 0:28:08](https://share.snipd.com/snip/4d64f2de-14c9-4f1c-a150-68479234483d)) - **Beta Validated By Early Community** - The public beta gained about a thousand hub signups and many users created hundreds of runbooks. - Community feedback via Discord and thoughtful GitHub issues validated the product direction. Transcript: Ellie Huxtable Yeah, it's been really good. We have opt-in, emphasis on opt-in telemetry. Nice. I screwed that up. It's actually opt-out, but you can opt-out on the launcher. So it's right there. So it's opt-out, but you just click a button right there. It's right in your face when you start it up. So it's easy. And it's pretty much what we gained a thousand signups on the hub, which was really cool to see. We've got people making hundreds and hundreds of runbooks, which is also really cool to see. I think the biggest thing for me, though, rather than that telemetry is more the community response. So we have in our Discord, we have a separate channel for the desktop app. And people have been in there really active using it. GitHub issues usually imply there's an issue, but it also implies that people care enough to actually tell you that something's not working for their use case or something's going Wrong and provide a bunch of steps. We've had people provide some actually really thoughtful GitHub issues as well, which has been nice to see and nice to work on. I think for me, it's also good validation. So again, I've been working on this for around a year in one form or another. ([Time 0:34:26](https://share.snipd.com/snip/51e01e16-17e0-49aa-b901-b8fff1e46899)) - **Treat Terminals And Scripts Differently** - Distinguish between interactive terminals and non-interactive scripts in runbooks. - Capture script outputs to feed later blocks and use templates to parameterize runbooks safely. Transcript: Ellie Huxtable That's what it does so it's again it's meant to be flexible enough that you can pick an individual block to run if you need to or rerun or whatever but then if you've built it to be sequential You can just run the whole thing end to end. Nice. Jerod Santo And then I assume it just like stops when certain parts fail because inevitably with somebody else's runbook, it's going to be like, no, you don't have this thing installed. Terminals are the only exception. Ellie Huxtable So terminals need to exit in some way and they won't exit themselves. So because it's an interactive terminal, we don't know when the command you've run is done or when what you're trying to do has finished so you either need to exit the terminal within Jerod Santo Your script or you need to press stop and when you say terminals you're referring to like an interactive thing that's going to go on in here so we have terminals and scripts terminals Ellie Huxtable It will run like like your terminal emulator just in your okay so it's going to like block and wait for a response exactly whereas scripts it's like you just it's like running bash on something Jerod Santo Basically right so in this desktop release the first thing i see is just a curl command that's a script right yeah and then this says terminal install cargo bump that looks like it's also Ellie Huxtable A script oh that's a terminal these are terminals so if you run one of them it'll'll open a terminal locally and run the thing. Gotcha. Jerod Santo I'm afraid to do that. Oh, look at this. Oh, because I can actually stop and I can say no, which I'm glad I can because I'm going to stop it right there. Okay. So terminals are interactive and scripts are just going to run and whatever the response of the script. Cool thing with scripts is we can capture the output. Ellie Huxtable So if we were to capture the output of a terminal, there's like a ton of control codes and various other things going on. But with a script, we can capture the output. And that we save in our local template system. So we support Ginger pretty much. And you can use the output of blocks to feed in as the input of other blocks. So as an example, you might have a Postgres block and the input for that, you might need a database URI that you can only get by running an AWS secrets manager command or like a one password Thing. ([Time 0:37:26](https://share.snipd.com/snip/dce65fd7-e514-4325-acb0-f35675caac0a)) - **Make Runtime UI-Agnostic** - Build a runtime that decouples block execution from the UI so runbooks run anywhere. - Enable CLI and CI execution so teams can test runbooks automatically and on schedules. Transcript: Ellie Huxtable So coming really soon is a new runtime. The current runtime is very much like let's get something that works and see if people like this. And the new runtime is going to be let's make sure things are really, robust and flexible and will allow you to run runbooks from the CLI, which is in my mind, very important because then It allows you to run them in the CI systems as well. So maybe you have a readme that's getting set up and you could actually test your readme and that would be really cool. Maybe you have a bunch of disaster response runbooks. It's really important that they actually work and you don't find out that they don't work at 3am when you need them. And if you get things set up right, maybe you could test that on a schedule in some automated system somewhere. I think it's also important just to be able to execute these things without a desktop app if you really don't want to do it. ([Time 0:43:49](https://share.snipd.com/snip/00b9586b-7f00-4501-8fd4-8fb6a562187c)) - **Front End Should Just Request Execution** - A minimal front end that simply asks 'run this block' unlocks extensibility and alternative UIs. - That separation lets third parties build new front ends while reusing the same execution runtime. Transcript: Ellie Huxtable When you click play on a terminal, there's a bunch that goes on behind the scenes. Currently the front end makes a call to the backend to ask it to open a pseudo terminal, and then it gets a handle back. And then it starts writing to that with the input you've provided it that's like a special case so the front end knows that it's a terminal it knows that it has to open a pty and do x y and z What we're trying to do is get it to the point where the front end just says run this block and that's that's it um and that means that the front end doesn't have to be a desktop app it could Be anything. And it also opens the door to a lot more flexibility in how blocks are defined. So we're not there right now. However, I would love for people to be able to write their own blocks, their own integrations. Whether these are backed by a shell command or some big set of code doesn't really matter. But right now it's very much like every block works but it's like a nice sort of combined effort between the front end and the back end and we'd like it to be the front end is as minimal as Jerod Santo Possible is more minimal does left heavy less heavy lifting so that a different terminal could call runbook and and run it from there was that is that going to require you to first figure Out more more permanent serialization format or you already have that no ([Time 0:44:47](https://share.snipd.com/snip/55bd6aa5-cecc-4bcb-a6d2-3fafd1c68d73)) - **Require Issues Before Major PRs** - Ask for an issue before accepting big feature PRs to avoid wasted contributor effort. - Prefer small fixes and well-discussed features so maintainers can evaluate long-term maintenance cost. Transcript: Ellie Huxtable So we accept contributions from anyone. We accept fixes, especially like quickly. Features, this is something I never really planned out with the CLI because I didn't think anyone would care when I first released that. We never really thought about how to accept feature requests from people. And in the early days, I was very much like, oh my God, someone's built something cool. Let's merge it and let's go. And towards sort of more recently, it's been, you know, is there something I want to maintain long-term? Is this something that people actually want? Or is this just sort of bloat the code for no real reason? For instance, there's been a pull request open for a really long time that I feel kind of bad about, but someone's added PowerShell support, which is super cool. However, when he first opened the pull request, I haven't seen very many pull requests from the guy. And if he's listening, I really appreciate your work and thank you very much. However, when he first opened it, I didn't know if he'd stick around and I made it very clear that I could not maintain a PowerShell integration. It's not something I have any familiarity with. And the dude stuck around for like six months making fixes to various things, making other PRs. And now it's like, well, I have trust in your code. And I also have trust that when you say you're going to stick around and keep it going, you probably will. So that's also a consideration I never really had originally. But jumping back to your original question, open contribution, fixes, like anyone fix anything and open a pull request, I'm super grateful and we'll review it as quickly as possible. ([Time 0:46:26](https://share.snipd.com/snip/65f35647-61bf-4a8a-bdf3-715937a9b4b4))