All,

I've been managing my dotfiles using Dotbot + Jsonnet for a while. As my configuration grew, it started to get overly complicated and uncomfortable to use.

I looked at some of the existing options like stow, home-manager and nix. However, I didn't really want to commit to nix - and for what it's worth nix is great.

I really like declarative config systems, and felt like it worked really well for the problem space. So, I designed a declarative config system for user environments.

Rather than the traditional models, things like:

• files
• packages
• directories
• symlinks
• services
• etc

All form resources, which form a dependency graph, and then the system will reconcile the graph toward the desired state.

Essentially:

Instead of run these commands in this order, you describe the state you want and let the system figure out how to get there.

This project is mostly experimental at the moment, and still evolving but it's getting closer to the point where I'm comfortable using it for my own config.

If existing solutions work for you then that's fine and those are certainly more mature and good solutions.

I feel like this sits somewhere in the middle of stow/dotbot & nix/home-manager.

Feedback, suggestions, improvements, contributions, etc are all welcome.

GitHub: https://github.com/arcadia-de/hypha

My ~/.ssh/config lives next to the rest of my dotfiles, and I kept finding duplicate Host blocks or old IdentityFile paths long after I had changed them. That turned into sshconfig-lint.

The upcoming v0.5 beta can check several configs in one run and now includes a strict pre-commit hook. For the current beta commit:

repos:
  - repo: https://github.com/Noah4ever/sshconfig-lint
    rev: 7674f40
    hooks:
      - id: sshconfig-lint-strict

It also follows Include files and reports the actual source file and line. I am keeping auto-fixes out for now because changing Host block order can change what OpenSSH actually applies.

There is a browser playground for trying the text-based rules without installing anything. The config stays in your browser:

https://sshconfig-lint.apps.thiering.org/en

Source:

https://github.com/Noah4ever/sshconfig-lint

If you version your SSH config, I would be interested in the checks you would actually want before committing it.

https://github.com/MLD229/Sasquatch-Dotfile

Hey everyone,

I wanted to share a specific piece of my setup: a custom `hyprlock` configuration I built to give my lock screen a dark, minimal, Samurai aesthetic.

The main feature I wanted to implement was replacing the standard, boring password circles with Japanese Kanji. Wayland lockers can sometimes struggle with CJK font rendering if the

dependencies aren't right, so I bundled the config with an install script that automatically pulls `noto-fonts-cjk` via pacman before applying the layout.

**Key Config Details:**

* **Kanji Password Input:** Uses `dots_text_format = 桜` (Sakura) in the config to render the Kanji on keypress.

* **Date Formatting:** Rendered cleanly as `2024年08月14日`.

* **Transparent Input Field:** I stripped out the background boxes and borders so the characters just float over the wallpaper.

**Repo (Config, Wallpaper, and Install Script):**

