I guess it’s like how “cooking from scratch” evolved. A cookbook from the nineteenth century might have said “1 hog” as an ingredient and instructed you to slaughter it. Now of course you buy hog pieces on foam trays.
But there's a whole market of people who could benefit from self hosting, but shouldn't be required to understand all the details.
For example, you can get many of these benefits by using a managed service with your own domain. Things like data ownership, open source software, provider competition, etc.
I think we need a broader term. I've been using "indie hosting" lately.
I think one of the big drivers of it has been the serious increase in performance and capability of the low power embedded processors from Intel and AMD (and in the last year or so some ARM based ones), like supporting more than 2GB of ram and having multiple cores that can meaningfully do work even with a 15W TDP.
>Starting from this version, the processing of media files using HEVC (H.265), AVC (H.264), and VC-1 codecs will be transitioned from the server to end devices to reduce unnecessary resource usage on the system and enhance system efficiency.
https://www.synology.com/en-us/releaseNote/DSM
They say it's to "reduce unnecessary resource usage" and "enhance efficiency", I say it's the start of a race to the bottom of the barrel now that the market is saturated and BOMs start weighing heavier.
Shared custody
No confidentiality
Portable domain identity
If they search around for an answer to that question, pretty soon someone is going to tell them to "self-host a Mastodon instance" or in the near future "self-host an ATProto instance".
My point is that the term "self-hosting" is unlikely to get them what they want, unless they happen to be interested in learning about DNS, IP addresses, ports, port forwarding, routers, firewalls, NAT, CGNAT, TLS, TCP, HTTP, web servers, Linux, updates, backups, etc, etc.
I don't think "web hosting" is going to help them much either.
What most people want is something like a Mastodon instance from masto.host[0] that integrates with a service like TakingNames[1] (which I own) to delegate DNS with OAuth2. I think we need a new term for this sort of setup. I think the term should also include self-hosting solutions, as long as those solutions focus on the outcomes (having a car to drive), not the implementation (building a kit car).
[0]: https://masto.host/
It's not as unambiguously incorrect as other silly things people say and do that are technically incorrect, but it is annoying when people don't provide enough context where it matters.
Honestly, the distinction only really matters when discussing privacy. Hosting your own stuff in a rented VM is still self hosting, but if you're talking about how you self host because you care about the security of your data, you're now definitely not talking about rented VMs.
Generally, I think we need to get used to the idea that "self hosting" now also refers to hosting software you configure on rented systems / VMs.
Has there been work to quantify relative network effects in Twitter vs Mastodon, either generally or in specific communities? e.g. if person A was following N people on Twitter (e.g. in a list), what subset or superset of N could be followed on Mastdon?
If a user requested all their data from Twitter, including people being followed, is there tooling to map user identity/handles from Twitter to member names on decentralized alternatives?
> someone is going to tell them to "self-host a Mastodon instance.. from masto.host
Wouldn't that be masto-hosted rather than self-hosted?
In that scenario, Masto.host would be a trusted custodian of a social media identity, somewhat like a bank.
The one generally accepted exception to this is network protection. You don't want to expose your home ip address to the outside world if you can help it, so a lot of people use tailscale, cloud flare tunnels, or a vps as a proxy.
If you know Wireguard well enough to set up your own and you're willing, you'll have a lot more control and less dependency, which is a win IMHO. But if you are limited by time and/or knowledge, Tailscale is great
Staying on the topic, I wonder how easy/complicated is to self-host Head scale, which is the opensource implementation of the TS server.
I wanted a NAS. I could do it with Linux and ZFS, rolling my own with full control. However, I didn’t want to sink that much time into it, and figured when something needed to be done, I would have forgotten so much I’d need to relearn over and over again.
Instead I went with a Synology. I get my NAS, I’m in control of my data, I can run some stuff with Docker on it… but I don’t really have to spend any time playing sys admin on my weekends.
Tailscale adds a lot of conveniences on top of Wireguard, though. I don't think most of their value comes from just eliminating the key management stuff from Wireguard setup.
There are more lightweight projects that rely on native kernel mode wireguard (thus giving fantastic performance) and only simplify key setup, without the need for persistent daemons that have had their own high severity CVEs. If you're asking this question, you might be better served by something like innernet (again, there are tons of alternatives).
There are more alternatives that are fully open and self hostable (including all server components), have support for the native kernel module, while having the same feature set as Tailscale (like netbird, but it's not the only one).
But TS is an HN darling because their devs have a presence here, some of them very well known and highly visible, and the company places lost of advertisements in podcasts and such.
When I discovered tailscale it was a godsend - all the annoying, boring, moving parts are gone. Thus is a fantastic product that just works.
I have a backup WG link to my main servers just in case but this is that: a backup.
AFAIK Tailscale only supports 2 modes of connection: direct connect or relayed over WebSockets with their DERP protocol. CGNAT is going to limit you to DERP, which is not designed for transmitting a lot of data. For one thing, that could get rather expensive for Tailscale.
It took a bit of time to set this up (and I fortunately had the V4 block already registered from back in the 90's.) I also had experience with BGP from previous jobs at early ISPs, which helped. Proxying is easier.
In case that doesn't make me an old timer, I also actually have pork and home cured bacon in the freezer from hogs we raised and processed. "An old soul living in a new world" feels pretty fitting here.
Every ISP prohibition on self-hosting that I have seen specifies commercial use, not just hosting services (since obviously that could technically prohibit tons of normal and authorized uses like co-op games).
and so does the author, kind of...
"And so, here is a gentle introduction to self-hosting that is not "true self-hosting", but whatever. Sue me."
:)
Or read an HN thread on "true self-hosting", https://news.ycombinator.com/item?id=41440855#41460999
Why arguing on semantics?
If you want to have a truly service "by you" this is going to be complicated to rewrite (or review) the applications and OS and build your own hardware from something arbitrarily defined as "scratch".
It sounds very much like the discussions of audiophiles about golden cables and what not - while others listen to the music for the pleasure of listening.
A hosting vendor will have detailed "Terms of Service" by jurisdiction, self-hosting will not.
> complicated to rewrite (or review) the applications ... build your own hardware from scratch
There are options between those two extreme scenarios, many discussed at length in HN self-hosting threads.
If you're running your own box, you still depend on network infrastructure and uplink of a service provider, whereas a cloud infrastructure provider may go the other way and negotiate direct connections themselves.
Plenty of valuable lessons await for those who even just provision a virtual host inside AWS and configure the operating system and its software themselves. Other lessons for those who rack up their own servers and VNETs and install them in a data-centre provider instead of running them onsite.
There's only so much you can or should or want to do yourself, and its about finding the combination and degree that works for you and your goals.
For a lot of stuff that doesn't need constant public network connectivity, I choose to run a home lab.
Depends, maybe? Was the speaker talking about hardware or software 10 years ago?
Because, when I was given the 'self-hosting' option by some SaaS vendor, it meant that I could host it on whatever I want to independent of the vendor, whether that is a rack in my bedroom or a DO droplet.
When I was given the 'self-hosting' option by some computer vendor (Dell, HP, Sun, etc), it meant that I can put the unit into a rack in my bedroom.
Context was always key; in my mind, nothing has changed.
Kind of makes sense, but kind of also makes historical texts more difficult to understand. In the year 2124, who know what "self-hosting" meant in 2054? I guess it's up to future software archeologists to figure out.
I actually self-host tools, and that involves having (in my case) a couple of rackmount servers in my spare bathroom, and an rPi5 with a 4x m.2 hat on my desk. Hell, even just running stuff on your own desktop/laptop is self-hosting.
But PaaS and SaaS are just as not-self-hosted as IaaS is. It's literally cloud hosting.
It's not so hard to genuinely self-host. You just need a reasonable ISP who is willing to open your connection, and to be sensible about securing your systems.
This isn't hard, but sure, just pretend words are all nebulous and ineffable and "imaginary".
WHERE and HOW it is hosted, is less important to me. Because if you self-host your own tools, you can freely pick them up and move them to any hosting provider, a cloud provider, or a Raspberry Pi in your basement. Self-hosting FREES you from infra/vendor lock-in.
Hosting from home has its own challenges, so I get why people would go to a hosting provider, but I do think some control is given up in the process.
I self-host my stuff on third-party VPSes and cloud providers. Partly because my residential internet is not suitable for self-hosting and partly because I trust the infra in a profit-motivated datacenter to have WAY more 9s of uptime than anything I could cobble together in my basement. This stuff helps run my life, it's not my hobby, nor something I want to spend more than the necessary amount of time managing.
If I wake up tomorrow and my providers have gone dark without any warning, I am back in action in just a few simple steps:
1. Purchase a new VPS or two
2. Run ansible playbooks
3. Restore data from backups
I feel like there's another term for what you're thinking of but I cannot come up with what it is.
Self-hosting definitely was locally hosted on your own hardware back when hosting providers like Linode, Digital Ocean, AWS, etc existed or were as customizable.
Even corporations "self-host" GitHub Enterprise or Gitlab when they set it up on AWS. Self-host just means you're not reliant on creator of the application to host it for you and manage the server.
There are certainly advantages and disadvantages to self-hosting on your own hardware, as there are to using a hosting provider.
In the beginning, self-hosting was seen as completely local partially because there were no good options for hosting on a server, so that's probably where it sort became synonymous with hosting it in your home.
Unfortunately, it also normalized and further desensitivied us to the topic.
Though I'm quite happy to see that eating sentient beings gets out of fashion, at least in developed world.
1. battery backup
That said, I'm not zealous about it. "Perfect is the enemy of good" and I like ecosystem diversity in general. Better to have a few dozen shared hosting providers than 2 or 3 monopolies.