How I Built My Own CI/CD Pipeline for a Small Project (Because GitHub Said “No”)

Why I Ditched GitHub Actions

So long story short no one wants to make systems of their own and why should we there are great minds who have devoted years in perfecting it. Like most developers, my first instinct for CI/CD was to use GitHub Actions—it’s built-in, well-documented, and mostly reliable. Until it wasn’t.

For some unknown reason, my GitHub Actions got blocked. I submitted a support ticket, and after a quick look at GitHub’s response time (which was somewhere between a month and eternity), I knew I had to find another solution.

Waiting wasn’t an option. I needed continuous deployment now, (ego issues) not when GitHub finally decides to reply to my ticket.

So, I did what any frustrated developer would do—I built my own custom CI/CD pipeline from scratch.

Step 1: Setting Up My Own CI/CD Server

Since GitHub wasn’t going to help me, I set up a self-hosted deployment server using Express.js.

The goal was simple:

• Whenever I push new code to my repository, my server should detect it.
• It should pull the latest code, restart the app, and send me a notification if something fails.
• No manual intervention. Just push and deploy. (and flex about pusing to production)

Sounds simple, right? It wasn’t.

Step 2: GitHub Webhooks

After some research, I discovered that GitHub provides webhooks, which can notify a server whenever specific events occur (like a push to the main branch or a pull request).

Setting Up the Webhook Listener

GitHub provides webhooks that trigger events whenever something happens in a repository, like pushing code, creating a pull request, or merging branches. My goal was to create a webhook that listens for a push event on the main branch, automatically pulling the latest code and redeploying the app.

First, I created a simple Express.js server and added an endpoint to listen for webhook events

Signature Verification Nightmare

If you think setting up a webhook is as easy as “just writing an endpoint,” let me save you some pain: GitHub doesn’t trust you.

Every webhook request from GitHub is signed using a secret key, and your server must verify this signature to ensure it’s a legitimate request.

Sounds simple? Not when the signature verification keeps failing.

For the next several hours, I tried everything:

• Manually comparing signatures (they never matched).
• Re-reading GitHub’s docs (which didn’t help).
• Trying different hashing methods (none worked).

At one point, I even considered disabling verification entirely—which is a terrible idea unless you enjoy waking up to your server being hijacked.

Finally, after digging through GitHub issues, I realized my mistake:

• I wasn’t using the exact raw body of the request for signature validation.
• Instead, I was verifying the JSON-parsed body, which modifies the data slightly, causing the signature to mismatch.

A few painful adjustments later, my signature verification finally passed.

Automating the Deployment Process

With the webhook working, I automated the deployment with a series of commands:

1. Pull the latest code from the main branch of the repository
2. Install dependencies (if any new one was added)
3. Rebuild the project
4. Restart the server process to apply changes

With this setup, every time I pushed code to GitHub, my server automatically updated itself. No manual pulling, no SSH logins—just smooth, hands-free deployment.

Step 3: Email Notifications with Resend

I wanted immediate feedback if something went wrong, so I integrated Resend, a powerful email API.

Now, after every deployment, I get an email saying either:

• ✅ Deployment Successful – Life is good.
• ❌ Deployment Failed – Something broke, and I need to fix it ASAP.

This turned out to be one of the most useful parts of the setup because it meant I didn’t have to check manually whether deployments were working.

Lessons Learned (Or, What I’d Do Differently)

Building a custom CI/CD pipeline was an exciting journey, but it also came with its fair share of facepalm moments. Here’s what I took away from this experience and what I’d change next time.

1. A CI/CD Pipeline Is a Game Changer

Before this, I used to manually SSH into my server, pull updates, restart processes, and pray nothing broke. With this setup, deployments happen automatically, saving time and reducing human error. But what really hit me was how much mental overhead it removed—no more worrying about forgetting a step or accidentally deploying a broken commit.

That being said, there’s still a critical issue I didn’t expect and figured out while writing this post…

2. No Rollback Mechanism = Potential Disaster

As much as I love automation, it comes with a huge risk: what happens when a deployment fails and breaks the entire server? Right now, my setup blindly pulls the latest code and restarts the app. If there’s a fatal bug in the pushed code, the app crashes, and boom—downtime.

What I should have done:

• Implement a rollback system: If deployment fails, revert to the last working commit instead of leaving the server broken.
• Use a blue-green deployment approach: Deploy to a separate instance first, verify stability, and only then switch traffic over (maybe I will not go with this because I am a solo developer).

Next on my list is building a rollback mechanism that can detect failed deployments and automatically restore the last working version—because nothing’s worse than waking up to “Hey, your site is down.”

Conclusion

While most people rely on GitHub Actions, it’s not the only way to do CI/CD. Having a custom deployment pipeline gives you more control, fewer limitations, and zero dependencies on external services.

Sure, it took some effort to set up, but now I can deploy changes automatically and reliably—without waiting for GitHub support to wake up.

And while I figure out how to build a custom monitoring system, at least I have CI/CD fully automated.