I've hosted and actively used my own email server for > 10 years and there are two things that are true at the same time:
It is absolutely possible to host, use, and achieve decent deliverability with your own server. It takes work and is a different beast than running a webserver, but that frontier is not dead (yet).
At the same time: it is an ABSOLUTELY TERRIBLE IDEA to suggest that folks operate an email server out of residential IP through your ISP. The spam prevention ecosystem is so draconian now that email traffic flowing out of address ranges belonging to residential owners is yeeted into the sun. If you've operated email infrastructure at decently large scales, you know that SPF/DKIM/DMARC are just one part of how spam is identified, and mixing in the source of email traffic into the detection heuristics is a significant part of that identification process. Achieving decent delivery can often involve "warming up" an IP over time to establish its reputation, and consumer address ranges are a hodge-podge of activity that incur very little trust about what they're doing.
I agree with some commenters that exhort the exercise of self-hosting email to prevent the venerable protocol becoming a homogeneous GMail and Outlook-only world, but there are reliable ways to do this: using a VPS, relying on a company for the sending/SMTP part, or something similar. But footguns abound, and disgorging SMTP packets from your LAN edge is one of them.
It's interesting to contrast this announcement with a similar post from the CEO in 2022 [1]: those past layoffs had much more of a victim-of-circumstances tone as ZIRP was beginning to dry up, but apparently those "bad times" versus "good times" during AI mania just accounts for a delta of +6% additional layoffs.
Another commenter questioned what size bucket Elastic falls into these days; in April 2025 their SEC filing [2] cited about 3,500 employees. So not a startup any more but definitely not fully-fledged FAANG-sized.
(not sure whether it even applies here; but full disclosure, I left Elastic in 2022.)
Thanks for the kind words! Especially given how ubiquitous systemd is now, skilling up on the toolbox with commands like `systemd-analyze` and `systemctl list-timers` feels super valuable.
Hey everyone, author here. I spotted the hn traffic a little late but I'm happy for any feedback or comments and will try and address the top-level comments as I can.
(Aside: I wrote this article early last month but it caught on only just recently. For better or worse, touching a third rail topic like systemd seems like a sure-fire way to elicit strong and numerous reactions both positive and negative.)
Another sort-of-recent development in the space has made self-hosting dramatically more accessible: even though hardware costs were reasonable before, they're now _very_ reasonable and also resource-efficient.
Repurposing an old tower would offer you enough compute to self-host services back in the day, but now an Intel NUC has plenty of resources in a very small footprint and branching out into the Raspberry Pi-adjacent family of hardware also offers even smaller power draw on aarch64 SBCs.
One experiment in my own lab has been to deploy glusterfs across a fleet of ODroid HC4 devices to operate a distributed storage network. The devices sip small amounts of power, are easy to expand, and last week a disk died completely but I swapped the hardware out while never losing access to the data thanks to separate networked peers staying online while the downed host got new hardware.
Relying on container deployments rather than fat VMs also helps to compress resource requirements when operating lots of self-hosted services. I've got about ~20 nomad-operated services spread across various small, cheap aarch64 hosts that can go down without worrying about it because nomad will just pick a new one.
Hardware's hasn't been the issue (at least for the 15 or so years I've been doing server tinkering). The problem is ISPs. They don't want to give me a static IP address, and they don't want to give me even half-decent upload bandwidth.
And a lot of software don't use syslog because it's easier to print to stderr/stdout or some random log file. Journald makes it easier to capture everything no matter what the software does, including the established syslog protocol, so I don't even see your point.
If everything on your machine uses syslog, journald is a drop in replacement for the dozen of possible syslogd implementations.
journald isn't drop-in because it only saves logs locally. syslog also is a protocol to send your logs to a log-server.
And the usual syslog APIs are 2 lines: Initialize with openlog(stream, process_name, flags) and after that do syslog(urgency, message). That is on par with stderr/stdout, and far simpler than handling your own logfiles. Except if you use log4$yourlanguage or something, then everything is just the same, you just configure a different destination.
And if you can't change your code to not use stdout/stderr, you can easily do yourcode | logger -t yourcode -p daemon.info 2| logger -t yourcode -p daemon.err
Hi, author here. The title is intentionally a little attention-grabbing hyperbole but I've appreciated the discussion and feedback about the post. Thanks for reading!
This is a nit-pick, but if you picked the title that way to BE hyperbolic, I am not sure if that is the best thing to do for a technical discussion. It sets an internal opinion before even clicking on it. It subconsciously makes people go into the article with an already preconceived notion.
I loved this game growing up, I'm definitely going to give this a try.
As a minor observation, I'm pretty (pleasantly) surprised that the project provides a NixOS package for the application. As somebody who tends to flit between Arch, Fedora, and NixOS, seeing packages for NixOS before Fedora availability is a very surprising signal in terms of Linux distribution popularity.
It is absolutely possible to host, use, and achieve decent deliverability with your own server. It takes work and is a different beast than running a webserver, but that frontier is not dead (yet).
At the same time: it is an ABSOLUTELY TERRIBLE IDEA to suggest that folks operate an email server out of residential IP through your ISP. The spam prevention ecosystem is so draconian now that email traffic flowing out of address ranges belonging to residential owners is yeeted into the sun. If you've operated email infrastructure at decently large scales, you know that SPF/DKIM/DMARC are just one part of how spam is identified, and mixing in the source of email traffic into the detection heuristics is a significant part of that identification process. Achieving decent delivery can often involve "warming up" an IP over time to establish its reputation, and consumer address ranges are a hodge-podge of activity that incur very little trust about what they're doing.
I agree with some commenters that exhort the exercise of self-hosting email to prevent the venerable protocol becoming a homogeneous GMail and Outlook-only world, but there are reliable ways to do this: using a VPS, relying on a company for the sending/SMTP part, or something similar. But footguns abound, and disgorging SMTP packets from your LAN edge is one of them.