

Someone registering the domain would be able to receive any email sent to any address under this domain, including password resets.


Someone registering the domain would be able to receive any email sent to any address under this domain, including password resets.


Alternatively, if your databases are on a filesystem that supports snapshots (LVM, btrfs or ZFS for instance), you can make a snapshot of the filesystem, mount the snapshot and backup thame database from it. This will ensure the backup is consistent with itself (the backed up directory was not written to between the beginning and the end of the backup)


Enabling multi DC redundancy is really easy though. The other providers you mentioned may have it by default, but they’re also a lot more expensive.
I love that they let me pick my own redundancy strategy, without forcing me to pay for theirs


ENS stands for Ethereum Name Service


I’m personally using Docker MailServer. It’s been working great for over a year now, but mailu seems to have some interesting features (I’m especially interested in the admin panel)


You’re probably behind a CGNAT, check out the other comments


Glad I could help :)


Your ISP might make you go through another layer of NAT. Can you find the WAN IP address of your router and compare it to your public IP address from a website such as ipinfo.io ?
If they do not match, you’re probably out of luck and will need to forward your port from an actually public IP in order to achieve what you want
More details : CGNAT (Carrier Grade Network Address Translation) is basically a second router between your router and the public internet. This second router is configured in the same way as your personal one, the main difference being that your ISP fully manages it. From the viewpoint of this second router, your WAN IP is a private IP, and you share one actual public IP with several other customers (the same way all devices on you LAN share one single WAN IP)
Performing port forwarding from the public internet to your LAN, when behind a CGNAT, would require you to be able to configure a forwarding rule in the ISP’s NAT, which you usually cannot do.


I can recommend some stuff I’ve been using myself :
I design, deploy and maintain such infrastructures for my own customers, so feel free to DM me with more details about your business if you need help with this


I’m pretty sure they are actually hosting it. The tech is quite different (cofractal uses urls ending with {z}/{x}/{y}, while their tile sever uses this stuff that works quite differently)


They told me about hosting their own tile server earlier today. I’m really impressed by how fast they moved !
A pull request for a privacy page during the onboarding is in the works, and I’ve been working with them to update the settings page and documentation (with the goal of providing an easy way to switch map providers). They are also working on a privacy policy, and want to ship all of this in a few weeks as part of a single release.
Once again, I’m really impressed with how well they’re handling this


Or you can quite easily configure nginx as your personal caching proxy with an arbitrarily long TTL/retention duration (you can check out my follow-up post for instructions on doing that)


I used to wonder what kind of nerd notices this kind of thing, now I’m one of them
Edit : If you want to join us :


Blocking the DNS was the first thing I did. This is intended to restore the map feature without having to trust a random company I’ve never heard of.
What do you mean by “a diff of a code fix” that would be simpler ?


You can, but you would not be able to display the map. Might as well disable the map server-wide


Thanks for the detailed feedback. According to one Immich dev, they used to use OSM’s raster tile provider but switched away from it since they were causing too much load on OSM’s servers.
There does not seem to be any non-commercial vector-tile provider at the moment (though OSM seems to be currently working on it), and it seems really overkill to try and self-host a tile provider (at least with the default level of details). Maybe the way is to find a balanced level of details that makes it reasonable to self host


Quoting one dev from the conversation I had on Discord :
the one run by OSM is not intended for general purpose use because that results in way too much load on their system. We used to use theirs, but as Immich grew we decided that we should relieve them of that
I guess you (and they) are talking about raster tiles, since OSM does not seem to provide vector tiles
Things have been going well for me, using docker-mailserver.
I followed the setup guide, did everything in the DKIM, DMARC and SPF documentation page. The initial setup required more involvement from me than your standard docker-compose self-hosting deployment, but I got no issues at all (for now, fingers crossed) after the initial setup : I never missed any inbound e-mails, and my outbound e-mails have not been rejected by any spam filter yet.
However, I agree with everyone else that you should not self-host an important contact address without proper redundancy/recovery mechanism in case anything goes wrong.
You should also understand that self-hosting an email address means you should never let your domain expire to prevent someone from receiving emails sent to you by registering your expired domain. This means you should probably not use a self-hosted e-mail to register any account on services that may outlive your self-hosted setup because e-mail is frequently used to send password reset links.


I will definetly look into this. I’ve been using tube archivist for a while now, but it eats so much RAM (especially the Elastic search dependency IIRC)!
I had one such case recently, turned out it was due to a faulty SATA (data) cable. Once you find which drive is clicking, try plugging it with a new cable before declaring it dead.
dmesgoutput may contain some useful error messages. If you find errors related to I/O, block devices, SCSI or SATA, you should include them in your post