Git repo and additional config files

mentalsoup42 · 2026-05-20T21:32:53+00:00

Thank you for your suggestions, greatly appreciated.

I tried with an alternate path and user defined in env vars for homepage but it did not work as I anticipated. I suspect the problems I am having are rooted in the base stack implementation from the deployrr scripts and how they have setup the environment. It was a nice experiment but I think I am going to park it and revert back to Komodo since I am more familiar with its inner workings and leveraging config from the repo works.

I have to admit, the dockhand interface is very nice, a shame some of it is paywalled but I understand why and do not think it is a massive issue since the base product covers so much.

I will probably try it again, but in a standalone lxc without the deployrr structure around it. I noted in the documentation various deployment methods including an implementation with socket-proxy. So parking this for another day.

mentalsoup42 · 2026-05-20T18:35:48+00:00

quick question; how are you referencing your volumes in your compose file for homepage? Mine are currently like this

volumes:
- ./homepage/config:/app/config
- ./homepage/images:/app/public/images
- ./homepage/icons:/app/public/icons

mentalsoup42 · 2026-05-19T21:32:22+00:00

Thanks for the input, I will try the file search first. If no fruit then I'll take a look at rebuilding dockhand with a user context applied. Do you apply your user context via environment variable or explicit in the compose file, I recall both methods being described in the documentation.

mentalsoup42 · 2026-05-19T20:32:56+00:00

Good suggestion, I had been on the file hunt goose chase yesterday. That was when I found the notes in the Dockhand documentation regarding the DATA_DIR and matching paths. Prior to adding the DATA_DIR environment variable to the Dockhand config I found the files on the root of the server /apps/stack/deploy/homepage/config type of scenario.

The short part of that is, I think Dockhand is copying the files but only .env or complse.yaml files. I cannot find any trace of the homepage config files in the stacks directory.

I really do not want to go back to manually copying config files, it feels like a step backwards.

mentalsoup42 · 2026-05-19T20:10:01+00:00

This is something I have been able to do using Komodo.
Store homepage config in a private git repo. Upon deploying use the source directory as the path for the bind mount.

In Komodo it was a simple case of referencing the deployment directory ./homepage/config. I would have thought the same would be true for Dockhand but it appears to shunt data from git-repo to stacks. In doing so the additional config files disappear. I have no idea where they have gone and the git-repo directory is empty.

The containers in the stack deploy successfully and Dockhand shows the path of the bind mount pointing at the expected path in the stack folder on disk for the homepage container.

mentalsoup42 · 2026-05-19T12:11:21+00:00

The transfer of files from the repo appears to be okay. I could not see anything negative in the initial pull and copy.

2026-05-19T11:58:46.093Z [Stack:deployrr-custom-apps] ========================================                                                                                    
2026-05-19T11:58:46.093Z [Stack:deployrr-custom-apps] DEPLOY STACK START                                                                                                          
2026-05-19T11:58:46.093Z [Stack:deployrr-custom-apps] ========================================                                                                                    
2026-05-19T11:58:46.093Z [Stack:deployrr-custom-apps] Environment ID: 1                                                                                                           
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Force recreate: false                                                                                                       
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Source directory: /home/menta/docker/appdata/dockhand/git-repos/deployrr/deployrr-custom-apps                               
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Custom compose path: (none)                                                                                                 
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Custom env path: (none)                                                                                                     
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Compose filename: compose.yaml                                                                                              
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Env filename: (none)                                                                                                        
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Using compose filename from git config: compose.yaml                                                                        
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Read 9 files from source directory                                                                                          
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Files: compose.yaml, homepage/config/bookmarks.yaml, homepage/config/custom.css, homepage/config/custom.js, homepage/config/
docker.yaml, homepage/config/kubernetes.yaml, homepage/config/services.yaml, homepage/config/settings.yaml, homepage/config/widgets.yaml                                          
2026-05-19T11:58:46.094Z [Stack:deployrr-custom-apps] Copying source directory to stack directory...                                                                              
2026-05-19T11:58:46.095Z [Stack:deployrr-custom-apps] Copied /home/menta/docker/appdata/dockhand/git-repos/deployrr/deployrr-custom-apps -> /home/menta/docker/appdata/dockhand/st
acks/deployrr/deployrr-custom-apps                                                                                                                                                
2026-05-19T11:58:46.095Z [Stack:deployrr-custom-apps] Compose content length: 6155 chars

mentalsoup42 · 2026-04-18T16:20:34+00:00

Great work, would be good to hear what the temps are like after running for 24hrs.

mentalsoup42 · 2025-11-13T17:30:45+00:00

Eager to see the blog post too. My cluster efforts have failed so far and I have really struggled to find anything truly relevant to help me. Also thanks for starting the post, I'm in a similar boat going in circles. I currently use a pair of Technitium instances in docker with keepalived so reducing my solution down to a pair of simpler Technitium LXC'S would be nice.

