Good shit
this post was submitted on 16 Oct 2025
102 points (100.0% liked)
Selfhosted
52461 readers
1401 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
This looks very nice.
Um, you know you're supposed to keep dev tools in dev, right? Npm->commit->release payload without npm. Far fewer supply-chain exploits.
Thanks! Hmm, not sure what you mean, that I shouldn't install devDependencies when building the release? That's a good point, I'll need to look into it
Merrier indeed! 😎
This looks good! It doesnt seem that it would fit my use case at the moment but it will be on my radar.
Thx! Out of interest, what is your use case?
I need an easy option to auto sync and backup my elderly parents phone pictures. That also wont propagate deletetions from either side. Im aiming for a failsafe style setup that they cant screw up.
Immich has been working well thus far. Due to the constant updates I have had a few issues to resolve after updates. Backup the backup!
I remember trying it. A very neat idea beautifully implemented. But switched to IMMICH, more features, closer to what I needed.
Keep up the great job! Having alternatives is always a good thing.
I loved photofield!
Hey thanks! The Immich folks are doing an astounding job indeed :)
I love how smooth is photo field, and the way it makes browsing your photos so unique.
I think it's a neat project!
Really didn't like Immich because of its massive install size and being forced to use Docker - this project is exactly what I was looking for. One simple go binary with no extra hoops to get it up and running? Delicious.
Installed, will be following it for sure! Thanks for the excellent software.
What is the install size of immich? 😦
It's the install size of docker and any container it brings down with it.
Really, I just don't like the idea of being forced to use something massive like docker for a single program.
Just give me a binary and let me set up hardening via systemd - or at least a source tarball or something.
Sincerely: someone who thinks software should not primarily be distributed through docker.
I have no counter points, can't argue with that. 👌
Thanks for trying it out! Let me know if you run into any issues or have some ideas :)
Exactly my situation. Thanks @mlunar@lemmy.world. The only way this could be done better was to do it in PHP / have fastcgi so it wouldn't require a constantly running background process specifically for it. People can say a lot of things about PHP, but nothing beats the fastcgi model.
I don't know a lot about fastcgi, but looking it up it seems like it also keeps a persistent process running to avoid execution overhead, but I don't know how that process is managed 🤷♂️
Either way, you could use a supervisor of sorts that shuts down the process/container after some idle time (at least for containers I know some exist) and that should probably work fine (outside of interrupting scanning operations).
I haven't tried it myself yet though :)
don’t know a lot about fastcgi, but looking it up it seems like it also keeps a persistent process running to avoid execution overhead
More of less, the good thing about PHP + fastcgi is that it keeps a configure amount of minimum persistent processes (plus a dynamic number) to avoid execution overhead like you said... now there's an important detail, PHP processes are generic, meaning if you've 50 apps hosted in your server they can all be served with just one persistent process. No need to spin up 50 processes for each app like with node/go etc.
Supervisors shutting down containers/processes are good, but starting up is slow compared to the single PHP idle process ready to go for any app. :)
Thanks for the explanation, makes sense! This app relies quite heavily on in-memory caches, so it's somewhat incompatible with that model :)
That said, I wonder if the startup time would be noticeable. Depends a lot on the configuration, but it shouldn't take more than a few 100ms (esp. if you use skip_collection_counts).
Not really incompatible, PHP provides configurable shared memory across processes that survive even if fastcgi releases every process and just keeps something idle for new requests.
Oh interesting! Thanks for explaining :)