DEV Community: Jesse James Kyemting

Engineering a CI/CD Pipeline with GitHub Actions and AWS EC2 published

Jesse James Kyemting — Tue, 30 Jun 2026 17:07:47 +0000

Introduction

As developers and infrastructure engineers, we strive to eliminate repetitive manual tasks. When it came time to host my interactive, terminal-themed portfolio website, running manual file transfers or standard SSH updates felt like a missed architectural opportunity.

I wanted a modern engineering workflow: write code locally, push to a remote repository, and let automated pipelines handle the heavy lifting.

Here is a comprehensive technical breakdown of how I designed and engineered a lean Continuous Deployment (CD) pipeline utilizing GitHub Actions and an AWS EC2 infrastructure, along with the real-world debugging lessons I learned along the way.

🔗 Check out the complete codebase and workflow configurations on GitHub.

The Architectural Blueprint

The pipeline is built on an automated, event-driven loop that links a local development environment to an active production server in the cloud:


mermaid
graph LR
    Dev[\"💻 Local Workspace (WSL)"/] -- git push --> Repo[("(fa:fa-github) GitHub Remote Repo")]
    Repo ==> Trigger{{"⚡ Workflow Runner Trigger"}}
    GHA[["🔧 job: deploy_site"]] --- Secrets[/"🔑 GitHub Encrypted Secrets"\]
    Trigger --> GHA
    GHA -- Secure SSH Tunnel --> EC2["🐧 AWS EC2 Ubuntu Instance"]
    EC2 -- git fetch & hard reset --> App[/"📁 Apache Root (/var/www/html)"/]
    App == Deployment Status 200 OK ==> Web(("🌐 Production Live Site"))

    style Dev fill:#eceff1,stroke:#37474f,stroke-width:2px
    style Repo fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style Trigger fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style GHA fill:#ede7f6,stroke:#5e35b1,stroke-width:2px
    style Secrets fill:#ffebee,stroke:#c62828,stroke-width:1px,stroke-dasharray: 5 5
    style EC2 fill:#efebe9,stroke:#4e342e,stroke-width:2px
    style App fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    style Web fill:#e8f8f5,stroke:#117a65,stroke-width:3px

What Cloud Computing Actually Does (And Why My Bootcamp Almost Had a Fight Over It)

Jesse James Kyemting — Sat, 27 Jun 2026 10:25:20 +0000

Nobody told us the first week of bootcamp would include a three-way argument about whose track matters most.
At SkillNg, we had separate specialists come in for frontend, backend, and cloud computing/DevOps. Each one opened their session the same way: introducing the track, explaining why it matters, and taking at least one shot at the others. It was funny at first. Then it turned into an actual debate.
The frontend dev made the case that the user interface is everything. If something looks broken or feels slow, users leave. Does not matter what is happening underneath. The backend dev fired back that a beautiful interface with no data, no logic, and no API is just a static webpage. Then both of them turned to the cloud computing instructor and asked, more or less, what we actually do.
He did not bite. He just said:

"No matter how good your creation is, you cannot render it in thin air. You need somewhere to save it, run it, and deliver it to people. That is where cloud computing comes in."
The room went quiet. That was the end of the debate.
I have been thinking about that moment since, mostly because I think a lot of people starting out in tech have the same question. Cloud sounds abstract. Infrastructure sounds boring. So what does it actually mean in practice?

The honest answer is that cloud is what makes code a product
Frontend and backend are about building. Cloud is about what happens after you build. You can write the cleanest React components in the world. You can design an API that handles every edge case. But if that code only runs on your laptop, it does not exist for anyone else. Cloud infrastructure is what closes that gap: the servers, the networking, the storage, the pipelines that take your build and put it somewhere the internet can reach. A simple way to think about it: frontend is the shop floor, backend is the warehouse, and cloud is the building itself, plus the electricity and the loading dock.

