Support custom config paths and automatic backup management

[pirate-boop]

It would be great to support custom or dynamic config paths instead of only using the default "~/.config/niri/config.kdl".

This would help users who:

• use Home Manager / NixOS
• store configs inside dotfiles repositories
• use symlinks
• maintain multiple Niri profiles/configs

For example, some users may store their config in locations like:
"~/nixos/.dotfiles/home/.config/niri/config.kdl"

A configurable path option or file picker would make Nirimod much more flexible for these setups.

It could also be very useful to add automatic backup support before saving changes.

Suggested behavior:

• create a backup before every save
• store backups in the same directory as the selected config
• support numbered or timestamp-based backups
• optionally allow setting a backup limit

Example backup names:

• "config.kdl.1.bak"
• "config.kdl.2.bak"
• "config.kdl.3.bak"

or timestamp-based naming
Example timestamp format:
"config.kdl.16-05-2026_18-42-11.bak"

(day-month-year_hour-minute-second)

If a backup limit is configured (for example 10 backups), the oldest backup could be automatically removed when the limit is exceeded.

If no limit is set, backups could remain unlimited.

It would also be great to expose backup restore functionality directly inside the Nirimod UI, so users can easily rollback broken configs after experimenting with layouts or settings.

This would make Nirimod much safer and more convenient for advanced setups and configuration-heavy workflows.

[srinivasr]

@pirate-boop great idea , working on implementing this.
what would you prefer the backups being stored in ~/.config/nirimod/ or ~/.config/niri/

[pirate-boop]

It would be great if there was an option to choose

[pirate-boop]

~/.config/nirimod/

[pirate-boop]

I also wanted to clarify and expand the Git integration idea a bit more because I think it could become one of Nirimod’s most powerful features for NixOS/Home Manager users.

The important part is that Nirimod would still keep its own normal local backup directory, something like:
"/.config/nirimod/backups/NiriMod (Gen 12) — 2026-05-24 19:42" example
and active work config directory:
"/.config/niri/config.kdl"

This is perfect for regular FHS distributions and local rollback support.

But for Git/dotfiles users, it could additionally support repository-aware remote backups.

Example setup:

• User connects GitHub account / Git provider
• Adds Personal Access Token
• Selects:
  • backup directory path inside repository
  • config path inside repository

Example:

• Backup path:
  "repo/dotfiles/.config/nirimod/backups/"
• Active config path:
  "repo/dotfiles/.config/niri/config.kdl"

Then the workflow becomes:

1. User edits config in Nirimod
2. Presses "Apply Remote"
3. Nirimod:
   • saves current config as backup
   • pushes backup to repository backup path
   • pushes new edited config to actual config path
4. Small Git/GitHub confirmation window appears
5. User confirms merge/push or cancels operation
6. Afterwards user simply runs Home Manager/NixOS rebuild normally

Rollback support could also become extremely nice here.

Instead of plain unnamed backups, Nirimod could display them similarly to NixOS generations:

• generation number
• date
• time
• optional commit message

Something like:

• NiriMod (Gen 12) — 2026-05-24 19:42
• NiriMod (Gen11) — 2026-05-23 02:15

Then rollback could restore:

• local config
• repository config
• previous remote backup state

This would make experimenting with layouts/configuration much safer while fitting perfectly into declarative Linux workflows.

At that point Nirimod would feel less like “just a GUI editor” and more like a proper declarative configuration frontend with built-in history and Git-aware state management.

[srinivasr]

@srinivasr check it out i just added the custom config/backup paths and backup generations features,
you can change these things in the menu