Is there a way to download the settings for an app in a file and use that file to later upload the same settings for the same app on a different instance of TrueNAS SCALE (avoiding manually entering the app settings twice or more times)?
1 Like
Thatās a feature thatās been requested since the first apps came out, but no, currently its not possible to save the apps settings.
That feature is under current development 
5 Likes
Awesome!
Has the feature (download and upload appsā configurations) been released yet?
1 Like
No.
The closest they did was let you convert an app to a YAML-app, that gives you an easy way to save the configuration. But itās one-way, once itās converted to YAML it stays YAML.
Having said that, all my apps are custom YAML and work just fine, I keep all my configurations saved elsewhere and just paste changes into TrueNAS if need be.
I am not sure if it helps in this situation, but I might have something that helps to ease the pain 
I am not a fan of ClickOps, and I donāt like that compose projects deployed through the api are not visible in the UI, so I created a wrapper script that uses the midcltcommand to interact with the TrueNAS Scale API to manage custom apps. You can find it on Github in meyayl/truenas-scale-custom-app-control (I am not allowed to post links as a new user).
1 Like
Seems my second post allows sharing a link: https://github.com/meyayl/truenas-scale-custom-app-control.
1 Like
Thanks for the script, but I needed a tool to inspect the installed catalog apps and not the custom apps configured with yaml files.
The script worked fine to get a JSON output for my custom app but not the catalog apps.
It was a design choice to restrict it to custom apps.
It could be easily modified to not restrict output to custom apps. Just remove [ācustom_appā,ā=ā,true]in line 34, 118 and 128.
The api has a method to get the configuration of an app. For custom apps, it only returns the compose yaml definition. I am not sure what it shows for non-custom apps.
I update the script. Now every command except list is not restricted to custom apps.
The list commands shows custom apps only by default. Adding the āall argument will show apps installed from the catalog as well.
The inspect and config commands can work with catalog and custom apps. By default, the output is json, which can be turned to yaml by using the āyaml argument.
If I figure out how the output of config can be used to create an instance of a catalog app, Iād be happy to implement it.
Thanks a lot!
Using the config command/argument I got all the details from the installed catalog applicationās configuration I needed in the JSON output.
I put some of my apps containers on a dataset āapps_configsā and point to it from a custom config I make from the Truenas apps discover ā Install by yaml. This way the app still gets to be seen in the Truenas apps tab, can be start/stopped/restart from there and notes accessed directly from their, and they can be easily backed up and restored using tools available in Truenas. Since the files are all accessible they should be able to be put on a different Truenas server or on a different machine.
The compose files, and any other files the app needs are where I can control them, see them, edit them, and not hidden or partially hidden. I use watchtower to update the apps. I did not mapp the dataset to SMB or anything, but I use code server in a container to edit and Portainer can slao access the containers
The custom config I make just has an include and the path to where the app resides which nice. Starting with TrueNAS 25.10, you will need to add a services key to your custom yaml for new stacks and when updating your existing stacks. Everything else is the same.
This was explained in a forum thread and also outlined in a youtube video that puts together what the forum thread discussed. There may be a similar way now of doing the same in a more recent version of Truenas CE, but the method works well.
It was always required by the Compose Specification. Seems TrueNAS 25.10 (or the embedded docker-ce version) started to validate against the specs.
The approach you describe leverages the include top-level property. Even though, It still requires clickOps actions in the ui, It is much better than having to copy/paste compose file content into the ui.
Interesting approach. I might try it out in the future.