What cloud engineers actually work on
Deployment. Someone has to configure where the application runs and how it gets there. Cloud engineers set up the environments, the containers, the compute resources. When a developer pushes code, it does not magically appear in production. Something has to receive it, test it, build it, and ship it. That something is what cloud and DevOps people build.

Scaling. Imagine your app gets picked up by a newsletter with a large audience and 10,000 people hit it at once. A server with fixed capacity buckles. Cloud infrastructure with auto-scaling spins up additional instances automatically to absorb the load, then scales back down when things settle. No one has to manually intervene at 2 am. That kind of reliability does not come free; someone has to design and configure it.

Storage and databases. The backend developer writes queries. But where does the database live? Who makes sure it does not go down, that the data is backed up, that it can be read from multiple regions without becoming a bottleneck? Cloud engineers do. Services like AWS RDS or Google Cloud Storage handle this, but they still need to be provisioned, secured, and maintained properly.

CI/CD pipelines. This is where DevOps earns its name. A CI/CD pipeline automatically runs your test suite, builds the application, and deploys it whenever new code is pushed. Without this, teams are copying files to servers by hand, which is slow and breaks often. With it, you can ship ten times a day and catch problems before they reach users.

Security at the infrastructure level. A backend developer secures their API. A cloud engineer secures what the API runs on: the firewalls, access policies, SSL certificates, network configuration, and compliance requirements. These are different jobs. Both matter.
Cost. Before cloud computing, companies bought physical servers upfront and hoped they sized them right. Too small and the app crashes under load. Too large and you are paying for capacity you will never use. Cloud's pay-per-use model changed that. You pay for what you actually consume, and you can adjust in real time.

The thing both sides missed in the debate
Frontend and backend developers use cloud infrastructure constantly without thinking about it. GitHub is cloud. The npm registry is cloud. Every third-party API they call in their apps runs on cloud servers somewhere. They were arguing against the foundation they were standing on.
That is not a knock on them. It is just how infrastructure works when it is done well: invisible. Nobody thinks about electricity until it goes out. Cloud is not competing with the other disciplines. It is the layer that makes them matter outside of a development environment. A good frontend and a solid backend are prerequisites for a good product. Cloud is what determines whether that product actually reaches anyone.

Where I am now
I am still early in the SkillNg program, and this is clearly the beginning of a long learning curve. AWS alone has more services than I can keep track of right now. But that first session reframed how I think about what we are learning. If you are starting out and trying to choose a track, I would not recommend choosing based on which one sounds most impressive. Choose based on what kind of problems you want to spend your time solving. If the idea of owning the infrastructure that everything else depends on sounds interesting, cloud is worth a serious look.

And the next time someone asks what cloud engineers do, you have an answer.

Cloud Computing vs. Traditional IT: The Great Shift

Jesse James Kyemting — Mon, 20 Apr 2026 11:37:53 +0000

When I got the news that I'd been selected for a cloud engineering boot camp here in Lagos, two things happened simultaneously: I was excited, and immediately convinced I had no business being there.

You see, I come from a different corner of tech. I'm a Salesforce Consultant with certifications in Administration and CPQ. I train AI models on platforms like Appen and Remotasks. I do data analysis in Excel and Power BI. These are not nothing but infrastructure? The cloud? That felt like someone else's territory.

A few sessions in, I'm realising that everything I've already done sits on top of exactly what we're now learning to build. That reframe matters. This article is my attempt to lay out the foundational shift clearly, for myself as much as anyone reading this.

The era of physical data centres
Not too long ago, if a company wanted to run software, it had to own the machines that ran it. That meant buying servers, racking them in a dedicated room or an entire building, hiring engineers to maintain them, and hoping nothing failed at the wrong moment. This was Traditional IT, and for decades, it was simply the cost of doing business with technology.

The model had a certain logic to it. You owned your hardware, so you controlled your environment. But control came with a heavy price: capital expenditure was enormous, scaling up took months of procurement and installation, and scaling down was basically impossible. You couldn't un-buy a server. Resources sat idle during quiet periods and buckled under sudden demand spikes.

