# Kaneo CI/CD Pipelines Explained: GitHub Actions, Docker & Helm Workflows

> Discover Kaneo CI/CD pipelines powered by GitHub Actions. Automate linting, testing, Docker builds, and Helm deployments with three core workflow files.

- Repository: [kaneo.app/kaneo](https://github.com/usekaneo/kaneo)
- Tags: how-to-guide
- Published: 2026-08-10

---

**Kaneo uses GitHub Actions as its CI/CD platform with three workflow files—[`ci.yml`](https://github.com/usekaneo/kaneo/blob/main/ci.yml), [`docker.yml`](https://github.com/usekaneo/kaneo/blob/main/docker.yml), and [`helm-chart.yml`](https://github.com/usekaneo/kaneo/blob/main/helm-chart.yml)—that automate linting, type checking, testing, building, containerization, and Kubernetes deployment packaging on every push, pull request, or manual trigger.**

Kaneo's continuous integration and continuous deployment setup is orchestrated entirely through GitHub Actions. The `usekaneo/kaneo` repository defines its automation in `.github/workflows/`, leveraging a pnpm-based monorepo structure with Node.js 20.20.2 and Ubuntu 24.04 runners. This article breaks down each pipeline job, its purpose, and how the workflows interconnect to deliver production-ready artifacts.

## Core CI Workflow: [`.github/workflows/ci.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/ci.yml)

The primary CI pipeline lives in [`.github/workflows/ci.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/ci.yml) and executes five parallel jobs on every trigger. Each job follows a standardized setup pattern before running its specific validation step.

### Job 1: Lint (Biome)

**Purpose:** Enforce code style and catch syntax errors early.

```yaml

# From .github/workflows/ci.yml - line 33

- name: Run Biome lint
  run: pnpm exec biome ci .

```

The lint job uses **Biome**—a fast, Rust-based toolchain—to validate formatting and catch lint errors across the entire codebase. This runs before any compilation or testing to provide immediate feedback on code quality issues.

### Job 2: Typecheck (TypeScript)

**Purpose:** Verify type safety across all monorepo packages.

```yaml

# From .github/workflows/ci.yml - line 56

- name: Run typecheck
  run: pnpm typecheck

```

Running the TypeScript compiler in `noEmit` mode ensures type consistency without generating output files. This catches interface mismatches and generic errors that unit tests might miss.

### Job 3: Unit Tests (Vitest)

**Purpose:** Execute fast, isolated tests for individual modules.

```yaml

# From .github/workflows/ci.yml - line 79

- name: Run unit tests
  run: pnpm test

```

The unit test job spins up **Vitest** across all workspace packages. These tests avoid external dependencies like databases, providing rapid feedback on business logic correctness.

### Job 4: Build

**Purpose:** Verify that production bundles compile successfully.

```yaml

# From .github/workflows/ci.yml - line 102

- name: Run build
  run: pnpm build

```

This compiles the API, Web frontend, and documentation sites into deployable artifacts. A failing build step prevents broken deployments from reaching the release pipeline.

### Job 5: Integration Tests

**Purpose:** Validate end-to-end behavior with real database connections.

```yaml

# From .github/workflows/ci.yml - line 146

- name: Run integration tests
  run: pnpm test:integration

```

Unlike unit tests, this job requires a **PostgreSQL** service container. It exercises database queries, migrations, and API endpoints in conditions that mirror production.

## Release Workflow: [`.github/workflows/docker.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/docker.yml)

After CI passes, the Docker pipeline handles containerization. Located at [`.github/workflows/docker.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/docker.yml), this workflow:

1. **Builds** multi-platform Docker images for the API and Web services.
2. **Pushes** images to the GitHub Container Registry with semantic version tags.
3. **Triggers** the Helm chart workflow via repository dispatch.

The API and Web apps each have independent `Dockerfile` definitions in their respective package directories, enabling optimized layer caching and minimal final image sizes.

## Deployment Workflow: [`.github/workflows/helm-chart.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/helm-chart.yml)

The final stage of Kaneo's CI/CD pipeline packages Kubernetes manifests. The [`.github/workflows/helm-chart.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/helm-chart.yml) workflow:

- Lints Helm templates with `helm lint`
- Renders manifests with `helm template` for validation
- Packages the chart into a `.tgz` archive
- Publishes to GitHub Container Registry as an OCI artifact

This workflow can trigger manually or receive dispatches from the Docker pipeline, ensuring charts stay synchronized with application images.

## Shared Setup Pattern Across All Jobs

Every CI job in [`ci.yml`](https://github.com/usekaneo/kaneo/blob/main/ci.yml) uses identical initialization steps. This consistency reduces maintenance burden and ensures reproducible environments:

```yaml
steps:
  - uses: actions/checkout@v7
  
  - name: Setup pnpm
    uses: pnpm/action-setup@v6
    with:
      version: 10.32.1
  
  - name: Setup Node
    uses: actions/setup-node@v7
    with:
      node-version: 20.20.2
      cache: 'pnpm'
  
  - name: Install dependencies
    run: pnpm install --frozen-lockfile

```

The `--frozen-lockfile` flag guarantees that CI uses exact dependency versions recorded in [`pnpm-lock.yaml`](https://github.com/usekaneo/kaneo/blob/main/pnpm-lock.yaml), eliminating "works on my machine" discrepancies.

## Local Development Commands Matching CI

Run the same validation steps locally before pushing:

```bash

# Install exact dependencies (same as CI)

pnpm install --frozen-lockfile

# Lint the whole monorepo

pnpm exec biome ci .

# Type-check the TypeScript sources

pnpm typecheck

# Run all unit tests

pnpm test

# Build production bundles for API, Web, and Docs

pnpm build

# Run integration tests (requires local PostgreSQL)

pnpm test:integration

```

## Monorepo Configuration Files

The CI/CD pipeline relies on two root-level configuration files to understand workspace structure:

| File | Purpose |
|------|---------|
| [`package.json`](https://github.com/usekaneo/kaneo/blob/main/package.json) | Defines workspace scripts (`test`, `build`, `typecheck`) invoked by CI |
| [`pnpm-workspace.yaml`](https://github.com/usekaneo/kaneo/blob/main/pnpm-workspace.yaml) | Lists packages to include in the monorepo (API, Web, Docs, etc.) |

Changes to either file can affect how CI distributes work across the codebase.

## Workflow Triggers and Concurrency

The [`ci.yml`](https://github.com/usekaneo/kaneo/blob/main/ci.yml) workflow responds to:

- **Push events** to `main` and feature branches
- **Pull request** opens and updates
- **Manual dispatch** via GitHub's Actions UI

Kaneo uses concurrency controls to cancel stale runs when new commits arrive, preventing resource waste on outdated code versions.

## Summary

- **[`.github/workflows/ci.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/ci.yml)** defines five validation jobs: lint (Biome), typecheck (TypeScript), unit tests (Vitest), build, and integration tests (PostgreSQL-backed).
- **[`.github/workflows/docker.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/docker.yml)** builds and publishes container images, then triggers Helm chart updates.
- **[`.github/workflows/helm-chart.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/helm-chart.yml)** packages and publishes Kubernetes deployment artifacts to GitHub Container Registry.
- All jobs use **pnpm 10.32.1** and **Node.js 20.20.2** on **Ubuntu 24.04** with locked dependency installation.
- The pipelines enforce code quality, type safety, test coverage, build integrity, and deployment readiness before any release artifacts are generated.

## Frequently Asked Questions

### What triggers the Kaneo CI/CD pipelines?

Pushes to any branch, pull request activity, and manual workflow dispatches all trigger the CI pipeline in [`.github/workflows/ci.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/ci.yml). The Docker and Helm workflows trigger conditionally—either after successful CI completion or through manual invocation and inter-workflow dispatches.

### Does Kaneo use self-hosted runners for CI/CD?

No. According to the source code in [`.github/workflows/ci.yml`](https://github.com/usekaneo/kaneo/blob/main/.github/workflows/ci.yml), all jobs specify `runs-on: ubuntu-24.04`, which uses GitHub's hosted runners. There are no self-hosted runner configurations present in the repository.

### How does Kaneo handle database dependencies in tests?

The integration test job configures a **PostgreSQL service container** directly in the workflow file. This provides an isolated database instance that starts automatically before tests run and terminates afterward, ensuring clean state without external infrastructure dependencies.

### Can I run the full CI pipeline locally?

Partially. You can execute `pnpm install --frozen-lockfile`, `pnpm exec biome ci .`, `pnpm typecheck`, `pnpm test`, and `pnpm build` locally using the same commands as CI. However, `pnpm test:integration` requires a running PostgreSQL instance that you must provision manually, as GitHub Actions' service container syntax has no local equivalent.