Atuin Desktop: Runbooks That Run

Original Article ↗ Hacker News Discussion ↗

Purpose and Use Case

  • Framed as “runbooks that run”: operational documentation plus executable commands in one place.
  • Aimed at real-world workflows that are too ad‑hoc or risky to fully automate via CI/CD, but too important to leave as copy‑paste snippets in wikis or spreadsheets.
  • Supporters emphasize: easier, less error‑prone than copying commands from Confluence / text files; good for incident response when on‑call staff are unfamiliar with a system.

Comparison to Notebooks & Literate Programming

  • Some see it as closer to literate programming for shells than to Jupyter: prose + commands + output together.
  • Others ask why not use Jupyter (! / % shell commands) or tools like marimo, polyglot notebooks, Livebook.
  • Objections to Jupyter for ops: Python/runtime dependency hell, fragile environments, and cell execution order issues.
  • Org‑mode / org‑babel, BBEdit shell worksheets, Runme, xiki, and similar tools are cited as prior art with similar ideas.

Reproducibility, Ordering & State

  • Concerns that “notebook style” encourages partial execution, leading to hidden state and ordering bugs in runbooks.
  • Author mentions planned dependency system (e.g., “A must run before B”, time‑bounded) and the need for branching and idempotent steps.
  • Extended side‑discussion: reproducibility vs “blobs of state” (Docker images, Terraform state, Nix/Guix, Bazel).
    • Some argue for declarative tools and explicit state; others want tools that infer and dump current state automatically.

Local‑First, Rot & Environment Drift

  • Skeptics argue local‑first workflows risk “rot”: commands rely on each person’s evolving laptop environment.
  • Counterpoint: containers or centralized execution could mitigate this, but then it’s less truly “local”.

Open Source, Stack, and Business Model

  • Desktop app built with Tauri (Rust) and a backend using Elixir/Phoenix plus some Rust.
  • Plan: desktop app will be open‑sourced later; server likely proprietary.
  • Sparks a strong debate:
    • One side criticizes “open source cosplay” and mixing free/proprietary components.
    • Others argue developers must be able to build paid products on top of OSS to sustain work.

Value vs Simple Shell Scripts

  • Some remain unconvinced, asking what it adds over plain scripts with comments and editor “send to terminal” features.
  • Fans argue the integrated UI, logging, history, and easier updating of “living docs” justify a dedicated tool, especially for teams and less‑technical operators.