What tools do you use for Omarchy dotfile management and configuration?

[kmf]

On the Mac and Ubuntu I used mackup

I've seen tools like BlackDon dcli tool for Arch (very cool), managing config declaratively, like NixOS, feels right to me.

What seems to work the best for Omarchy. Which offers the right balance, custom keybindings, additional themes, custom waybar config and extra applications.

I was think of just jumping in with Ansible to do something, suggestions?
What is the tried and tested patterns for Arch?

[knothhe]

I use chezmoi for both macOS and omarchy, it's great.

[farangkao]

chezmoi is great.
i use it daily so that i even created some alias for easier usage.
Especially useful to setup multiple machines with the same configs. I also recommend to change the diff viewer to Neovim.

[ghrubi]

Typecraft has a great video on customizing your Omarchy setup and dotfiles. He uses GNU Stow.

https://youtu.be/d23jFJmcaMI?si=vLTGCzCnYakOun78

[kmf]

Found this: https://dotfiles.github.io/utilities/

[EFrMG]

I gave some opinions around these related threads:
#191 (reply in thread)
#3228 (comment)
#5588 (comment)

So, it is clear to me, and after quite some time of use and looking around for real alternatives myself, that nothing quite surpasses Chezmoi.

The issue then is how would one implement it in Omarchy in particular.
I'd say that it is tricky, because tracking all files related to 'Omarchy' configurations would be noisy for most Chezmoi users, even if possible by just checking which files lie someplace like ~/.local/share/omarchy/config/* (and running chezmoi add).

I'd leave it at recommending the best tool for the job on the manual, and seeing if the user wants to learn to use Chezmoi, which is easy enough as one mostly uses 2 or 3 commands (add, apply, diff), along with setting up his own git directory and GH repository for those files.
The main problem that would be solved, after all, is how to add other configurations outside of the sensible defaults Omarchy has (in which case, there would be no default set of files to track); but also, it would help to track if changes the user makes to the defaults are changed by migrations eventually.

[farangkao]

chezmoi supports ignore files, so you can specify in the root folder which folders or file types it shouldn't track.

[iop098321qwe]

I use Chezmoi pretty regularly as well, and I think @dhh could work some real magic by integrating something like it directly into Omarchy.

For those of us with multiple Linux machines, having a built-in way to sync our preferred settings, dotfiles, and configuration changes across systems would be incredibly useful. I have several Linux laptops myself, and being able to carry over the tweaks I’ve made on one machine to the others would make the experience much more seamless.

I also think this would fit really well with Omarchy’s goal of making a polished, pre-configured, but still highly malleable Linux experience more accessible. Having this functionality built in could remove a lot of the setup and complexity around managing dotfiles, especially for newer users.

I could see this being a really compelling addition.

[EFrMG]

There seems to have been some updates recently on future plans about this using a custom tool: https://github.com/basecamp/omarchy/blob/quattro/plans/dots.md
I would like integrating something more like Chezmoi too, but hey!

[jdx]

One more option, since mise already ships with Omarchy: mise dot. Unlike Stow or chezmoi, your files can stay where they are. There's no source directory and no symlinks. mise dot track ~/.config/hypr/bindings.lua starts keeping the file's history. A background service saves your edits, mise dot rollback restores an earlier version, and an optional private Git remote syncs your machines. If you prefer the Stow or chezmoi approach, it can also create symlinks, copies, or templates. It can also install your extra pacman and AUR packages through [bootstrap.packages].

It works today with mise 2026.9.9 or newer; you don't need anything from Omarchy. Guide: https://mise.jdx.dev/bootstrap/setup.html

