As of today, this site has been hosted directly from my home for two years!

I hope the transition was seamless enough, and its behaviour consistent enough, that no regular visitor would have noticed the change unless I'd mentioned it.

(A note on terms: hosting a site oneself rather than through a hosting service is commonly termed "self-hosting." I avoid the term because, strictly speaking, it implies a site that hosts itself. "A self-cleaning oven" means "an oven that cleans itself," not "an oven you clean yourself" – nor should "self-hosting" mean "a site you host yourself." If a single word is needed, I'd go with "home-hosting.")

The dawn of my home on the Web was October 17, 1997. In other words, though home-hosting is still considered in some respects preferable to commonplace dependency on a hosting service, not to mention appropriately nerdy for a Web enthusiast, it took me ages even to set out to achieve it. The main reason for the delay? Perhaps, like me, you've discovered that to research the topic is to summon a variety of warnings from a variety of people. It can feel like everyone who knows anything about hosting one's own site is a member of a chorus that strangely lauds and extols the endeavour while trying to talk you out of it.

A typical dose of advice goes something like this: "go ahead and start out with a well-reviewed hosting company while you just focus on developing your site. They'll take care of all sorts of things you can't possibly do half as well – server configuration, network interruptions, a kingdom of bugs, batting away security threats of all kinds, and so on. Down the road, when you're comfortable and settled, when it's all up and running, when you've studied up, when you're ready to take on all those things yourself, then think about hosting it yourself. Even then, use caution."

Pretty daunting stuff if you lack the experience even to know what they're talking about. And they're not lying: those are all legitimate considerations.

I'm here to purport, though, that in retrospect, if I'd known just a little more about the those shadows, I would have done the opposite: started by launching my site from home, eventually considering the option of enlisting a service. I'm not asserting that's right for everyone, but I'm standing up to say it's worth really considering. So, I'll elaborate on why I think it would have been right for me.

Foremost, I love the Web. I love its openness and permissionlessness, how it suddenly changed the world, connecting everyone. As soon as was possible, I wanted to join these other inspired people, young and old, near and far, who had shown up there, having designed and built their own virtual homes. ("Look at this person's site! Look at that one! How do you make a site? How does it work?")

A mantra of mine became swiftly relevant: "if you want to create something, you learn whatever you have to learn to create it." Learning for that reason seldom feels tedious, and often feels like what you'd rather do than anything.

So, across the decades, I've loved every minute of learning to code for the Web too. I'm of the first multitude who buried themselves in HTML and CSS; and if you've done this too, you know it doesn't take long to start really creating something. As we discovered: if you dream of your own home on the Web, that's really all you need.

Except that one's home does have to live on some kind of a server, accessible to the Internet worldwide. That's what hosting is. And whether with a local hosting company, a large hosting company, a modern service like Neocities or its legendary trailblazing predecessor GeoCities, or even – at least traditionally – one's own ISP, it's never been necessary to know much about servers.

And that's the distinct upside to hosting one's own site. If you want to create your own server situation, you learn whatever you need to, and you end up knowing something about servers. Not everything, in the same way you won't know everything about HTML and CSS after writing ten or even a hundred sites. But you'll have some working knowledge rather than none.

The feeling that I distinctly lacked this knowledge swelled when I noticed, well past a decade into my Web presence, that I still wasn't even sure exactly what a server was! I knew the role it played in making sites available to the world, and I thought I knew it was some sort of computer. But I had these images of special, purpose-built computers, perhaps shaped as alien-looking blocks with lights, that ordinary people, even computer geeks, wouldn't be likely to see or access. I'd never found myself near a situation where I, or anyone I knew, would have to look for one, buy or sell one. I wasn't sure who made them. And since Web enthusiasts, even certifiable nerds, usually don't have to know much about them, I fear this marked imbalance of knowledge is typical.

The most basic and most important fact, stated here for anyone else to whom it has not been conveyed, is: a server is any ordinary computer. Like the last notebook computer you saw, for example. Or even the old beigish PC tower you noted in someone's garage the other week. The server providing this site for you, as of two years ago, is a 14-year-old Mac mini sitting quietly a few metres away. Yes, companies that run ten million sites do hoard specialized, higher-powered, geometrically primitive computers optimized for the purpose, but even those, grandiose traits aside, are just computers.

So, how does a regular computer make a Web site available to the whole world? Isn't that some kind of priviliged wizardry similarly off-limits to everyday people? Again: not at all. In a sentence: it's just an app. We use apps every day that send and receive data – messages, social network posts, audio calls – and visiting a Web site is simply another case of sending and receiving data.

So, a "server" in the hardware sense is just a computer, and a "server" in the software sense is just an app. It's that simple.

To many, I'm sure these last paragraphs are eye-rollingly obvious. The point is that for me and others, they're genuinely new and critical information. They illustrate the extent to which even true Web enthusiasts can miss the basics. And if you're considering hosting your own site, this is where you must start.

Naturally, there is more detail to be uncovered on this point, and I won't lean much further into that here. (One might ask next: a server is just an app? So, which app is it? Predictably, there are options, but those are readily looked up. The important thing is that the question is now apparent.)

The next most relevant concepts I'll wade briefly into – and if you've never hosted your own site, this is where you start to feel you're really learning something – pertain to what happens between the moment someone types your Web address into a browser, and the moment your server app receives a request for your site. Domain name servers, which tell browsers where Web addresses point, play the same role whether your Web address points to a hosting service or a home computer. But when a visitor's request travels inward through your modem and arrives at your router, the router must pass it to your computer, and your server app must notice and receive it. But your router can have dozens of connected devices… so how the heck is it supposed to know it's meant to pass an unsolicited piece of incoming data, not formerly associated with any particular app, to a particular computer?

Well: when we set up a router, we're used to providing a network name and a password, then plonking it down and forgetting it. During that setup, we might notice an arcane maze of other settings lurking behind those, perhaps accompanied by a sneaking sense of dread and hope we never have to deal with them. It turns out situations like "when you receive an incoming request for a Web site, pass it to this particular computer" is exactly what those settings are for! At this point, you'll likely meet the term "ports" – virtual channels meant for different types of data, including Web requests. And whichever server app you wind up choosing, one of its main functions is to stay quiet and listen for requests on the appropriate port. And so, the basic picture of a complete circuit, all the way from some visitor's browser across the world and back, takes shape.

Even if you don't know from experience, you can probably tell I'm still sticking to basic concepts, and you'd be justified in believing this must be trickier to do than to read about here. Navigating even a few router settings is initially an unfamiliar task. But I want to point out that, especially for one whose heart and brain are in it, it is a small task. Once you've completed the task and look back on it, you'll realize it's barely a more daunting technical task than any other which requires a little learning.

Beyond that point? Admittedly, there still exists that remaining list of concerns usually addressed by hosting providers. What happens when your home suffers a five-minute power outage? Well, unless you've equipped yourself with alternate power for your devices, your site goes offline for five minutes. What happens when someone decides to write a mischievous program that sends ten thousand requests in three minutes for your featured 13-megabyte animated GIF of the prophecy cat? Is someone from your ISP going to be calling you? The serving of your site is simply the app accessing and handing out files you place on your computer's own hard drive – what if you somehow accidentally give it with the ability to reach just outside your site directory and send that text file with all your bank account numbers? Is that even possible, or just something you thought you read somewhere? Again, I'll back away from details here, but reaffirm the point that these are all legitimate questions with real answers, and that the exercise will prompt you to think and learn about them rather than carry on oblivious to them.

To me, this exercise has fallen squarely within the same category of exciting, rewarding, creativity-centric learning as digging around in HTML and CSS does. If you've read to this point, you may already grasp why I now believe that even if I had still relied on a hosting service for the majority of my own site's history, I ought to have begun by acquiring this practical experience. Then, should I have chosen to move to a hosting service, I'd have spent these intervening years actually appreciating the variety of tasks they handle, regarding their work not as a matter of blind trust around something I barely comprehend, but as something I do comprehend and have delegated to them.

So that's why, to someone who's thinking today about hosting their own site, I would suggest really considering the option of trying it sooner than later. Yes, don some humility as you begin, and yes, proceed knowing mistakes are possible. You're embarking at least partway along the path from beginner to expert in a new area. There's risk in any such self-improvement. You might hit a snag or learn the odd lesson the hard way, but you won't set something on fire or blow up a motel or anything. You can work all the way up to opening your front door and still turn back if you decide it's not for you. So don't let the possibility of mistakes frighten you out of trying.

As a final point: hosting one's own site from home just feels right – which in my case, after all, I refer to as my "Web home." The earliest and most revolutionary accomplishment of the Web, after all, is to connect individuals from anywhere. When you call someone at home, their phone rings at their home. When you sit at home to virtually visit someone on the Web, the connection ought to form between your home and theirs. That was a scheme envisioned alongside the Web originally, tragically obscure and esoteric today. But the Web is an enduring champion because even its most forgotten capacities remain for anyone to pick right back up.