This is a similar use case I had in mind when implementing the possibility of monitoring multiple Syncthing instances at once in Syncthing Tray. I have never really followed up on that because for me personally it didn’t seem that useful after all. But interesting to see that someone tries to fill that gap. I guess a web app like this is indeed the better fit for this use case anyway. It is nice that it also shows pending devices and folders.
Because you mentioned it on the README: It would still be nice if the UI was a bit more polished and more in-line with the official Syncthing UI. A little bit of CSS would already make a huge difference - you don’t need any fancy frameworks that will impact the loading time.
I had been looking for this kind of setup for a while, and finally settled with a custom api someone posted on r/selfhosted a few months ago for Homepage. I’ll still deploy this one on my RPi.
This is really cool. Certainly beats opening chrome with multiple tabs.
This is my second time using docker and still getting to grips with how things work - but one thing I noticed: I want to run this on one of the machines running Syncthing and couldn’t connect to itself (others were fine) until I put in extra line “network_mode:host” — I suppose this is by design of docker right and not something can make an option in your app?
I’m guessing you used 127.0.0.1 as the ip for the syncthing instance on the same machine.
Important thing to remember is that if you use that ip for anything running in a docker container. It will be interpreted as the container itself. Which in your case (and most cases) is not what you want.
There are 2 options for this situation. (which won’t require network_mode:host)
if you are running syncthing in a docker container as well (and they are both in the same network) you should be able to use the container name in place of its ip. which could mean the environment variable for this could look like : - DEV_URL_1=<syncthing_container_name>:8384
if you are not using docker for your syncthing install you should be able to use the lan ip address of that machine this is usually the one that looks like either one of these (10.0.0.* or 192.168..)
if these don’t work it might be interesting to check what the value is off the gui listening address in the syncthing settings (settings → gui → gui listen adress) I would suggest to change it to 0.0.0.0:8384 (which will make the api respond to wherever the request is made from, so definitely make sure you have set a password for your gui)
You could of course keep using the network_mode:host fix you used. But my personal recommendation would be to only use that as a last resort.
If these don’t work or anything is still unclear feel free to ask.
Also sorry for taking so long to respond, Seems like my notifications are not setup correctly on my end.
Hi - thanks for the long and considered response. I am happy with the network host approach as it solves my issue with minimal fuss - but for others having prorblems:
It could be because I am using tailscale for all my IP setups (I have a mix of machines at homelab and some in cloud services). Otherwise my setup mirrors what you mentioned:
Syncthing running as service on host
WebUI listening on 0.0.0.0
SM2 pointed host using host tailscale IP (ie something in range 100.64.0.0/10)
SM2 happily can see all the other syncthing instances (Which are also on TS IPs) but can’t connect to syncthing instance on host itself.
Anyway - for your consideration only as the network_mode host does work and already appreciate your wonderful work.
I’m very interested in putting this to use, but even though I consider myself an advanced user/admin, I’m missing the obvious steps in creating the server and getting it running.
Would you mind adding a couple of lines in the GitHub repository that would point me in the right direction?
I definitely want to help with that.
But you’ll have to help me help you.
Could you add some more detail with what is unclear/ needs better explanation.
I added what I always look for on a github page when finding a new project. And that are the compose examples that can be found here.
But this might be a case of “developer thinks it easy because they made it and lived it, but end-users don’t understand because they are seeing it for the first time”
It appears that this is built to run in Docker, something that is not obvious to someone used to running scripts, web-apps, or native apps like Syncthing. There were several clues there that I caught onto, and sure enough I found it in Docker.
Second, I assume that the interface is intended to be presented to a web-browser, but I don’t find this information easily.
I guess I would start with answering the question, what is the intended target – a personal desktop where the presentation is on localhost, a local network webserver, or public internet?
For me personally, the ideal would be to run this on a VPS where I can pull up a status page from anywhere in the world. That may present some issues with a few of my devices that are behind firewalls.
Running on my personal desktop would be second-best, but should give me a view of any connected Syncthing instance (even the remote devices).
However, running a simple Docker instance on Windows is “not simple” and takes up an enormous amount of resources. (As an aside, the experience of trying to “just” run a simple Docker wrapper on Windows has pretty much soured me on ever trying to do anything with Docker in the future! What a hog – but that applies to Windows too!)
I tried to set this up on a VPS with Docker and failed there as well. Ideally, I would prefer to be able to run this without the overhead of Docker, but I understand that there are advantages for the developer in doing so.
Yes, the project is made to be run in docker. In my opinion from professional and homelab experience. I see almost no reason to not use docker for anything homelab related. (Won’t be expanding much on that as then we would go off topic)
Sm2 should be deployable without docker but not supported by me.
The interface is indeed intended to be in a browser. And I 100% agree that that is unclear in the readme.
I wrote the readme based on what I look for in the readme off a project. some screenshots and a docker-compose example.
I will add it to my todo for expanding the readme to clarify this.
What is the intended target (aka deployment target)?
I made this project for my own use (I was looking for something like this and could not find it so I made it myself).
The project is intended to run a server, Mine runs at my home and I have s2s vpn’s to the other locations I need to access. I would definitely not recommend to expose this to the public internet. sm2 nor your syncthing gui.
But if you are using windows on your personal pc then yes. Windows and docker are known to not be very lets call it “collaborative” (I’m also speaking from past exp)
The install on your vps with docker should have been pretty smooth. I’m interested to hear what issues you came across.
I would also like to add that there is almost no (if any) overhead with running docker.
I can strongly recommend that you give docker another try. Not just for sm2 but just in general. just don’t use windows.
And if you are looking for something to mess around on and just try I would suggest getting a raspberry pi, or dusting off that old laptop/desktop you might have laying around.
And it is true that docker is marketed as perfect tool for developers. But I can tell you. (professional exp off teaching others) that some developers struggle with docker themselves.
And you might not believe my opinion around docker (Fair enough I’m just a random dude on the internet (with professional exp (but I can claim whatever I want ofc )))
but these are the survey results by selfh.st from 2024 (check the “containers” section)
I hope this clarified some things.
If you have other questions just let me know.
And if you have docker specific questions just send me a DM so we can keep it on topic here.
