Inside Enersys’s CI/CD Pipeline — From Git Push to Live Website in 5 Minutes

Why share our own pipeline?

When we talk to clients about CI/CD, the question we hear most often is: "So what do you use yourselves?"

We believe the best way to prove expertise is to show that we use the same practices we recommend. This article takes you behind the scenes of the actual pipeline that delivers enersys.co.th — from a developer’s push all the way to a live website.

Overview: From code to production

Our pipeline is split into 2 main paths, each triggered by a different event:

1. PR Validation — every time a Pull Request is opened, the system builds and tests automatically
2. Release & Deploy — when a new version tag is created, the system builds, pushes, and deploys to production

Both pipelines run on a self-hosted runner installed on our own Ubuntu machine — not a GitHub-hosted runner that has to provision a fresh VM every time.

Path 1: PR Validation

Whenever a developer opens a Pull Request, 2 workflows run in parallel:

Build Validation

The first workflow checks whether both Docker images (Web and API) can build successfully — but does not push them to the registry. It is a safeguard to confirm that new code does not break the build.

What makes this effective is our use of Docker Buildx cache stored on the self-hosted runner. On subsequent builds, unchanged layers are skipped immediately, reducing builds that would normally take minutes to just seconds.

Lighthouse Performance Audit

The second workflow is more rigorous — it builds the full website and actually serves it on localhost in order to run Lighthouse audits 3 times.

Required thresholds:

• Performance ≥ 60% — anything lower causes the PR to fail immediately
• Accessibility ≥ 80% — accessibility matters to us
• SEO ≥ 80% — the site must be ready for search engines
• Best Practices ≥ 80% — baseline quality standards

The results are stored as artifacts for 30 days, allowing us to track how performance changes across PRs.

Path 2: Release & Deploy

Once a PR has been reviewed and merged, the next step is to create a version tag such as v1.1.178 — this is the trigger that sets everything in motion:

Step 1: Docker multi-stage build

The core of our pipeline is the Docker multi-stage build — a technique that keeps production images as small and secure as possible:

Web Frontend (3 stages):

The first stage installs all dependencies required for the monorepo. The second stage runs the build to export the site as static HTML/CSS/JS. The final stage is the actual production image — Nginx Alpine serving only static files with no Node.js, no source code, and no unnecessary dependencies.

The result is an image of roughly 22 MB — lightweight and fast.

API Backend (2 stages):

The first stage compiles TypeScript into JavaScript and generates the Prisma Client. The final stage keeps only the compiled code, Prisma Client, and production dependencies — removing dev dependencies, source code, and build tools entirely.

Step 2: Push to container registry

Both images are pushed to DigitalOcean Container Registry with 2 tags:

• A version-specific tag such as v1.1.178 — for rollback if needed
• The latest tag — for current reference

Step 3: Kubernetes deployment

The pipeline handles Kubernetes end to end:

Secrets & Configuration — secrets are created for the database connection and various API keys (Mailgun, LINE Messaging, Google Forms). Everything is managed through GitHub Secrets, and no sensitive value is hardcoded.

Rolling Update — Kubernetes replaces pods gradually, one at a time:

• A new pod starts and waits until the readiness probe passes (checking /healthz every 5 seconds)
• Once the new pod is ready, traffic is redirected
• The old pod is drained gracefully
• There is zero downtime

Step 4: Autopublish

After a successful deployment, the pipeline commits the updated Kubernetes manifest back to main, ensuring the Git repository always remains the single source of truth. By inspecting the manifest, we can see exactly what production is running and which version is live.