Feature Request: Suggestions for Custom Setup Persistence

[lorecov]

I'd like to suggest a few feature ideas inspired by HATSKitPro to help custom setups survive clean updates directly on Switch.

Split Component Manager & Auto-Restore

• Divide Component Manager into "Pre-installed" (HATS pack standard) and "User-installed" (custom).
• On clean/destructive updates (Replace Atmosphere+Bootloader+Switch), remember the "User-installed" list and auto-redownload/restore them afterward.

Smart Conflict Resolution

• If a "User-installed" component conflicts with a "Pre-installed" HATS component, don't delete files.
• Show a popup with options like: "Disable HATS component" (preferred) or "Disable User component".
• Advanced Option toggle: Option to automate conflict handling (e.g., default to "Disable HATS component" to preserve user setups).

Hekate Config & Boot Entries Persistence

• hekate_ipl.ini Editor: An in-app menu to edit and preserve custom configurations across /bootloader updates.
• bootloader/ini/ Protection: Automatically backup and restore this folder during updates so Linux, Android, or TKMM boot entries aren't lost.

Btw, thank you for this amazing tool! I don't know how to code, so I can't provide a Pull request, but I wanted to share these ideas in case you find them useful. Absolutely no pressure to implement any of this—thanks again for all your hard work for the community!

[sthetix]

Thanks for the suggestions, but I think there is a misunderstanding about the purpose of HATS. HATS is not intended to be a universal component manager. It is a curated pack that I maintain and publish with a specific set of components and configurations. HATSKitPro and its preset system exist primarily to make that curation, building, and updating process manageable and reproducible. A clean update intentionally restores the selected curated setup. Automatically restoring third-party components, preserving arbitrary modifications, or disabling official HATS components during conflicts would create a mixed configuration that I did not curate or verify. That would also make compatibility issues much harder to diagnose and support. Users are absolutely free to customize the pack, edit the available definitions/code, and create their own presets. However, once they depart from the curated HATS configuration, maintaining those customizations across clean updates is their own responsibility. So while the ideas may be useful for a universal package manager, they are outside the intended scope of HATSKitPro.

…

