Itās ok, my bad at first for not understanding the specifics and not taking the time to actually see what you are saying. Yes, I change the custom icons myself, thanks for posting and hopefully it exists in Truenas soon. I just wanted to give you a non change Truenas option that is native docker.
Whatās weird is it does work to me, but, itās a semi well known docker workaround that has worked for many many years as docker has never responded to the github issue for your requirement (from someone else). I believe they suggested it originally.
So Iām kind of a dummy when it comes to Docker, specifically when it comes to Dockerfiles, as Iāve never had occasion to use them before. So I create $SOMEDIR, and in that create Dockerfile mostly as above (though with Cloudflare because Iām using that), compose.yaml mostly as above, and .env containing my admin email and API credentials.
Then create a custom app containing:
include:
- $SOMEDIR/compose.yaml
Straightforward enoughābut where does the custom Caddy image get built? It has to, right, to include those two plugins? Or does the (effective) docker compose up -d build that as part of the process?
Edit: Well, nothing like just giving it a try. And the answer is, yes, docker compose up does build the Dockerfile. It works, Homepage proxies behind it with just two labels (vs. five with Traefik), and of course Caddyās configuration is considerably simpler than is Traefikās. Now a bit of conversion to do on my apps. And work out how to expose Caddyās API to Homepageā¦
I am new to TrueNAS and I am undecided between dockg and this custom app/include approach.
What I really would like is to keep the dependencies/additional tools to a minimum, so this is a plus of this approach, although realistically, I would need studio code server or similar to edit.
What i am wondering about this approach:
My understanding is that I can export a TrueNas Settings file, load that into another server and everything will be restored from there (except for the Data).
If I go for this approach and restore, would the custom docker files be part of the TrueNAS Settings file? Probably not, right?
But apart from that: What is the benefit of this approach vs. dockge?
Didnāt use dockge, so canāt say for sure. But if I were serious about running docker containers on truenas, I would deploy portainer-agent to truenas and then would manage containers from the portainer on a separate machine. Thus, truenas would store only data volumes and images.
Right now I run only 1 container on truenas, so I decided to not go the portainer-agent way. Canāt say that suggested approach is the best; I am just experienced with/used to portainer.
I confirm all of this as well. I setup my apps in TrueNAS this way last night.
I like having all of my containers setup with compose so that I can use git to backup the compose.yaml, any .env files, and any other config files. It helps me track what changes Iāve made to a stack in time. Itās come in handy more times than I can count to see āupdated config due to v1.2.3 breaking changeā. Or else I might fix the same thing multiple times.
It seems you canāt control the stack via CLI once itās added in the GUI. When I ran ādocker compose psā in the stack directory, no containers were listed.
Just an FYI if your intention was to gain some visibility in the GUI but continue managing via CLI. I could also be wrong - I only noticed this when I went to down the test stack I had added using the includes option and did not test thoroughly.
If you want to use the docker compose command to aid you in some tasks:
First check list of projects with docker compose ls. It will print out a table of NAME, STATUS, CONFIG FILES. The names are in format of ix-<HowYouNamedYourAppInUI>
Now run a command like docker compose -p ix-minio ps
Tada . Very neat. You can use it for some things if you canāt be bothered to do them in the UI or factually canāt do them there, and itās cleaner than messing up with the containers individually. As for why you canāt instead enter the workdir of Compose project like usually with stacks or use the -f option to specify the runtime path of Compose file: donāt ask me.
But actually some rare things might want -f to the Compose file and you can also run docker compose pull in the directory without any further options, which also doubles as a way to validate your Compose file contents.
But the reason Iām coming back to this thread is to report that TrueNAS 25.10 partially breaks this now:
In case anyone wanted to know how to add a button that links to the application (and/or add some notes to this application in TrueNAS):
If you install a new yaml using this Custom Config, you can add the following snippet and customize to your needs to show a button to your application. This only appears to work at the time of creating the app. Adding OR changing the extra stuff after the fact did not add, or change, the button or Notes. Youāll have to recreate the application if you made a mistake.
include: - path: /mnt/<path/to/compose.yaml services: {} x-notes: | # VS Code Server or whatever Add as many lines of text as you want, but do mind the indentation x-portals: - host: 0.0.0.0 # replace this with FQDN or dedicated IP address if you like name: Web UI # text on the button path: / port: 8880 # change to whatever port the service is listening on scheme: http # change to https if the app uses HTTPS