From Zero to Live Server: A Beginner's Log of Setting Up ConnectedAlly's Hosting

I'm not a developer by trade, or at least I didn't think I was. I'm a Paralympic swimmer who's slowly teaching myself the tech side of building a business. Today was one of those days where I went in expecting to tick off one small task and came out having learned an entire new layer of how websites actually work. Here's what happened, in plain English, for anyone else starting from scratch.

Step 1: Getting a server of my own (the KVM)

Everything starts with having somewhere for your website to actually live. KVM with Hostinger Unlike basic shared hosting, this gives me a proper Linux server to configure exactly how I want it which matters because ConnectedAlly isn't just a static website, it's going to run automation and other tools alongside it.

Beginner takeaway: a VPS/KVM is like renting an empty apartment instead of a furnished room. More freedom, but you have to bring (and build) your own furniture.

Step 2: Deploying the site through the terminal

Next, I connected to that server using the terminal, the text-based command line, rather than clicking around a visual interface.

Beginner takeaway: the terminal looks scary, but it's really just typing instructions instead of clicking buttons. Once you've done it a few times, it becomes second nature, and it's often faster than the alternative.

Step 3: Connecting it all to GitHub via VS Code

Rather than editing files directly on the live server (a recipe for disaster if something goes wrong), I pushed everything to GitHub straight from VS Code, my code editor. GitHub acts as a safe, version-controlled home for all my code; every change is tracked, nothing is ever truly lost, and I can pull the latest version onto the server whenever I'm ready to update it.

Beginner takeaway: think of GitHub as a save-file system for your whole project. If you break something, you can always go back.

Step 4: Discovering Docker containers

This is where the day took an unexpected turn. What started as "just get the site live" expanded into learning about Docker containers. A container is essentially a self-contained little box that runs one piece of your system the website, the automation tool, the blog completely separately from the others.

Why does that matter? Because it means:

• If I need to update or fix one part (say, the blog), I'm not risking breaking the main site.
• Everything stays organized instead of turning into one tangled mess on the server.
• I can edit and experiment with individual pieces without fear of taking the whole thing down.

Beginner takeaway: Docker containers are like keeping your website, your automation, and your blog in separate, labeled boxes instead of throwing everything into one drawer.

Why this matters for ConnectedAlly

None of this is glamorous; there's no pretty new feature to show off yet. But this is the plumbing that everything else gets built on top of. ConnectedAlly is about helping people feel confident with tech and stay safe online, and I figured the best way to build credibility in that space is to actually go through the learning curve myself: server setup, terminal commands, version control, containerization, the lot.

If you're a beginner reading this and it all sounds like a foreign language, that was me this morning too. The best way through it, I'm finding, is just to do the next step in front of you and let the concepts click into place as you go.

More updates soon as the ConnectedAlly build continues.