You forget about that UI. Only used to create users. Then use. Cardiac/cal app like Dav5X on Android or similar to connect and do all the stuff like create, import etc
See my wiki at https://wiki.gardiol.org/7-services/radicale
It also shows how to install infCloud to get an actual web GUI to use calendars from your server
Try LazyNVR for reolink cameras, it’s very lightweight and a different take than frigate https://codeberg.org/LazyNVR/lazynvr-sources
To my knowledge conduit is basically dead in the water. Very little updates if any.
When I chooses my matrix server, o went with the predecessor of Continuwuity and then migrated to Continuwuity and have been happy ever since…
Tuwunnel don’t know, I didn’t really appreciated the corporate backing somehow and lack of perceived transparency.
Is conduit actually still in business at all?
Yes … That is what pissed me…
But half day of cussing and swearing helped
Isn’t that the plesk added value?
Agree. I went directly with Jellyfin because I joined late the party, but never regret it.
So can’t comment on Plex, because I never used it. But I see the news and see the enshittified path it’s going on with Plex
I understand that they need revenue, specially if they actually provide the bandwidth to let you access your media from outside home. I also understand why people is mad, but I guess convenience come with a price, of you don’t want to pay for it, there are alternatives I don’t see anything bad in switching to jellyfin.
I fully understand your point, but the mailcow as open relay seems strange. Anyway, it’s a risk/cost tradeoff right? Everybody should do it’s own assessment and experimentation. But after the initial setup, it’s zero maintenance. The only maintenance i do is keep the stack regularly updated, and it broke twice in 20+ years (dovecot new config format, WTF…)
Isn’t that the gist of selfhosting?
Yes you can do it, yes you can have it done for you by somebody else. The first is fun, and risky, the second is less fun and less risky. We are all here for the fun… and probably we all don’t care too much of the risks. But why shut down everybody who ask about email selfhosting with a don’t do it? Let them try, make errors and fix them, maybe they learn something new, maybe it works out for them
What is the worst that might come out of it? Some spam? A blacklist? Come on, you can survive both. Don’t use your primary email account as self hosted from the beginning maybe, to mitigate all those risks, no?
Because 99% of helfhosters pull containers, with zero understanding of what they do. They they try email, because heck why not also email, and hit the wall of actually must understand what you are doing or else…
Yes probably selfhosting email is for advanced users, people who at least know how to manage a DNS record and how nwtworking works. Maybe it’s just that selfhosting bar has dropped significantly thanks to docker, and indeed email hosting is a bit more complex that just “docker compose pull” approach.
Yet i think people should not be scaring others so easily on email self hosting, it’s perfectly doable and fun to do. Maybe don’t switch your primary account just imediately to mitigate risks…
I fully agree with you.
but i guess, from other replyies, people are just afraid somehow and have deep rooted fears about email and self hosting it. The people like you and me who have actually done it, understand that’s not that impossible.
And like with anything you learn only doing it, not fearing it. Maybe don’t switch your main account just from day 0 and see how it goes… :)
Never said it’s for beginners. It’s not.
You must understand what you do and do it properly. IT’s not drop a container and run mindless. Regardless, you can do it if you take the proper precautions and have fun doing it.
I fully agree with you: it’s NOT easy. And you must understand what you do. It’s not just deploy a container and run happy.
I might say this is the first serious step for a selfhoster, something that goes over and beyond just hosting a service for yourself and fun, since it federates (modern term fur how email works) with the outside world.
Are you scared of hosting email? don’t do it. You want to learn and improve your skills and you are happy with running the risks associated? go for it.
Anyway tools like stalwart and mailcow do provide full instructions for DKIM/DMARK and DNS records that you only need to follow, so today there are easier options than the “old days”.
Anyway you don’t have to do it on your primary email from day one, just use a test account/domain and see how it goes. Keep using your gmail account and spin it up on a secondary domain, if it works good… switch over in 6 months or 2 years as you are confortable. OTherwise, keep gmail and stop.
Sorry man, i understand your fears, but it’s not that difficult. Granted, you need to STUDY and UNDERSTAND what you do, it’s not just deploy a container and run. But hey, you can give up on learning new stuff and don’t run risks ever, in that case you should also stop driving a car, since it’s much more dangerous than running an open relay by error.
Also, use mailcow stalwart or any other already packaged solution if you want to be safe.
I fully agree …
Email server require to understand what and why you are doing. This is a steep step up from spinning docker containers.
Nothing against docker containers, I run quite a few myself… But indeed a successful email server is a different beast.
Many people also try self host it at home, and this is a serious issue with email due to the residential ip address as well.
But it can be done successfully and it’s a great feeling of accomplishment when you do it. And you learn way more than using containers
Also all containerized solutions for email require the understanding and additional steps like DNS done properly as well .
That is a mandatory requirement for proper email delivery.
Not an issue with email itself, more due to spam prevention and such.
I flagree that hosting email servers on residential IPs is a recipe for being filtered and blocked
Email must run on a server with a public non residential ip address. Email is something you definitely can self host just not on your home server. Maybe that was the issue from the start?
Stalwart is nice, but definitely not lightweight in my experience… Mailcow is a fully docker based solution.
That is plain not true…
I run my email server since decades and the only upgrade I had to to over time was adding dkim dmarc and proper DNS records. Took a few hours of studying, but perfectly doable
Granted, running docker containers is much easier than setting up a proper email setup. But be this is because with the latter you must understand what you are doing…
Why people keep spreading this misinformation? It’s plainly not true and I am the living proof of that.
Been using my email self hosted (on VPs) for decades now, never had serious issues at all. And it’s all my family primary addresses
What is the problem? I have been self hosting my mail for the last 20+ years and has always worked pretty well.
I rent a VPS for that since you should not use a residential address for email servers.
If you are careful enough to configure it properly I assure you that it works and it’s perfectly usable and stable
All my family primary email addresses are managed in that way on my various domains and we never had a single issue
Today it’s even easier because there are all in one docker based solutions. But going the hard way is perfectly doable as well.
Here is my experience, on my wiki, if you are interested https://wiki.gardiol.org/doku.php?id=email%3Astart
Be aware that there are no optional steps: everything must be properly installed and setup from DNS entries to dkim/dmarc and certificates. But I promise, maintenance it basically zero after a proper setup. And I think twice in 20 years something broke. And the nice part of that email will just be delayed and delivered after you fix it, nothing gets ever lost
I love email, with all it downfalls, it’s still one of the most resilient and solid stuff on the internet.
Yes, there aren’t many options that is not idea but it works fine