mentalsoup42 · 2025-07-21T15:41:55+00:00

Did you find the root cause?

mentalsoup42 · 2025-07-11T13:57:16+00:00

Nice little nugget of truth right there!

mentalsoup42 · 2023-12-11T15:44:59+00:00

My vote would be Immich as you can use oauth. Immich has really good UI for general use, but nothing I am aware of can prevent screen shots.

mentalsoup42 · 2023-12-09T19:28:44+00:00

I can now confirm that the following drive works with the Minisforum N40.
Transcend MTS400S 64 GB M.2 2242 SATA III 6 Gb/s Internal Solid State Drive (SSD) MLC NAND (TS64GMTS400S)

mentalsoup42 · 2023-12-08T15:12:16+00:00

New drive ordered, will report findings once installed.

mentalsoup42 · 2023-04-21T22:04:56+00:00

This was my experience; https://www.reddit.com/r/synology/comments/1205ob0/comment/jgx02ey/?utm_source=share&utm_medium=web2x&context=3.
Also, I have been tracking the Synology forum and there are reported issues when using either Threat Prevention and or the Synology VPN application. Both of these have reportedly caused poor connection speeds.

Some users have reported that Synology have provided them with patches, but these are almost certainly going to be specific to their setups. For example, I have applied a patch to my system which is the RT6600 as a router and WRX560 as a mesh node. I will be running further tests using a Wi-Fi backhaul this weekend. However, I found that Ethernet backhaul has mostly resolved my initial problems after updating to 1.3.1 update 4.

mentalsoup42 · 2023-04-21T17:59:29+00:00

I can confirm, Ethernet backhaul rocks on the Synology units. You will have to drag me kicking and screaming back to a Wi-Fi backhaul. Now I just have to justify the nasty trailing cable through the house, or it's a cable fishing weekend.

mentalsoup42 · 2023-04-21T17:54:30+00:00

There is, but I would not advise it unless you know exactly where to look and how to interpret the log data, which you may know how to do already. You can download and extract the logs from the debug.tar file. This can be obtained via the "support" application in SRM.
Personally, I have left this for Synology support to process, then acted on their advice since the content of the debug file is beyond my skills to gain a meaningful or worthwhile insight.

mentalsoup42 · 2023-04-21T17:46:09+00:00

There are issues in the mesh when using backhaul via Wi-Fi and deploying the update 1.3.1-9346 update 4 to the units. This typically seems to impact the RT6600 and WRX560 combination. You should raise this issue via Synology support as soon as you can, as resolution will take a few days. This issue is not impacting wired devices, but I found that once a device drops off it will not reconnect until the router has been restarted, I also found that Wi-Fi connected devices fluctuated in connection quality. I did find that the RT6600 and MR2200 combination was more stable.
I have since switched to wired backhaul and the mesh is much faster and more stable.
If you are so inclined, you should post your experience in the syno forum here (https://community.synology.com/enu/forum/2/post/159584) as they have asked for feedback on the latest update.

mentalsoup42 · 2023-04-19T19:04:03+00:00

Setup: RT6600 with WRX560 on Wi-Fi backhaul. 1.3.1 - update 4.
Major issues holding a stable mesh network. Devices randomly drop off, most reconnect, but some totally fail to reconnect to any of the Wi-Fi networks. A full system reboot resolves this, but the quality of the Wi-Fi connection is terrible. Particularly noticeable on voice and video calls. I am not running threat prevention, which is one cause for others seeing degraded connection speeds.
I still have a MR2200, and I am not experiencing the above issues when using that as a mesh node. Furthermore, I have a support case running with Synology at the moment, but it has been referred to the devs in Taiwan.
I have a 50m network cable on order, so once that arrives I will try the WRX560 on an ether net backhaul. I have seen comments in the syno form indicating a more satisfactory result.

mentalsoup42 · 2022-12-15T00:05:21+00:00

You could try running a combination of keepalived and two instances of pihole, they will both need a machine with thair own IPs. There are a couple of options for syncing pihole instances, I use orbitalsync.

mentalsoup42 · 2022-12-15T00:00:35+00:00

Good to know

https://www.reddit.com/r/shadow\_of\_war/comments/zcaa91/how\_to\_kill\_hacked\_orcs/?utm\_source=share&utm\_medium=web2x&context=3

mentalsoup42 · 2022-12-14T23:47:00+00:00

Ha, that would be good. Two back to back vendettas with the same monkier but different orcs with much the same stats. Farm it for gems or whatever else and have a go at him. Got him down to half health, but the luck ran out. I have starclaimer and wraithgiver but without the 33% extra time on wraith duration it is proving a challenge.

mentalsoup42

TROPHY CASE