this post was submitted on 18 Jun 2023
256 points (98.1% liked)

Selfhosted

40345 readers
418 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

In the past few days, I've seen a number of people having trouble getting Lemmy set up on their own servers. That motivated me to create Lemmy-Easy-Deploy, a dead-simple solution to deploying Lemmy using Docker Compose under the hood.

To accommodate people new to Docker or self hosting, I've made it as simple as I possibly could. Edit the config file to specify your domain, then run the script. That's it! No manual configuration is needed. Your self hosted Lemmy instance will be up and running in about a minute or less. Everything is taken care of for you. Random passwords are created for Lemmy's microservices, and HTTPS is handled automatically by Caddy.

Updates are automatic too! Run the script again to detect and deploy updates to Lemmy automatically.

If you are an advanced user, plenty of config options are available. You can set this to compile Lemmy from source if you want, which is useful for trying out Release Candidate versions. You can also specify a Cloudflare API token, and if you do, HTTPS certificates will use the DNS challenge instead. This is helpful for Cloudflare proxy users, who can have issues with HTTPS certificates sometimes.

Try it out and let me know what you think!

https://github.com/ubergeek77/Lemmy-Easy-Deploy

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago (1 children)

how well do those email servers work to begin with? i just flat out disabled the postfix relay on my instance and simply configured sendgrid, which works perfectly, no delays or spam folder issues (although i did have to disable a bunch of tracking bullshit). doing so with similar services has been my go-to card in freelance webdev, because getting other mail servers to trust you can be hard, so i'm interested in the experience people are having with those. (i'd much prefer to self-host email too, but providing a good experience is the primary goal)

[–] [email protected] 2 points 1 year ago (1 children)

I haven't actually used the embedded postfix server at all, I keep mine disabled. I only include it because it's "included" in the official Docker deployment files, and I try to keep this deployment as close to that as possible.

I'm considering adding support for an external email service, as you mentioned, but I have nearly zero experience in using managed email services, and I'm not sure if non-technical users would be able to navigate the configuration of things I can't do for them (i.e. on a web dashboard somewhere). And if I can't do it for them, it means more issues for me, so I hesitate to add support for it at all.

I'd love to hear your experience in setting up sendgrid and how easy that was. And the tracking stuff you mentioned as well.

[–] [email protected] 1 points 1 year ago (1 children)

On the surface, setting up an external mail server is actually super easy. Pretty much every service supports SMTP, so all you need is to find your credentials (an endpoint, a username, and a password) and input that in your lemmy.hjson file, along with a sender address. There is a verification process with every email provider, you will usually have to set some DNS records to prove you own the domain you're trying to send from, but once you do these two things, emails will just start flying out.

The actual process tends to be a little more tedious though. Pretty much every mail provider wants to sell you on their specific super awesome API and only mentions SMTP as a footnote, for reasons that I can only parse as an attempted vendor lock-in. They also sometimes make the verification process difficult. SendGrid, for example, immediately redirects you to their "sender identities" which are more useful for their marketing automation tooling than they are for automated emails from a website, and you also have to dig a fair bit to find the SMTP credentials. (The endpoint is smtp.sendgrid.net, apikey on the username, and whatever your API key is for the password, you'll need to set one of those up.) They also have a number of different tracking things that you'll have to find and turn off in the UI (luckily all of them can be toggled in the same place), which would normally actually help you by providing you statistics about how many emails were opened and how many people clicked on links, but for the emails Lemmy sends, it's useless and I didn't want SendGrid to collect that data on my instance users, so I shut that off.

Initially, I wanted to use Amazon SES, but they have an even more tedious setup: you have to talk to an actual human to have them turn it on for you, otherwise you're stuck in sandbox mode and can only send email to verified receiver addresses. Their service works well though, I used it a lot in my freelancer days, and they do make it fairly straightforward to find the SMTP credentials, but the verification process can be slow.

I also remember using Mailgun for some project ages ago, it was pretty much the same deal as all the others: you have to pry the SMTP details out of their docs, but once you do and you verify your stuff, it works well.

Ultimately, I think the best you could do to help out users here is to provide them with documentation for a few of these services: exactly where to go, which buttons to click and whatnot. Or just stick to the embedded service for a bit, but the real issue there is the bounce rates from spammers. They made my instance send out like 60-70 verification emails for bogus addresses on gmail, yahoo, hotmail, and live.com on the first day I got federation working, and if you don't already have a good reputation -- which is what these third parties help you with -- then you can easily get yourself blacklisted, either internally or externally.

[–] [email protected] 2 points 1 year ago (1 children)

I see. Thanks a lot for this!

I really don't have the capacity to support a bunch of different email services, so it sounds like the best I can do right now is make the SMTP settings accessible without also running the postfix server. So if someone wants to run their own email somewhere else, they can configure it. But otherwise, I'll leave it to the user to figure out what happens after an email request leaves Lemmy.

Does that sound fair, and like something you would have used? Essentially just an interface in config.env that puts the right SMTP address/credentials in lemmy.hjson.

[–] [email protected] 1 points 1 year ago (1 children)

yup, that sounds perfect

i can't track down a non vendor-specific guide right now but if you just expose the same settings in config.env that you'd have in the lemmy.hjson file that should be more than sufficient to get an external service going

[–] [email protected] 2 points 1 year ago

Thanks!

I've got that included in a staging version I'm preparing to release, if you wanted to take a look at the changes:

https://github.com/ubergeek77/Lemmy-Easy-Deploy/issues/17