Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
What benefits to running it as an VM rather than on bare metal.
For me just the convenience of having everything in one box. Simplifies networking too. I run home assistant, openwrt, OMV, an ubuntu dtop VM and a wordpress LXC on a little m93 I jacked up with 32Gb RAM. Backups are dead simple and it's all on one little UPS.
Some might prefer metal for other reasons but simplicity and convenience are priorities for me, at least in my homelab.
The rules now are generally: bare metal if that's all the box will do, or it's main task, container if it's one of many services, vm if it's a larger application you might migrate and i/o isn't your limitation.
The line between container and vm is fuzzy, but bare metal means you're making a design choice for that machine and if that or another application breaks the machine you're screwed.
In a way freebsd is amazing for this, you put all applications in jails and don't use the main userspace much, but the virtualiztion story isn't quite there yet.
Beyond the other reasons, the idea is that you can keep the hypervisor (host OS) minimal and stable and so it's less likely to break. Whereas you can break the VM to your heart's content and you'll still have access to the host and don't need to rely on live USB etc to recover (or even video access since you can still access the host over the network). You can also migrate the VM to a new system more simply since it's just a VM with simpler, abstracted hardware that is less likely to run into driver issues.
One downside of a VM is that GPU passthrough/GVT-g isn't always stable or performant (especially GVT-g), so you might want to keep some services on the host if they need GPU access (such as transcoding). You can still access the files in the VM over NFS/Samba from the host. Although I'd use containers (e.g. docker) at least, sticking with the principle of keeping the hypervisor OS as minimal as possible.