Think about what this meant for businesses in a market like Nigeria, where infrastructure investment is already a significant barrier. Building and maintaining your own data centre was not just expensive; for most organisations, it was simply not viable. Tech had a ceiling, and the ceiling was physical.

"We need more capacity" used to mean: raise a purchase order, wait weeks for delivery, find a rack, configure the machine. By then, the moment had often passed.

Enter the cloud: computing as a utility
Cloud computing flips that model entirely. Instead of owning hardware, you rent capacity from a provider (AWS, Microsoft Azure, Google Cloud) over the internet, paying only for what you actually use. Need a server for one hour? Pay for one hour. Need a thousand servers for a product launch weekend? Spin them up, use them, shut them down.
The NIST definition describes it as the on-demand delivery of IT resources via the internet with pay-as-you-go pricing. Practically speaking, infrastructure became a service, not an asset.
There are three service models worth knowing. IaaS (Infrastructure as a Service) gives you raw virtual machines and storage. PaaS (Platform as a Service) adds a managed layer so you can focus on code, not servers. SaaS (Software as a Service) delivers finished applications entirely managed by the provider, which, as a Salesforce Consultant, is actually the layer I've been living in for years without fully realising it.

Why businesses, especially in Nigeria, are making the move
A concrete competitive advantage drives the migration from on-premise to cloud, and the case is even sharper in markets like Nigeria, where the cost and unreliability of physical infrastructure have historically held businesses back.
Speed of innovation. In the old model, launching a new product required procuring infrastructure first. In the cloud, a developer can provision a fully configured environment in minutes. The feedback loop between idea and production shrinks from months to days, which is critical for Lagos-based startups competing at global speed.
Elasticity. Cloud resources scale with demand. A fintech startup that gets featured on a major platform doesn't need to have anticipated that traffic spike six months in advance. The infrastructure grows and shrinks with the workload.
Cost efficiency. Capital expenditure shifts to operational expenditure. Organisations stop paying for idle capacity. For businesses operating with leaner budgets, this is genuinely transformational.
Global reach. Deploying infrastructure closer to your users used to require owning hardware in multiple countries. Now it is a configuration choice. Nigerian companies can serve international customers without international offices.
Reliability. Major cloud platforms offer 99.9%+ uptime SLAs with built-in redundancy. That kind of resilience, built from scratch on owned hardware, would be prohibitively expensive for most organisations.

The DevOps connection: where my background suddenly makes sense
Here's what clicked for me during the first session: the cloud doesn't just change where computing happens; it changes how teams work. And that's the DevOps conversation.
DevOps breaks down the wall between software development (Dev) and IT operations (Ops), with the goal of building, testing, and releasing software faster and more reliably. Traditionally, developers wrote code and handed it to operations teams to deploy, a slow, manual, often broken process.
The cloud makes DevOps natural. When infrastructure can be defined as code, provisioned through an API, and torn down after a test, automation becomes the default. CI/CD pipelines that build, test, and deploy code automatically run on cloud infrastructure. This is what makes continuous delivery real rather than theoretical.
And here's the part I keep thinking about: every tool I've already worked with (Salesforce, Power BI, the AI annotation platforms) runs on this infrastructure. The cloud isn't something separate from what I've been doing. It's the foundation underneath it. Learning to work at that layer doesn't make my previous experience irrelevant; it makes it legible in a new way.

The cloud is not the destination. It's the infrastructure that makes the destination, fast, automated, collaborative software delivery, actually reachable.

The shift is still happening, and so am I

Traditional IT isn't dead. Many enterprises still run workloads on-premise, and hybrid architectures are common. But the direction is clear. Cloud computing has become the dominant model for modern software infrastructure, and the Lagos tech ecosystem, from fintech to healthtech to the growing DevOps talent base, is building directly on top of it.
The imposter syndrome hasn't fully left. But it's quieter now that I understand what I'm actually learning and why it connects to everything I've already done. I'm not starting from zero. I'm going deeper.
Six months from now, I'll have a lot more to say about this. For now, this is where I'm starting.