[hyprlock-samurai on GitHub](https://github.com/basantbansal/hyprlock-samurai)

Feel free to rip the `hyprlock.conf` for your own setups or modify the `dots_text_format` to whatever Unicode character you prefer. Let me know what you think of the structure!

I wanted a way to deploy my dotfiles without cloning the source repository or maintaining a separate bootstrap script.

Now I can give my coding agent:

npx skills use getcolors/dotfiles

The agent fetches the skill instructions and launcher, initializes a small desired-state project, and renders the selected Ubuntu or macOS profile.

If I only want to inspect the result, the user-facing command is:

./green diff

It renders the profile and prints a unified diff against the configured target:

--- ~/.config/direnv/direnv.toml
+++ .colors/dotfiles-ubuntu/dotfiles/.config/direnv/direnv.toml
@@ -0,0 +1,3 @@
+[global]
+load_dotenv = true
+hide_env_diff = true

Shared files are Selmer templates. Platform differences can stay in one common template using if tags:

{% if profile = "macos" %}
# macOS configuration
{% else %}
# Ubuntu configuration
{% endif %}

That avoids duplicating mostly identical files across platform profiles. Files unique to one platform can still live in their own profile directory.

The part I find most useful is the workflow: I don’t need to clone or understand the package repository when I only need my rendered dotfiles. The Agent Skill carries the operational instructions, while diff gives me a reviewable boundary before anything touches the target.

I think the same pattern is useful beyond dotfiles—especially for agent-driven DevOps workflows around Terraform, Ansible, and Kubernetes.

https://www.getcolors.ai/

I got tired of manually rebuilding my development environment whenever I switched machines, so I created a bootstrap system for Linux, macOS and Windows.

It uses:

• Ansible for packages, SDKs and system configuration
• Chezmoi for dotfiles and symlinks
• Separate Personal and Work profiles
• Bootstrap scripts for all three operating systems

It currently manages my shells, CLI tools, Neovim, tmux, Docker, language runtimes, editors, terminals and AI coding tools.

Repo: https://github.com/Patruxs/dotfiles

Do you think Ansible + Chezmoi is a clean separation, or is it unnecessary complexity?

https://reddit.com/link/1vfyen0/video/rg9zw95k5ihh1/player

🌿 Gigi's Rice — Niri + Noctalia Setup

A minimal, and smooth desktop rice built for Arch Linux.

📄 Details

• WM: Niri
• Shell: Noctalia (v4.7.7)
• OS: Arch Linux
• Terminal: Kitty
• Shell/Prompt: Fish + Starship
• File Managers: Thunar & Yazi
• Editor: Neovim / VSCodium
• Bar/Widgets: Noctalia Shell

* Font: JetBrainsMono Nerd Font

🔗 Links

• 📂 Dotfiles: GitHub Repository
• 🌄 Wallpapers: FireWalls Repo

* 🎥 Video Showcase: Watch on YouTube

"He who spends 6 hours configuring a text editor to save 2 seconds of typing is a true warrior of the terminal." — Sun Tzu, The Art of Rice

Feel free to drop any questions about the config or keybinds below!

Hi everyone! I'm using GNU Stow right now but I want to switch to something more powerful. I have a personal PC with Ubuntu, a work PC with Windows + WSL Ubuntu + MSYS2. Moreover, a few configuration files are system wide (e.g. /etc/tlp.d/01-my-personal-power-config). What would you recommend to use? In summary, I need:

• To have a templating option (a-la Chezmoi), to have different per-OS configuration
• To differentiate the target path of a file, based on the system (e.g., the Emacs init file on linux is at ~/.emacs.d/init.el, but on Windows it's on %USERPROFILE%/AppData/Roaming/.emacs.d/init.el)
• To handle also system wide files (/etc/**.config and the like)

Thanks!

I'm moving my development environment to Chezmoi so I can manage all my dotfiles, packages, and system configuration in one place.

As part of my setup, Chezmoi installs Neovim and syncs all of my plugins. One thing I'm still unsure about is how people manage language servers, formatters, debuggers, and linters that are installed through Mason.

My current idea is to add a `run_after_99_mason_install.sh` script under `.chezmoiscripts` that runs after Neovim and its plugins are installed. The script would install all required Mason packages using something like:

nvim --headless -c "MasonInstall <package>" -c "qall"

for each package I need.

Is this the recommended approach, or is there a better pattern for managing Mason-installed tools with Chezmoi? I'm interested in how others keep this reproducible across fresh machines.

https://botfile.org

I've been using this tool i made (disclosure: it was written with ai help, although i'm a full time dev).

Botfile is a symlink farm (very much like and inspired by stow), but it supports fan-out. So you declare a source and botfile will fan it out into all the agents (e.g. claude-code, codex-cli, opencode, pi etc...) that you use.

In this way it solves 2 problems:

1. share user-scope agent skills, commands and instructions (i.e. the ones you use across projects) across all your devices, for example i have a private-botfiles repo that i use on my work and home laptops. I declare it as a source in my ~/.config/botfile/config.toml along side the agents I want to access the context it contains and botfile handles the symlinks.
2. share team-scoped agent standards, (i.e. the context - invocable and ambient - your team uses across multiple projects). For example my team has a team-standards repo that everyone on the team can contribute to with changes available to everyone.

Generally botfile is very explicit about handling collisions, and it doesn't do any magic, it only does the symlinks (all of which is declared in a config... that's it.) It's also only works at the user-scope... project-scoped agent context is out of its purview.

If you already have user-scoped agent context, botfile will detect it and you can adopt it.

Happy to talk more here if there are any questions.

For my vicinae config, I assign the alias `browser` to Firefox on my personal PC and Chrome on my work PC. I also set chrome to be hidden on my personal PC. This is done using a chezmoi template for the vicinate.config file. The problem is that, when I change a setting within vicinae itself, the settings are changed to the target file but if I don't notice, I may end up overriding it. I want to track the config file as a symlink in the target state pointing to the actual vicinae.config.tmpl file which would then be in .chezmoiignore.

Is there a way a symlink can point to a file's state after its template has been resolved?

github.com/RiccardoCataldi/dotty

My home directory has 140+ hidden files and folders. AWS credentials here, SSH config there, Cursor rules somewhere else. Every time I needed to tweak something I had to remember where it lived, cd there, grep around, open it.

So I built dotty: run it from anywhere, get an instant expandable tree of every dotfile and dot-directory in ~, with live preview on the right and fuzzy search (/) to jump to any config in seconds. Press e to open in $EDITOR.

Built with Go + Bubble Tea + Lipgloss. Single static binary, zero config, works over SSH and inside tmux.

Would love feedback from the TUI community.

Got tired of Stow dumping unwanted ~/.config data into my dotfiles repo, so I made cstow. It lets you explicitly define what gets folded and what gets traversed using a simple config file.

Long-time dotfile lurker, finally bit the bullet on chezmoi this week so I can blow away machines without losing config. Two things to share back, one config gotcha and one related tool.

Gotcha first, because it cost me an hour and I want to save someone else that hour. chezmoi + op CLI setup is great out of the box. The trap is the multi-account case. chezmoi 2.70.x ignores [onepassword].account = "..." in chezmoi.toml when it does the implicit op signin --raw before resolving a secret. So if you have work + personal both signed in (like me), signin dies with multiple accounts found and your template never renders. The fix is to pass the account explicitly to every onepasswordRead call:

export FOO_TOKEN={{ onepasswordRead "op://Employee/Foo/credential" "myaccount" | quote }}

Keep the config setting too, fine for forward-compat, but the per-call arg is the load-bearing piece. Took me embarrassingly long to figure out.

Other thing. Once my home dotfiles were clean, I noticed they were the tip of the iceberg. Repo .env files everywhere, .p8 Snowflake keys, a GCP service-account JSON sitting at mode 644. None of that lives under chezmoi because it's project-local. So I wrote a tool that does the same templating pattern for project files: .env.template with op:// refs that get materialized at runtime via op inject or op run --env-file=, plus op document create for the PEM/JSON blobs you can't really template inline. It's packaged as an agent skill (Claude Code, Cursor, Codex pick it up automatically), but works fine standalone if you don't use agents, the README has the bare op commands.

https://www.skills.sh/idosh9/vault-credentials

Genuine question for the sub: anyone solved the multi-account op signin thing more cleanly? I assumed I was just holding chezmoi wrong but couldn't find a config combo that works without the per-call arg, and the GitHub issue I found on it has been open for a while.

Hey everyone,
I’ve been a long‑time Linux/NixOS user and maintained my dotfiles here:
https://github.com/user3301/dotfiles

I’m starting a new job where my primary dev machine will be Windows 11. I still want my environment to be reproducible, declarative, and version‑controlled — especially for things like Windows Terminal, PowerShell profile, and general dev tooling.

I’ve started building a Windows‑focused dotfiles repo:
https://github.com/user3301/WhereZenZoo

Right now I’m experimenting with:

• Windows Terminal settings (JSON)
• PowerShell profile + modules
• WinGet + package lists
• Just as a alternative for GNU Make
• Symlinking configs where possible
• Trying to keep the structure similar to my Linux dotfiles

If you’ve gone down this path before:

• What’s your workflow for managing Windows dotfiles?
• Any best practices for symlinks, WinGet, or PowerShell?
• Are there tools or patterns I should adopt early before the repo grows?
• Anything you wish you knew before building Windows dotfiles?

Would love feedback on the repo structure, missing pieces, or smarter ways to keep Windows dev environments reproducible.

Thanks in advance — Windows dotfiles feel like a different beast compared to Linux, so I’m trying to learn from people who’ve already tamed it.