I'm Not a Developer. I Built an Automated Deployment Pipeline Anyway.

Two late nights, forty error messages, one hosting support setting, and the most satisfying green checkmark of my life.

I want to tell you about the dumbest bottleneck in my business, and the two nights I spent killing it.

I run a one-man marketing agency. I build websites, I write blog content, I manage campaigns. And for years, every time I updated my own website, I did it the same way: log into cPanel, open File Manager, click upload, pick a file, wait, click upload again, pick the next file, wait again.

One. File. At. A. Time.

If I updated ten blog pages, that was ten uploads. If I fixed a typo, that was another login, another upload. It worked, but it was the kind of work that makes you avoid doing the work. I'd finish writing a post and then think, "I'll upload it tomorrow." Tomorrow became next week. You know how that goes.

The Question That Started It

So one night I asked my AI assistant a simple question: "Is it possible to give you access to my cPanel?"

The answer was no — and honestly, it should be no. Nobody should be handing their hosting credentials to anything. But the conversation didn't end there. It turned into: what if your website updated itself every time you saved your work?

That's a real thing. Developers call it a deployment pipeline. Big companies have entire teams for this. I had me, a Windows laptop, and a stubborn streak.

Here's the idea in plain English: your website files live in a folder called a repository on GitHub. When you change a file and "push" it, GitHub notices and automatically copies your files to your web server over a secure connection. No File Manager. No clicking. You save, you push, it's live.

Sounded simple. It was not simple. But it was worth it, and I want to walk you through what actually happened — including the parts where I wanted to throw my laptop into the lake.

Night One: Learning Git the Hard Way

First, I had to install Git — the tool that tracks file changes and talks to GitHub. I had never used it. Within the first hour I had typed get instead of git, typed =m instead of -m, and gotten lost between three different terminals that all looked the same but apparently weren't.

At one point I typed a command in the wrong folder and the computer told me, essentially, "there's no such thing here." I didn't know you had to be standing in the right folder for the commands to work. Nobody tells you that. Now I know.

But here's the thing — within a couple hours, my entire blog was on GitHub with version control. Every file, every change, backed up and tracked. That part alone was worth the evening. If my server caught fire tomorrow, my whole site lives somewhere safe.

Then Came the SSH Keys

For GitHub to upload files to my server automatically, it needs to prove it's allowed in. That's done with SSH keys — a matched pair of files, one public, one private. The public key sits on your server like a lock. The private key is the only key that opens it.

Simple concept. Brutal execution.

My first key was in the wrong format. Generated a new one — also the wrong format. Downloaded one from cPanel — it came out in PuTTY format, which is a third format that nothing I was using wanted. I generated keys on the server, keys on my laptop, keys in formats I didn't know existed. The error message error in libcrypto is now permanently burned into my brain.

By the end of night one, nothing was deploying. The workflow ran and failed, ran and failed. Permission denied, over and over. I said good night, honestly a little defeated, and went to bed.

The Hidden Switch

Here's where the story turns. The next day, I contacted my hosting company, and it turned out SSH had never been fully enabled on my account. They flipped it on. Progress! I came back that evening ready for the victory lap.

Still failed.

But this time the error message changed — and that mattered. Instead of rejecting my key, the server let me in and then said: "Shell access is not enabled on your account." Different problem. The key worked. The door opened. There was just another locked door behind it.

And here's my favorite part of the whole saga: I found the switch myself. Digging around my hosting control panel, I found the account settings, toggled shell access off and back on to force it to take, and ran the test one more time:

CONNECTED. One word on a black screen. I have closed six-figure deals that felt less satisfying than that one word.

The Last Two Bugs

Almost done — but not quite. Two more gremlins showed up.

First, the key I pasted into GitHub didn't match the key that worked on my laptop. Copying multi-line text out of a terminal window had mangled it. The fix was one command that copies the file straight to the clipboard, byte for byte, no human hands involved. Fingerprints matched after that.

Second, the workflow was looking for a folder called blog inside my repository — but my repository was the blog. One path fix later, I pushed one more time and watched the screen.

Green checkmark. Ten seconds. Deployed.

I pushed a test change just to watch it happen again. Ten seconds. Live on the internet. I may have said "wow" out loud to an empty room.

What My Workflow Looks Like Now

Today, publishing to my website looks like this:

1. Drop the new or updated files into my blog folder
2. Type three commands: git add . then git commit -m "New post" then git push
3. Wait about ten seconds

That's it. That's the whole thing. No cPanel. No File Manager. No uploading files one at a time like it's 2009. Ten pages or one page — same three commands, same ten seconds.

As a bonus, every version of every file is saved forever. If I break something, I can roll back. If my laptop dies, nothing is lost.

What I'd Tell Another Business Owner

You don't need to be a developer. I'm not. I needed patience, an AI assistant that could explain every step and every error message, and the willingness to keep pasting error text and asking "okay, now what does THIS mean?"

The errors are the process. I hit somewhere north of forty of them across two nights. Every single one meant something specific, and every single one had a fix. Wrong key format. Password-protected key. Shell access disabled. Corrupted paste. Wrong folder path. None of them were dead ends — they just felt like it at 2 AM.

Some problems are one phone call. The biggest blocker of the entire project wasn't technical skill. It was a setting my hosting company had to enable. If you get stuck on "permission denied" errors forever, ask your host about SSH and shell access before you spend another night fighting key formats.

Test locally before you automate. The turning point was testing the SSH key from my own laptop first. Once that one-line test printed CONNECTED, I knew the key was good, and every remaining problem had to be somewhere else. Cut the search area in half.

The payoff compounds. This wasn't about saving ten minutes on one upload. It's about removing the friction that made me delay publishing. The bottleneck wasn't the upload — it was that I dreaded the upload. That dread is gone now.

One Task at a Time

Funny enough, the last article I published — uploaded through this very pipeline — was about how AI won't replace most jobs, it'll rewrite them one task at a time.

This was one of my tasks. It just got rewritten.

I still write the content. I still make the decisions. I still had to find that shell access switch myself. But the repetitive, mind-numbing part of publishing — the part that added zero value and drained real energy — is now handled by a robot in ten seconds.

One task down. Plenty more to go.