I see now, that makes sense why you are building the image since it was set up that way. I don’t know why projects set up the compose file to build the image when they already have a publicly available image to use; it just creates unnecessary friction for people who just want to test out the software. Anyway, using that image should work for you, but feel free to ask if you run into any issues.
Why are you building the image yourself? Not that there’s a problem with that necessarily, but it seems a bit wasteful of your resources unless you have a specific reason to do so. There’s a docker image (quay.io/invidious/invidious:latest) built by the developers that gets updated pretty frequently. I’ve been using it for years now and it’s been working perfectly fine for me the whole time.
If you’re ok with just file storage sftpgo has been solid for me for years now. Does sftp ftp and WebDAV (like nextcloud). Webui isn’t as pretty but it’s fast. Mobile apps will be various sync apps with sftp or WebDAV support. On Android folder sync pro is pretty good for keeping documents and pictures backed up
Well that’s disappointing. I’ll have to investigate further I guess. I was really hoping to set it up (at least initially) without any type of media storage.
Oh I see, I definitely misunderstood what you were asking. How is your caddy server set up? Is it serving one site per subdomain (site.your.domain) or is it one site per path (your.domain/site/)? I am running traefik so I probably won’t be able to help with specifics, but it’s worth a shot.
Correcting the link for non lemmy.world users. !unixporn@lemmy.world
The way I have my monitoring set up is to poll the containers from behind the proxy layer. Ex. if I’m trying to poll Portainer for example:
---
services:
portainer:
...
with the service name portainer
from uptime-kuma within the same docker network it would look like this:
Can confirm this is working correctly to monitor that the service is reachable. This doesn’t however ensure that you can reach it from your computer, because that depends on if your reverse proxy is configured correctly and isn’t down, but that’s what I wanted in my case.
Edit: If you’re wanting to poll the http endpoint you would add it before like http://whatever_service:whatever_port
I believe the Pictrs is a hard dependency and Lemmy just won’t work without it, and there is no way to disable the caching
I’ll have to double check this but I’m almost certain pictrs isn’t a hard dependency. Saw either the author or one of the contributors mention a few days ago that pictrs could be discarded by editing the config.hjson to remove the pictrs block. Was playing around with deploying a test instance a few days ago and found it to be true, at least prior to finalizing the server setup. I didn’t spin up the pictrs container at all, so I know that it will at least start and let me configure the server.
The one thing I’m not sure of however is if any caching data is written to the container layer in lieu of being sent to pictrs, as I didn’t get that far (yet). I haven’t seen any mention that the backend even does local storage, so I’m assuming that no caching is taking place when pictrs is dot being used.
Edit: Clarifications
Thanks for sharing! I’ll definitely be looking into adding this to my infra alerting stack. Should pair well with webhooks using ntfy for notifications. Currently just have bash scripts push to uptime-kuma for disk usage monitoring as a dead man trigger, but this should be better as a first-line method. Not to mention all the other functionalities it has baked in.
Edit: Would also be great if there was an already compiled binary in each release so I can use bare-metal, but the container on ghcr.io is most-likely what I’ll be using anyway. Thanks for not only uploading to docker hub.
I have reservations about running either the agent or portainer itself on something external to my lan.
I don’t feel like it’s safe enough personally either, so I just have portainer edge-agent nodes connected to the primary on my intranet through through vpn tunnels. I really, really would prefer not to ever open ports on my local firewall, but being able to monitor and control remote docker hosts is also pretty convenient, so my solution has been decent for me.
It’s available on 1.19.3. Using it with my Gitea instance currently. Behind a flag in the config.ini I believe. Not at all stable yet, and not feature complete compared with Github Actions, but I’ve done a bit of testing with it and it’s been pretty smooth sailing.
Man, I wish I could find a good colo solution that wouldn’t kill me with fees. VPS isn’t bad cost-wise, but I’d really like to be able to throw as much hardware as I want at it without paying $1k/mo.
Great to know. Thanks! I’m looking into them now.
Sure thing. But it seems my position on iOS client support is out of date. poVoq said that there’s a couple decent options for XMPP clients now for iOS.
Oh that’s good to hear. I’ll most likely look into it again then, since client support was what was really holding me back. Do you have an XMPP server deployed? If so, what did you end up going with?
IIRC they’re just different protocols. Snickett is XMPP, while something like Synapse is Matrix. XMPP is older than Matrix as a protocol, and from what I’ve heard is it’s far lighter on resources than Matrix, at least Synapse. Looked into XMPP when I was researching how I was going to set up my private messaging and it seemed nice, but lack of good iOS clients at the time made it a non-starter as my family and friends are mixed between iOS and Android. Don’t know if the client situation has changed however.
Nice! Thanks for the release update!
Looks like scrot pngs from here
Holy crap that’s awesome! I’d be lucky to get 1 minute out of my trash Cyberpower UPS once the power goes out. Thanks for the informative post OP! And for the inspiration!
Can you help me fill in the blanks on your waybar layout? from what I can tell (left to right):