include:
- path: /mnt/tank/Data/Compose/Ubuntu/compose.yml
env_file:
- /mnt/tank/Data/Compose/.env.global
- /mnt/tank/Data/Compose/Ubuntu/.env
Indeed, this seems to work for variable for the compose interpreter and variables for inside the container.
Sorry for the back and forth.
Here is an explanation how to add your own app icon. How to change icon of custom app? - #25 by adelzu
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ā¦
7 posts were split to a new topic: Dockerfile, Caddy, and qBittorrent, oh my!
I found this through Techno Timās recent video. Just wanted to drop some appreciation. Iāll be trying this out soon.
Two Questions:
Does this work when there are multiple containers within a single Compose file?
Can I use this for existing compose stacks that were created via CLI?
Thanks.
Didnāt try it myself, but see no reason why it wouldnāt.
Perhaps you would need to migrate the content of your volumes. Did you really run your compose from the console?
Hello,
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?
Greetings,
Hendrik
Iām almost sure it wonāt be backed up.
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.
Yes. I have tested this myself.
Yes. Just point the include to that docker compose file. It may need a one of the above fixes if you use a .env file.
Thanks. Just tested this and here are my observations.
I wrongly assumed it would show each individual container as the app instead of the stack, but the way it works makes total sense and it does work.
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. 
One other thing I noticed.
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.
I wrote this at some point:
If you want to use the
docker composecommand to aid you in some tasks:
- First check list of projects with
docker compose ls. It will print out a table ofNAME,STATUS,CONFIG FILES. The names are in format ofix-<HowYouNamedYourAppInUI>- Now run a command like
docker compose -p ix-minio psTada
. 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
-foption 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:
The workaround is to prepend services: {} at the top above your include:
EDIT: Bug has been filed: Jira
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
Since this topic is kind of Caddy centralā¦ This topic (Shortlived certificates (from Let's Encrypt) - General - Caddy Community) in the Caddy forum describes how to use the shortlived certificates from Letās Encrypt, if desired. To do this using labels in the Compose file, set the following caddy_2 labels:
- caddy_2="*.lan.example.com"
- caddy_2.tls.issuer=acme
- caddy_2.tls.issuer.profile=shortlived
- caddy_2.root="* /usr/share/caddy"
- caddy_2.file_server
The second and third lines are whatās new.
Hi everyone, has anyone found a solution for git synchronization with TrueNAS applications?
I recently switched from a simple Debian Docker setup with Portainer to TrueNAS, and Iām looking to replicate my workflow. Ideally, Iād like to use a single Git repository with periodic git fetch updates alongside my Renovate bot for automated versioning, this could potentially eliminate my need for Portainer altogether.
Does anyone have experience with this approach? What would be the best and cleanest way to manage a Docker stack on TrueNAS currently?
Just use portainer. Not sure whether itās the best (it is, though), but it should work on truenas.
Whatās wrong with portainer? Did it become a whipping boy just like windows?
Hi, thanks for the answer! Nothing wrong with Portainer per se, but I have a few specific pain points that pushed me to look for alternatives:
So itās less āPortainer is badā and more āTrueNAS has its own container management story now, and Iād rather work with one coherent system than bolt two together.ā
Mainly, Iād love both to cohexist as Portainer does container management right while TrueNAS is a NAS with some added docker features.
But Iād definitely rather have the stack start-up using a local compose file for faster docker-compose changes and iterations when wanting to try things out before rolling it to production.
Hope it clarifies !
How does it differ from portainer without a git setup?
I wouldnāt be so sure. Truenas changes the appās storage layout from time to time. Also, by default, it stores the data in UI-hidden datasets, which makes versioning and/or managing snapshots not so transparent. Moreover, you canāt even create a periodic snapshot task (at least not in the UI) for these datasets.
Truenas apps management is far from perfect, and IMO it would be a forever-catching-up solution. Because other solutions target the whole docker user market, while truenas targets just the truenas user market. And as a cherry on top, truenas enterprise customers donāt need apps, soooā¦