CI/CD with GitHub Actions

April 18, 2026

In my current role, I’ve been focused on modernizing our internal deployment workflows by implementing a CI/CD pipeline across our infrastructure. The goal was to reduce manual deployment steps, increase reliability, and standardize how applications are built and deployed across multiple environments, including staging and production.

GitHub Actions

The first step in this effort was securing a GitHub Enterprise license on our common platform to enable centralized source control and CI/CD capabilities through GitHub Actions.

Self-Hosted Runners

Rather than relying on GitHub-hosted runners, I implemented self-hosted GitHub runners directly on our infrastructure. This decision was driven by the need to deploy into internal systems that are not publicly exposed.

GitHub-hosted runners are primarily designed for cloud-native workflows. In our case, we needed to deploy into internal systems. Self-hosted runners allowed us to bring CI execution directly inside each server’s network boundary.

This provided several key advantages:

• Direct deployment into staging and production environments without exposing internal infrastructure

• Elimination of external SSH-based deployment orchestration simplifying deployment scripts.

Instead of GitHub orchestrating deployments remotely, each server independently executes its own CI/CD jobs.

Pipeline 1: Vite Application Deployment to Apache

One of the first pipelines implemented automates the optional build and deployment of a Vite-based frontend application.

The workflow supports both staging and production environments:

• A push or merge triggers the pipeline

• The Vite project is installed and built on the appropriate runner

• Static assets are generated

• Output is deployed to either staging or production

Pipeline 2: Node.js Application Behind a Reverse Proxy

We also maintain a Node.js application running behind a reverse proxy, with separate staging and production environments.

In our architecture, the Apache layer acts as the entry point and is configured as a reverse proxy that routes requests to the Node.js application servers. This allows us to keep Node.js services isolated while still exposing them through a unified web layer.

The CI/CD pipeline handles:

• Dependency installation

• Application build and packaging

• Deployment to the Node.js environment

Outcome

With this CI/CD architecture in place, deployments are now fully automated across both staging and production environments for multiple application types and hosting models.

What previously required manual server access and coordination is now handled through version-controlled pipelines executing directly on each target system.

This setup has significantly improved deployment reliability, reduced operational overhead, and created a scalable foundation for future applications across sites, WordPress infrastructure, and Node.js applications.