I'm the mise author, and I'm working on a PR to build this into Omarchy (proposal in #11029). Coming from chezmoi or Stow, your feedback would be especially useful: what's missing, and what would stop you switching?

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: 2.1.289.

[farangkao]

i'm happy to test it out, i'm a heavy chezmoi user (multiple machines installed with omarchy) and also had stow for a while.
by the way thanks for the great mise-en-place, i do already use it for any coding project i'm working on, even if it's just a shell script, love the "run " feature.

Give me some days to test your 'dot' feature with my setup, for constructive feedback.
Where you would like to have it, here or in your own repo?

[jdx]

great! you can tag me here or there, doesn't matter to me

[EFrMG]

The [bootstrap.packages] is something Chezmoi lacks and what makes me use setup scripts for different machines, although I suspect pacman packages would still have to depend on a bash script setup.

My biggest concern there is the lack of a source directory, as editing text on the source to be applied is handy quite often; Stow is kind of the opposite to Chezmoi in this regard, coming from a time when people had to build everything from source and mirror binaries and man pages to a destination (not source).

Thank you for sharing here! I will see to try it as well.

[jdx]

No bash involved for pacman: https://mise.jdx.dev/bootstrap/packages/pacman.html

mise dotfiles support 3 main workflows:

1. chezmoi style: a source directory applied to a target with copy/template modes
2. stow style: symlink mode
3. mise style: tracking real files in place

I use a mix, but mise style is my preferred.

[nickp73]

Thanks @jdx mise took about 5 minutes. By far a much quicker way than Stow.

[farangkao]

@jdx : great work.

I only tested the recommended mise-style.
The Testing and Report was done with help of GLM-5.3, but with heavy manual testing (none automated work, only guidance).

mise dot test report — 2026.10.3, track-mode end-to-end

Setup: two fresh Omarchy VMs (mise 2026.10.3 via omarchy's mise-bin repo),
self-hosted Gitea as the origin, 168 dotfiles migrated from a mature chezmoi
setup, age encryption with two machine keys plus an offline recovery key in a
password manager. Sync modes manual and sync both exercised.

What we proved (all positive)

• Full migration of a chezmoi estate into track-mode; day-2 flow with the
  watcher auto-capturing edits (edit trigger, unattended, encrypted files
  included).
• History: rollback/undo with an append-only operation log; batched,
  described checkpoints (save -d, one checkpoint for N changed files).
• Encryption: ciphertext-only at rest (verified at git-blob level), decrypt
  round-trip via rollback, recipient rotation, fresh-machine bootstrap --adopt decrypting with the machine's own key, and a full disaster-recovery
  drill: machine wiped of all mise state and identity, rebuilt using ONLY the
  recovery key — files, enrollment, decryption, all restored.
• Bidirectional sync between two live machines through the origin.
• The security design works in practice: --yes does NOT approve plaintext
  (tested); the push-side audits (reachable-commit encryption check + the
  secret-line scanner) are excellent ideas.

Findings / suggestions

1. Pending changes are invisible in mise dot status. With the watcher
   off and an unsaved edit, status is silent; mise dot history diff shows
   it (path | changed). Suggest surfacing a pending count/pointer in
   status's history section — status is the command everyone runs first.

2. The plaintext WARN fires on every command once allow_plaintext is
   recorded, forever. Suggest warning once at allow-time and again when an
   origin actually syncs — per-command warning fatigue defeats the guardrail.
   The offending file was an secrets.sh.example file with TOKEN="Dummy" entries.
   There should be a real opt-out to avoid such messages for false positives.
   Is there a way to suppress the per-command plaintext WARN for an explicitly
   allowed file? We found no setting.

3. Bulk-track footguns.
   a. With stdin redirected (scripted while read loop), the plaintext
   confirmation prompt consumed the next list line as its answer and
   aborted: expected y/yes or n/no, got ".config/starship.toml".
   Suggest reading /dev/tty for prompts, or failing cleanly with a
   pointer to --allow-plaintext when stdin is not a TTY.
   b. mise dot track -y <dir> silently swept 200 browser-profile files
   into history — the interactive "(N files, X KiB)" preview never
   displays under -y. Suggest surfacing file-count/size for large
   tracks even under -y, or requiring explicit opt-in for directory
   recursion.

4. Recipient rotation vs. save no-op. The encryption docs say a
   recipients change "re-encrypts each file the next time it is saved", but
   save is a documented no-op for unchanged content — so unchanged encrypted
   files never re-encrypt until their content happens to change. We had to
   touch files to force it (and an untouched file correctly blocked a second
   machine's adopt with cannot unlock). Suggest save --re-encrypt (or
   save detecting recipient drift), plus a stale-encryption report: which
   encrypted files' latest version doesn't include all current recipients.

5. bootstrap --adopt hard-aborts on the first un-decryptable file,
   naming only that one. With several stale files you fix-and-retry blind.
   Suggest listing all locked files before aborting, or quarantining them
   and proceeding with the readable set.

6. Adopted machines don't inherit mise's own configuration. After adopt:
   no watcher declaration ("automatic capture: not declared"), no local
   [dotfiles] table (status prints "nothing configured in [dotfiles]"
   directly above healthy 168-entry tracking — confusing), and presumably
   no [history.encryption] recipients in config form (open question: does
   an adopted machine saving an encrypted file use the manifest's
   recipients?). untrack on inherited entries works via config.local.toml
   overrides — nice. Sharpest suggestion: a first-class story for tracking
   ~/.config/mise/config.toml itself; that would restore table + watcher

   • recipients literally on adopt and close the loop completely.

7. Checkpoint IDs vs. listings don't visibly align. history --path
   showed checkpoints 6 and 8 for a file while rollback reported "rolled
   back to checkpoint 7"; undo referenced 10 with 9 unaccounted
   (internal before/after ghosts?). Cosmetic, but disorienting when you're
   reasoning about history mid-incident.

---

Full transcripts and step-by-step repros available for any of these. Overall:
genuinely impressed — track-mode replaced a mature chezmoi setup in an
evening of testing, and the encryption + multi-machine story is already
solid. The items above are rough edges, not blockers.

[jdx]

@farangkao all of the above, including mise dot save --re-encrypt and the unsaved-changes list in mise dot status, shipped in mise 2026.10.6. Thanks again for the detailed testing.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5-5; version: 2.1.293.

[farangkao]

@jdx : me and my AI friend ,did another clean-room test to proof that encryption works with added recipients.

In-Detail

Clean-room repro of your #4 — you were right, and the behavior is actually
broader than you described.

Setup: fresh private repo, two fresh VMs (mise 2026.10.3), dummy secrets
only, watcher never installed (manual saves only, so every checkpoint was
initiated by hand).

1. VM3 = author: age identity, recipients = [VM3] only, two files
   tracked with mise dot track --encrypt, origin set --sync manual,
   published. Verified on a clean host clone: both blobs carry exactly 1
   X25519 stanza, manifest has 1 recipient.
2. Generated VM4's age key, appended its public key on VM3
   (grep-verified: 2 keys in [history.encryption]).
3. The test, on VM3: mise dot save ~/.config/repro-alpha.toml -d "plain save after recipients change" — targeted at ONE file whose content
   was byte-identical (no edit, no echo, nothing).
4. Result: the save fired (no no-op) and produced a checkpoint in which
   • repro-alpha.toml went 1 → 2 stanzas,
   • repro-beta.toml ALSO went 1 → 2 stanzas — a file I did not save and
     never touched,
   • manifest.json recipients went 1 → 2.
     So a single targeted save re-encrypted every encrypted tracked file to
     the new recipients, not just the file it was given.
5. Published, re-verified the same numbers on a fresh host clone
   (on-disk files are mise-encrypted-file-v1 framed ciphertext, 2
   stanzas each, no plaintext).
6. VM4: mise bootstrap --adopt <repo> → both files restored and decrypt
   with VM4's own key. End-to-end consistent.

And the confession: my original "no-op" report was contaminated. At the
time, my recipients edit had not actually been written to disk (editor
buffer never saved), so content AND recipients were unchanged — the save
correctly did nothing. Sorry for the noise, and thanks for pushing back;
the repro was worth it.

One small aside from the same session: right after track + save,
~/.local/state/mise/history/repo.git did not exist yet (checkpoints
lived in index/; the git layer only appeared later, around origin setup).
Not a problem — it just surprised me when I tried to inspect blobs
locally before any origin was configured.

[farangkao]

@jdx : I played around with mise dot more ,and my decision to switch to it from chezmoi is already settled.

love the --machine switch, need to try it, but sounds exactly the solution for the few files that can't be easily shared, like omarchy's monitor configuration ,but still makes sense to keep track of them.

profile / environment

Only one thing i might not understood correctly is the handling of the --profile switch in connection with the track-mode.
what happened:

• in my config.toml the entry was attached with variants = [{ profile = "dot-3" }]
• i didn't set any environment like MISE_ENV or miserc.local.toml
• sync happened
• in my git instance i could see a folder created like home@dot-3 ,so everything looked like expected
• on my vm-4, i tried to get the file, mise dot pull didn't pull it -> expected
• i set miserc.local.toml to env = ["dot-3"] ,mise dot pull didn't pull it.
• i tried with mise -E dot-3 dot pull -> nothing
• i went back into my vm-3 ,where the original lies
• and after a sync the git entry was gone (no more home@dot3) ,the local file and config.toml entry with --profile was still present
• mise dot pull then complained about the difference, so i kept the local version, added dot-3 into my miserc.local.toml on vm-3 too
• mise dot sync
• git repo had the home@dot-3 again
• vm4: file came with mise dot pull -> good

so it did work ,but was a bit confusing, if it first didn't land in the git repo, i would have thought of maybe i need to specify the profile before i sync or use miserc.config.toml. it wasn't also not obvious from 'mise dot status' that files were skipped because of their profile setting, this would have helped.

Further Feedback

i also need to test the templating options, i noticed while reading the documentation.
I also notices that the table with the mode and keys : https://mise.jdx.dev/dotfiles/reference.html#modes-and-keys ,is very hard to read because of the many columns. maybe a link to just the table would help the display of all entries and columns in one view.

I understand you tried to cater to every developers prefered method, but this caused a bit of a overly expansive "mise dot".
maybe you create a recommended setup/operation section, where you only concentrate on your prefered way and the necessary steps and commands, while have the full documentation still lists all the possibilities to make this solution more easy looking on first-glance ;)

Many thanks for your efforts and feel free to contact me for any further testing or feedback i can help you with.

[jdx]

I understand you tried to cater to every developers prefered method

that's not quite it, it's more that i want to support setups like my own where i want some combination of the different strategies rather than having to go all in on one

looking into the rest of these

[iop098321qwe]

I utilize chezmoi templates for my monitor config and seem to have no issue between machines. I'm going to try out mise myself and see if a simpleton like myself can offer any further input.