I’m trying to better understand hosting a Lemmy Instance. Lurking discussions it seems like some people are hosting from the Cloud or VPS. My understanding is that it’s better to futureproof by running your own home server so that you have the data and the top most control of hardware, software etc. My understanding is that by hosting an instance via Cloud or VPS you are offloading the data / information to a 3rd party.
Are people actually running their own actual self-hosted servers from home? Do you have any recommended guides on running a Lemmy Instance?
“Self-hosted” means you are in control of the platform. That doesn’t mean you have to own the platform outright, just that you hold the keys.
Using a VPS to build a Nextcloud server vs using Google Drive is like the difference between leasing a car and taking a taxi. Yes, you don’t technically own the car like you would if you bought it outright, but that difference is mostly academic. The fact is you’re still in the driver’s seat, controlling how everything works. You get to drive where you want to, in your own time, you pick the music, you set the AC, you adjust the seats, and you can store as much stuff in the trunk as you want, for as long as you want.
As long as you’re the person behind the metaphorical wheel, it’s still self-hosting.
Selfhosting is the act of hosting applications on “hardware you control”. That could be rented or owned, its the same to us. You could go out and buy a server to host your applications but there a few issues that you might run into that could prevent you from simply standing up a server rack in your spare room. From shitty ISPs to lack of hardware knowledge there are plenty of reasons to just rent a VPS. Either way youre one of us :)
But you don’t control the hardware if you run it on a VPS?
You control the hardware you are provisioned and the software you run on it, which is enough for me. Unless you’re looking for a job in the server adminstration/maintenance field the physical hardware access component of it matters less IMO
You definitely don’t control the hardware. Someone else at some remote server farm or something does.
Self hosting basically means you are running the server application yourself. It doesn’t matter if it’s at home, on a cloud service or anywhere else.
I wouldn’t recommend hosting a social network like lemmy, because you would be legally responsible for all the content served from your servers. That means a lot of moderation work. Also, these types of applications are very demanding in terms of data storage, you end up with an ever growing dataset of posts, pictures etc.
But self hosting is very interesting and empowering. There are a lot of applications you can self host, from media servers (Plex, Jellyfin), personal cloud (like Google Drive) with NextCloud, blocking ads with pihole, sync servers for various apps like Obsidian, password manager BitWarden etc. You can even make your own website by coding it, or using a CMS platform like WordPress.
Check the Awesome Self-hosted list on GitHub, has a ton of great stuff.
And in terms of hardware, any old computer or laptop can be used, just install your favorite server OS (Linux, FreeBSD/OpenBSD, even Windows Server). You can play with virtualization too if you have enough horsepower and memory with ESXI or Proxmox, so you can run multiple severs at once on the same computer.
Hey, I love this thread, and I am intrigued by the term "futureproof"ing. can someone direct me to a thread where local networks are self-hosted and the human element of organizing the network is discussed? Thank you. If I don’t come back, it’s because I’m new to Lemmyworld and got lost.
I consider selfhosting to be both. VPS or homelab. The latter has more ‘cred’ but is also a much bigger investment and not everyone can do it. Granted I’m living in a difficult environment but as somebody using Linux since 1994 it took me 3 years to recently get a homelab to where I could credibly serve the wider internet from it, and I still use a VPS as reverse proxy anyway! Meanwhile, offloading your physical plant to a mom-n-pop platform-as-a-service provider isn’t the worst thing in the world. Some operators started out selfhosting and grew their little VPS provider from that, those guys need business too!
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CGNAT Carrier-Grade NAT DNS Domain Name Service/System Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol LXC Linux Containers NAS Network-Attached Storage NAT Network Address Translation Plex Brand of media server package SATA Serial AT Attachment interface for mass storage SSD Solid State Drive mass storage VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) nginx Popular HTTP server
[Thread #139 for this sub, first seen 16th Sep 2023, 05:05] [FAQ] [Full list] [Contact] [Source code]
I ran one for a few months until I woke up one morning and it wasn’t working. As I was the only person using it, I didn’t bother to troubleshoot and just signed up for an account at lemmy.world.
If you want to run your own I recommend you check out the ansible install route. It’s really simple and straightforward once you wrap your head around ansible.
actually have a server at home
I haven’t got any piece of hardware that was sold with the firstname “Server”.
But there’s this self-built PC in my room that’s running 24/7 without having to reboot in several years…
Well technically a “server” is a machine dedicated to “serving” something, like a service or website or whatever. A regular desktop can be a server, it’s just not built as well as a “real” server.
There is though reasons to stray from certain consumer products for server equipment.
Certain cloud providers are as secure, if not more secure, than a home lab. Amazon, Google, Microsoft, et al. are responding to 0-day vulnerabilities on the reg. In a home lab, that is on you.
To me, self-hosted means you deploy, operate, and maintain your services.
Why? Varied…the most crucial reason is 1) it is fun because 2) they work.
Listing Microsoft cloud after their recent certificate mess is an interesting choice.
Also, the “cloud responds to vulnerability” only works if you’re paying them to host the services for you - which definitely no longer is self hosting. If you bring up your own services the patching is on you, no matter where they are.
If you care about stuff like “have some stuff encrypted with the keys in a hardware module” own hardware is your only option. If you don’t care about that you still need to be aware that “cloud” or “VPS” still means that you’re sharing hardware with third parties - which comes with potential security issues.
Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense. So it’s not just “yum —update” and reboot to remediate a vulnerability, there is more to it; the odds of a home lab admin keeping up with that seem remote to me.
Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.
Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?
Well with bare metal yes, but when your architecture is virtual, configuration rises in importance as the first line of defense
You’ll have all the virtualization management functions in a separate, properly secured management VLAN with limited access. So the exposed attack surface (unless you’re selling VM containers) is pretty much the same as on bare metal: Somebody would need to exploit application or OS issues, and then in a second stage break out of the virtualization. This has the potential to cause more damage than small applications on bare metal - and if you don’t have fail over the impact of rebooting the underlying system after applying patches is more severe.
On the other hand, already for many years - and way before container stuff was mature - hardware was too powerful for just running a single application, so it was common to have lots of unrelated stuff there, which is a maintenance nightmare. Just having that split up into lots of containers probably brings more security enhancements than the risk of having to patch your container runtime.
Encryption is interesting, there really is no practical difference between cloud vs self hosted encryption offerings other than an emotional response.
Most of the encryption features advertised for cloud are marketing bullshit.
“Homomorphic encryption” as a concept just screams “side channel attacks” - and indeed as soon as a team properly looked at it they published a side channel paper.
For pretty much all the technologies advertised from both AMD and intel to solve the various problems of trying to make people trust untrustworthy infrastructure with their private keys sidechannel attacks or other vulnerabilities exist.
As soon as you upload a private key into a cloud system you lost control over it, no matter what their marketing department will tell you. Self hosted you can properly secure your keys in audited hardware storage, preventing key extraction.
Regarding security issues, it will depend on the provider but one wonders if those are real or imagined issues?
Just look at the Microsoft certificate issue I’ve mentioned - data was compromised because of that, they tried to deny the claim, and it was only possible to show that the problem exists because some US agencies paid extra for receiving error logs. Microsofts solution to keep you calm? “Just pay extra as well so you can also audit our logs to see if we lose another key”
The azure breach is interesting in that it is vs MSFT SaaS. We’re talking produce, ready to eat meals are in the deli section!
The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.
Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.
A container should refuse to execute processes that have nothing to do with container function. For ex, there is no reason to have a super user in a container, and the underlying container host should never be accessible from the devices connecting to the containers that it hosts.
Bare metal is an emotional illusion of control esp with consumer devices between ISP gateway and bare metal.
It’s not that self hosted can’t run the same level of detect & reject cfg, it’s just that I would be surprised if it was. Securing self hosted internet facing home labs could almost be its own community and is definitely worth a discussion.
My point is that it is simpler imo to button up a virtual env and that includes a virtual network env (by defn, cloud hosting).
The encryption tech in many cloud providers is typically superior to what you run at home to the point I don’t believe it is a common attack vector.
They rely on hardware functionality in Epyc or Xeon CPUs for their stuff - I have the same hardware at home, and don’t use that functionality as it has massive problems. What I do have at home is smartcard based key storage for all my private keys - keys can’t be extracted from there, and the only outside copy is a passphrase encrypted based64 printout on paper in a sealed envelope in a safe place. Cloud operators will tell you they can also do the equivalent - but they’re lying about that.
And the homomorphic encryption thing they’re trying to sell is just stupid.
Overall, hardened containers are more secure vs bare metal as the attack vectors are radically diff.
Assuming you put the same single application on bare metal the attack vectors are pretty much the same - but anybody sensible stopped doing that over a decade ago as hardware became just too powerful to justify that. So I assume nowadays anything hosted at home involves some form of container runtime or virtualization (or if not whoever is running it should reconsider their life choices).
My point is that it is simpler imo to button up a virtual env and that includes a virtual network env
Just like the container thing above, pretty much any deployment nowadays (even just simple low powered systems coming close to the old bare metal days) will contain at least some level of virtual networking. Traditionally we were binding everything to either localhost or world, and then going from there - but nowadays even for a simple setup it’s way more sensible to have only something like a nginx container with a public IP, and all services isolated in separate containers with various host only network bridges.
I like how you have a home smartcard. I can’t believe many do.
Why do you think cloud operators are lying?
I like how you have a home smartcard. I can’t believe many do.
Pretty much anyone should do. There’s no excuse to at least keep your personal PGP keys in some USB dongle. I personally wouldn’t recommend yubikey for various reasons, but there are a lot more options nowadays. Most of those vendors also now have HSM options which are reasonably priced and scale well enough for small hosting purposes.
I started a long time ago with empty smartcards and a custom card applet - back then it was quite complicated to find empty smartcards as a private customer. By now I’ve also switched to readily available modules.
Why do you think cloud operators are lying?
One of the key concepts of the cloud is that your VMs are not tied to physical hardware. Which in turn means the key storage also isn’t - which means extraction of keys is possible. Now they’ll tell you some nonsense how they utilize cryptography to make it secure - but you can’t beat “key extraction is not possible at all”.
For the other bits I’ve mentioned a few times side channel attacks. Then there’s AMDs encrypted memory (SEV) claiming to fully isolate VMs from each other, with multiple published attacks. And we have AMDs PSP and intels ME, both with multiple published attacks. I think there also was a published attack against the key storage I described above, but I don’t remember the name.
I agree that our stuff is unlikely to be victim of an targeted attack in the cloud - but could be impacted by a targeted attack on something sharing bare metal with you. Or somebody just managed to perfect one of the currently possible attacks to run them larger scale for data collection - in all cases you’re unlikely to be properly informed about the data loss.