On Sat, 22 Aug 2026 at 00:47, 2020loryx ***@***.***> wrote: *2020loryx* created an issue (sthetix/HATS-Tools#26) <#26> I'd like to suggest a few feature ideas inspired by HATSKitPro to help custom setups survive clean updates directly on Switch. *Split Component Manager & Auto-Restore* - Divide Component Manager into "Pre-installed" (HATS pack standard) and "User-installed" (custom). - On clean/destructive updates (replace_ams_bl / clean), remember the "User-installed" list and auto-redownload/restore them afterward. *Smart Conflict Resolution* - If a "User-installed" component conflicts with a "Pre-installed" HATS component, don't delete files. - Show a popup with options like: "Disable HATS component" (preferred) or "Disable User component". - Advanced Option toggle: Option to automate conflict handling (e.g., default to "Disable HATS component" to preserve user setups). *Hekate Config & Boot Entries Persistence* - hekate_ipl.ini Editor: An in-app menu to edit and preserve custom configurations across /bootloader updates. - bootloader/ini/ Protection: Automatically backup and restore this folder during updates so Linux, Android, or TKMM boot entries aren't lost. Btw, thank you for this amazing tool! I don't know how to code, so I can't provide a Pull request, but I wanted to share these ideas in case you find them useful. Absolutely no pressure to implement any of this—thanks again for all your hard work for the community! — Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AFJ23DZYZ2MO3GPNR3I2PSL5LCDJJA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NJSGE3DOMJZGUZDNJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJ23D7LEP4YLYZHPFTXDB35LCDJJAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMRSGAZTENRZHE5US43TOVSTWNJSGE3DOMJZGUZDNILWAI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lorecov]

Thanks for explaining your vision—that totally makes sense! I completely understand that keeping HATS as a verified, curated pack makes support and troubleshooting much easier.

Just out of curiosity, since setting things up via PC after every update is a bit tedious for those of us using extra boot entries (like Android/Linux) or custom tools (i have a lot of custom tools), do you think a basic protection for specific folders and files (like /bootloader/ini/) could ever fit the scope? Or would you recommend using a different tool alongside HATS-Tools for custom files?

[sthetix]

I checked the HATSKitPro installer behavior. It only removes the /atmosphere/ and /sept/ directories during a clean installation. It does not delete /bootloader/. The new pack is then extracted over the existing SD contents. Files with matching paths are overwritten, while unrelated existing files remain untouched. Therefore, custom Android or Linux entries inside /bootloader/ini/ will remain available under Hekate’s *More Configs*, provided they use their own filenames. There is no need for a separate protection or restore feature for that folder. You should not need to recreate those boot entries after each HATS update.

…

On Sat, 22 Aug 2026 at 17:11, 2020loryx ***@***.***> wrote: *2020loryx* left a comment (sthetix/HATS-Tools#26) <#26 (comment)> Thanks for explaining your vision—that totally makes sense! I completely understand that keeping HATS as a verified, curated pack makes support and troubleshooting much easier. Just out of curiosity, since setting things up via PC after every update is a bit tedious for those of us using extra boot entries (like Android/Linux) or custom tools (i have a lot of custom tools), do you think a basic protection for specific folders and files (like /bootloader/ini/) could ever fit the scope? Or would you recommend using a different tool alongside HATS-Tools for custom files? — Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AFJ23D47XJPDSJPBXXX53G35LFWUBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZXHE3TANBRHE32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5379704197>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJ23D5USFUEMRFTJZJEOQT5LFWUBAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMRSGAZTENRZHE5US43TOVSTWNJSGE3DOMJZGUZDNILWAI> . You are receiving this because you commented.Message ID: ***@***.***>

[lorecov]

I think there was a small misunderstanding: I was referring to HATS-Tools (on the Switch), not the HATSKitPro on PC. I only brought up HATSKitPro as a reference for handling individual modules.
My end goal is to manage everything directly from the console without needing a PC. To clarify what I had in mind:

Config & Entry Protection: A feature to automatically back up and restore the /bootloader/ini/ folder AND hekate_ipl.ini Even if configs are manually edited on a PC once, users shouldn't lose custom boot entries (like Android/Linux) or custom Hekate settings after doing a clean HATS update via the console.

Custom Folder Preservation: An option to preserve specific user folders across updates, such as custom Atmosphere mod directories (/atmosphere/contents/ or /atmosphere/exefs_patches/), so personal setups aren't lost.

User Modules vs. Default Modules: I don't want to modularize the core HATS pack itself. The idea is to separate Default Pack Modules from User-Added Modules:

• Default Modules: Cleaned up and updated automatically according to your official releases (if you remove an outdated tool from the pack, HATS-Tools will remove it on the Switch too).
• User Modules: Standalone apps/tools added by the user that persist across pack updates and get updated automatically via HATS-Tools, without being wiped during a clean install.

Automatic Conflict Resolution: Handling overlapping files seamlessly if a user module conflicts with a HATS default component.

​I explicitly want to use the full clean installation option (completely wiping /atmosphere/, /bootloader/, and /switch/ to prevent leftover issues), which is precisely why having these backup/restore layers for user configs, mods, and custom modules directly on the console is essential to avoid relying on a PC after every update.

[sthetix]

Thanks for explaining the workflow in more detail. Your idea makes sense in principle, but I think the main issue is that the existing installation modes may not have been fully understood.

For your Android/Linux setup, Switchroot stores its Hekate entry as a separate file under /bootloader/ini/—for example, android.ini—while its main files are stored under /switchroot/.

If you want a fresh Atmosphere installation while keeping your Android/Linux entries, the appropriate option is replace_ams, not clean. This mode deletes and replaces /atmosphere, but does not delete /bootloader, /switch, or /switchroot. Your Android/Linux boot entries therefore remain intact.

The modes are intended for different purposes:

• overwrite: Update HATS while preserving existing custom files.
• replace_ams: Clean Atmosphere while preserving bootloader entries and homebrew.
• replace_ams_bl: Clean Atmosphere and bootloader.
• clean: Remove and replace Atmosphere, bootloader, and Switch with the curated HATS pack.

HATS-Tools also recursively backs up the complete /atmosphere and /bootloader directories before installation when automatic backup is enabled. This already includes hekate_ipl.ini, /bootloader/ini/, custom contents, and patches.

The important distinction is that clean is intentionally destructive. Its purpose is to return those directories to the exact HATS configuration generated by HATSKitPro and tested as part of the release. Automatically restoring external configs, mods, patches, or modules afterward would reintroduce files outside that tested configuration and could also restore the conflicts or outdated files that clean mode is intended to remove.

The default-versus-user module idea is useful conceptually, but arbitrary user-installed modules do not have the HATSKitPro-generated manifest metadata needed to identify their files, versions, ownership, and update sources. Without that metadata, HATS-Tools cannot safely update, uninstall, or resolve conflicts between them.

So the idea itself is understandable, but for the Android/Linux use case you described, the existing replace_ams mode already provides the intended result. Use clean only when you explicitly want the complete curated HATS state and accept that custom files inside those directories will be removed.

bersihin > nya bro

[lorecov]

I completely understand your reasoning regarding the clean mode and the technical limitations (like the lack of module manifests to safely track/resolve conflicts without breaking the tested HATS state).

My main goal was just to find a way to maintain a completely wiped/fresh system without orphan files while avoiding the PC altogether, as I have quite a few custom modules that I prefer applying directly on top of a fresh, clean HATS base. But I see how trying to selectively restore custom files after a true clean install goes against the design purpose of that mode.

Out of curiosity, given that goal, is there any workflow or tool you’d recommend for managing custom overlay modules directly on the Switch after a clean update, without needing a PC?

[sthetix]

I understand your goal now. Technically, something like a partial snapshot could work: before updating, HATS-Tools could ask which custom folders to preserve and then restore them after the clean installation. The problem is that you would still need to know exactly which files belong to each custom module. Preserving every unknown file could also restore the orphan files you are trying to remove. For now, the most practical PC-free workflow is to keep a separate personal overlay containing only your known custom modules in a folder unaffected by clean mode, then copy it back using an on-console file manager after the update. Creating and maintaining that overlay would remain manual. I’m not aware of a universal on-console tool that can reliably identify, update, and restore arbitrary modules without their own manifests. A partial-snapshot feature is possible, but handling path selection, conflicts, compatibility, and failed restores would add considerable complexity.

…

On Sun, 23 Aug 2026 at 06:09, lorecov ***@***.***> wrote: *lorecov* left a comment (sthetix/HATS-Tools#26) <#26 (comment)> I completely understand your reasoning regarding the clean mode and the technical limitations (like the lack of module manifests to safely track/resolve conflicts without breaking the tested HATS state). My main goal was just to find a way to maintain a completely wiped/fresh system without orphan files while avoiding the PC altogether, as I have quite a few custom modules that I prefer applying directly on top of a fresh, clean HATS base. But I see how trying to selectively restore custom files after a true clean install goes against the design purpose of that mode. Out of curiosity, given that goal, is there any workflow or tool you’d recommend for managing custom overlay modules directly on the Switch after a clean update, without needing a PC? — Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AFJ23D7U5E724Q5P6C4GPR35LIR33A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYGMYDQMZRG4Z2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5383083173>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJ23D4UQHZ2YKLWQ3BHK3L5LIR33AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMRSGAZTENRZHE5US43TOVSTWNJSGE3DOMJZGUZDNILWAI> . You are receiving this because you commented.Message ID: ***@***.***>

[lorecov]

I understand the complexities regarding path selection, conflict handling, and failed restores.

That PC-free manual workflow you suggested (using an unaffected folder and copying it back via an on-console file manager) actually sounds like a great practical workaround for now.

Since this is a feature I'd really love to have, I might eventually try to experiment with this idea myself on a fork of both HATS-Tools and HATS-Installer-Payload. I’m only 16, still pretty new to Switch development, and quite busy with school and life, so no promises on when or if I’ll pull it off! But if I manage to build a working prototype, I’ll definitely open a Pull Request so you can check it out if you’re interested

[lorecov]

While setting up my fork to start experimenting, I ran into a strange issue with compiling the project via GitHub Actions.

When I build HATS-Tools from source using the latest devkitPro Docker container (devkitpro/devkita64:latest), the build initially fails on gc_menu.cpp due to changes in recent libnx updates regarding svcGetDebugEvent and DebugEventInfo.

I patched that up to get it to compile, but the resulting .nro is very unstable on the console: at startup, it frequently crashes or renders a blank UI without text and backgrounds. Interestingly, enabling RAM/CPU overclock helps the build launch more consistently, but on stock settings, it almost never boots properly.

On the other hand, your official release ZIP works 100% reliably on my Switch under any condition.

I have attached the .github/workflows/build.yml file I'm currently using for reference.

build_preset.yml

Could you share how your build environment/pipeline is set up, or what devkitPro toolchain version you use to build the releases? I'd love to adapt it to a working workflow so I can test my changes cleanly. Thanks a lot for your guidance!

[sthetix]

please use the dec 2025 devkitpro image version to compile the hats tools or sphaira..

…

On Tue, Aug 25, 2026, 23:10 lorecov ***@***.***> wrote: *lorecov* left a comment (sthetix/HATS-Tools#26) <#26 (comment)> While setting up my fork to start experimenting, I ran into a strange issue with compiling the project via GitHub Actions. When I build HATS-Tools from source using the latest devkitPro Docker container (devkitpro/devkita64:latest), the build initially fails on gc_menu.cpp due to changes in recent libnx updates regarding svcGetDebugEvent and DebugEventInfo. I patched that up to get it to compile, but the resulting .nro is very unstable on the console: at startup, it frequently crashes or renders a blank UI without text and backgrounds. Interestingly, enabling RAM/CPU overclock helps the build launch more consistently, but on stock settings, it almost never boots properly. On the other hand, your official release ZIP works 100% reliably on my Switch under any condition. I have attached the .github/workflows/build.yml file I'm currently using for reference. build_preset.yml <https://github.com/user-attachments/files/31427882/build_preset.yml> Could you share how your build environment/pipeline is set up, or what devkitPro toolchain version you use to build the releases? I'd love to adapt it to a working workflow so I can test my changes cleanly. Thanks a lot for your guidance! — Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AFJ23D2UNQF5G4I632FUSLD5LW263A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBRGMZDMNJQGMZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5413265032>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFJ23D4TEA4MM7YBULBJTDT5LW263AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMRSGAZTENRZHE5US43TOVSTWNJSGE3DOMJZGUZDNILWAI> . You are receiving this because you commented.Message ID: ***@***.***>