Atuin: SQLite-backed shell history with encrypted sync
Making your shell magical. Additionally, it provides optional and _fully encrypted_ synchronisation of your history between machines, via an Atuin server.
At a glance
- What is it?
- Atuin replaces your shell history with a SQLite database, adds context like exit codes and durations, and offers optional end-to-end encrypted sync across machines. This review covers its mechanism, setup, and where it falls short.
- Who is it for?
- Adopt Atuin if you want a searchable, context-rich shell history across multiple terminals and machines, and you accept the overhead of a Rust binary and a sync server. Skip it if you prefer minimal tooling or if your shell is not in the supported list (zsh, bash, fish, nushell, xonsh, PowerShell).
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Atuin actually replaces
The project is written in Rust, which shows in its performance ambitions. The README links to a CodSpeed badge, implying a focus on speed. But the real shift is architectural: history becomes queryable data, not a linear file. That opens the door to features like statistics on most-used commands. If you have ever grepped `.bash_history` and wished for structured fields, Atuin is aimed directly at you.
The mechanism: SQLite, hooks, and a search UI
The sync feature is optional. You can use Atuin without any server, purely as a local history replacement. If you enable sync, the README claims "fully encrypted" synchronization. The encryption is end-to-end, meaning the server operator cannot read the data. The README says: "As all history sync is encrypted, I couldn't access your data even if I wanted to." That is a strong claim, but the details of key management are not in the README. You would need to read the sync documentation to understand how keys are derived and stored. The architecture is client-server: you either use the hosted server at atuin.sh or run your own instance. The sync is not a simple file copy; it is a protocol that merges history across machines, handling conflicts.
Getting it running: quickstart commands and config
The install method is a curl pipe to sh, which some users will reject on security grounds. The README does not offer alternative install methods, though the docs likely do. The version in the repository is v18.20.1, released recently, so the project is actively maintained. The command structure is simple: `atuin search`, `atuin import`, `atuin sync`. The search command takes flags like `--exit` and `--after`, which are documented in the README example. That is the extent of the command surface visible in the README.
A genuine limitation: bash-preexec and shell coverage
Another limitation is the reliance on a sync server. Even with end-to-end encryption, you are adding a network dependency. If the server is down, does `atuin sync` block or fail gracefully? The README does not say. For a local-only user, that is irrelevant, but for a sync user, it is a question. The encryption claim is strong, but it also means you cannot recover your history if you lose your key. The README does not discuss key recovery. That is a potential failure mode for the forgetful user.
The wrong tool: when Atuin is overkill
The sync feature, while encrypted, may be a liability for users who are required to keep history on-premises. Even with encryption, sending history to a third-party server, even a self-hosted one, might violate policy. The README does not offer a local-only sync option, though it says "or just don't use sync at all." That is a binary choice: either you sync via an Atuin server or you do not sync. There is no peer-to-peer or file-based sync. For users who want to sync without a server, Atuin is the wrong tool.
Alternatives: the difference in approach
For sync, the alternative is to use a dotfiles manager like GNU Stow or a git repository to sync your `.bash_history` file. That approach is not encrypted by default, and it does not merge conflicts well. Atuin's sync is designed for merging history across machines, which is a different problem. If you only need to share history between two machines, a git repo might be simpler, but it lacks the encryption and conflict resolution. The choice depends on whether you value structured search over simplicity.
Maintenance and upgrade cost
The fact that the tool is written in Rust means it is compiled to a single binary, which is easier to deploy than a Python or Node app. But the shell plugin is a script that must match your shell version. The bash-preexec dependency is a third-party piece that could break with bash updates. That is a maintenance risk. Overall, the upgrade cost is moderate: you need to monitor releases and test your shell integration after each update.
Editorial conclusion
Adopt Atuin if you want a searchable, context-rich shell history across multiple terminals and machines, and you accept the overhead of a Rust binary and a sync server. Skip it if you prefer minimal tooling or if your shell is not in the supported list (zsh, bash, fish, nushell, xonsh, PowerShell). Before adopting, verify the sync encryption model: the README claims end-to-end encryption, but you should confirm the key management details in the docs, especially for self-hosted servers. Also test the bash-preexec integration, since the README notes limitations. Start with `atuin import auto` and `atuin sync` to see if the workflow fits.
Community notes