Is it an option? Can't find it. (But GitHub is confusing and I'm old, so maybe there's something?)
Reminder that you can go for hybrid approaches; receive email and host IMAP/webmail yourself, and send emails through someone like AWS. I am not saying you can't do SMTP yourself, but if you want to just dip your toes, it's an option.
You get many of the advantages; you control your email addresses, you store all of the email and control backups, etc.
...
And another thing: you could also play with https://chatmail.at/relays ; which is pretty cool. I had read about Delta Chat, but decided to play with it recently and... it's blown my mind.
https://dgross.ca/blog/linux-home-server-auto-sleep did the rounds lately.
But you'll need another system to always be on to handle this.
In many cases, you can "fake" this in other means. For example, I had Remmina configured to run a script to send a WOL packet and wait before connecting via remote desktop to a computer.
Came in here to mention Incus if no one had.
I love it. I have three "home production" servers running Proxmox, but mostly because Proxmox is one of very few LTS/comercially-supported ways to run Linux in a supported way with root (and everything else on ZFS). And while its web UI is still a bit clunky in places, it comes in handy some times.
However, Incus automation is just... superior. incus launch --vm images:debian/13 foo, wait a few seconds then incus exec foo -- bash and I'm root on a console of a ready-to-go Debian VM. Without --vm, it's a lightweight LXC container. And Ansible supports running commands through incus exec, so you can provision stuff WITHOUT BOTHERING TO SET UP ANYTHING.
AND, it works remotely without fuss, so I can set up an Incus remote on a beefy server and spawn VMs nearly transparently. + incus file pull|push to transfer files.
I'm kinda pondering scripting removal of the Proxmox bits from a Proxmox install, so that I just keep their ZFS support and run Incus on top.
Well, it's more procedural than object-oriented because it's easier to avoid object-oriented programming than procedural code :D
(Note: I wouldn't call defining classes OOP until you start using inheritance. Overriding __str__ and stuff might count, but not a lot to me.)
Personally, as time goes on, I use inheritance less.
I switched to Emacs over two years ago because I was getting too comfortable in VS Code. If VS Code didn't have the "dodgy" stuff, I would recommend it to everyone without reservation.
Emacs has been a pleasant surprise. The latest versions have introduced Eglot (LSP), EditorConfig and a few other odds and ends that make it very close to being usable with very little configuration. My latest suggestion for getting started is JUST two lines of config, and I think you can scale easily.
I just wish Emacs had started from the outset with more common keybindings- it makes it hard to recommend because you need to make a significant investment. I think it's worthwhile, but still...
However, due to how it's evolving lately, I suspect it might become even easier to get started with time. If they rolled in to base Emacs automatic LSP installation, that would be huge, for instance.
I assume you basically want protection against disasters, but not high uptime.
(E.g. you likely can live with a week of unavailability if after a week you can recover the data.)
The key is about proper backups. For example, my Nextcloud server is running in a datacenter. Every night I replicate the data to a computer running at home. Every week I run a backup to a USB drive that I keep in a third location. Every month I run a backup to a USB drive on the computer I mentioned at home.
So I could lose two locations and still have my data.
There is much written about backup strategies, for example https://en.wikipedia.org/wiki/3-2-1_backup_rule ... Just start with your configuration, think what can go wrong and what would happen, and add redundancy until you are OK with the risks.
What volume of data you are discussing? How many physical nodes? Can you give a complete usage example of what you want to achieve?
In general, there's a steep change in making things distributed properly, and distributed systems are often designed for big and complex situations, so they "can afford" being big and complex too.
I discovered Open Food Facts very recently. I was supersurprised because the mobile app is very neat, and I didn't expect there would be so many products (edit: in Spain). I've sent two contributions so far.
Also, you can download their database. If I had some time, I'd try to run some queries on it. (I'm on a low sodium diet and sometimes you find the most unexpected products with little salt, but it's time consuming.)
edit: also, I forgot, the app is on F-Droid, another nice touch.
I keep everything documented, along with my infrastructure as code stuff. Briefly:
- Nextcloud
- Vaultwarden
- Miniflux
- My blog
- Takahe (a multi-domain) ActivityPub server
- My health tracker CRUD data entry
- https://alexpdp7.github.io/selfhostwatch/
- Grafana (for health stats and monitoring data from Nagios)
- Nagios
- FreeIPA/Ipsilon (SSO)
edit: plus a few things that do not have a web UI.
I did some testing with it, because I believe more people should be able to self-host.
I like how it is implemented. It has good support for email. Many apps support SSO.
The critical part to me is how up-to-date applications are. I started a small project to automate version tracking, check out:
https://alexpdp7.github.io/selfhostwatch/app/nextcloud.html
; so for example, the YunoHost Nextcloud app does not lag much behind upstream. My intention with this is to let people see that they have been updating Nextcloud dilligently for two years; they might pull the plug tomorrow, but it's a good track record.
(I'd like to add scrapers to other projects similar to YunoHost. My ultimate goal would be to be able to choose a list of apps you'd like to self-host, and see which projects like YunoHost carry the applications you want, and compare how they track updates.)
I think having a solid/stable virtualization layer is very helpful. Whether that's Proxmox, Incus, or something else, it's a matter of taste.
You can then put NixOS, Guix, Debian, Arch, whatever on top.