GitHub Actions for Application Developers: A Practical Guide

GitHub Actions is the right CI/CD tool for most application development teams in 2026. It is deeply integrated with GitHub, requires no separate service to maintain, has excellent documentation, and the free tier covers most small-to-medium teams. Here is how to use it effectively without a DevOps background.

What GitHub Actions Actually Does

GitHub Actions runs automated workflows in response to events in your repository. The most common events: a push to a branch, a pull request being opened or updated, a schedule (cron), or a manual trigger.

Each workflow is a YAML file in .github/workflows/. When the trigger fires, GitHub spins up a fresh virtual machine (Linux, macOS, or Windows), runs your workflow steps, and tears it down. You see the results in the Actions tab of your repository.

The practical outcome: every time a developer pushes code or opens a PR, your tests run automatically, errors are caught before they reach production, and if everything passes, the code can be deployed automatically.

The Starter Workflow: Lint, Typecheck, Build

Start with a workflow that catches the most common classes of errors:

name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      - uses: pnpm/action-setup@v3
        with:
          version: 9

      - run: pnpm install --frozen-lockfile

      - run: pnpm lint
      - run: pnpm tsc --noEmit
      - run: pnpm test --passWithNoTests
      - run: pnpm build

This catches syntax errors, type errors, failing tests, and build failures on every push. The --frozen-lockfile flag ensures CI uses exactly what is in the lockfile - no silent dependency updates.

Caching Dependencies: 3-5x Faster Workflows

Without caching, every workflow run downloads and installs all your dependencies from scratch. For a project with 500 packages, this can take 2-3 minutes just for pnpm install.

With caching, the actions/setup-node action (with cache: 'pnpm') stores the pnpm global store between runs and restores it when the lockfile has not changed. Install time drops to 10-30 seconds.

The cache key is automatically derived from the lockfile hash. When you update dependencies, the cache is invalidated and rebuilt. This is correct behavior - you want fresh packages when the lockfile changes.

Secrets Management

Never hardcode API keys, database connection strings, or tokens in workflow files. GitHub provides encrypted secrets storage.

Add secrets at the repository level (Settings > Secrets and variables > Actions) or at the environment level for finer-grained control. Reference them in workflows:

- name: Deploy
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
  run: pnpm deploy

Repository secrets are available to all workflows. Environment secrets (Settings > Environments) require a deployment environment to be configured and can require manual approval before a workflow can access them - useful for production deployments.

Matrix Builds: Testing Across Multiple Configurations

Matrix builds run the same job across multiple values - different Node.js versions, different operating systems, or different test configurations.

jobs:
  test:
    strategy:
      matrix:
        node: ['18', '20', '22']
        os: [ubuntu-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: pnpm test

This runs 6 parallel jobs (3 Node versions x 2 OS). The workflow fails if any combination fails. Matrix builds are most useful for libraries that need to support multiple environments. For application code targeting a specific runtime, a single configuration is usually sufficient.

Reusable Workflows: DRY Across Multiple Repos

If you maintain multiple repositories with similar CI setups, reusable workflows let you define the workflow once and call it from multiple places.

Define a reusable workflow in one repository:

# .github/workflows/shared-ci.yml
on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: '20'
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      # ... standard steps

Call it from another repository:

jobs:
  ci:
    uses: your-org/shared-workflows/.github/workflows/shared-ci.yml@main
    with:
      node-version: '20'
    secrets: inherit

This keeps CI configuration consistent across projects without copy-paste. When you update the shared workflow, all projects using it get the update on their next run.

Deployment Workflows

A typical deployment workflow runs after CI passes on the main branch:

name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    needs: ci          # wait for CI job to pass
    runs-on: ubuntu-latest
    environment: production    # requires environment approval if configured
    steps:
      - uses: actions/checkout@v4
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - name: Deploy to server
        run: ./scripts/deploy.sh
        env:
          SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}

The needs: ci line means the deploy job only starts if the CI job succeeds. The environment: production line links to a configured GitHub environment, which can require manual approval from designated reviewers before deployment proceeds.

Cost: What You Get Free

Public repositories: unlimited Actions minutes. Private repositories: 2,000 free minutes per month on the free plan, 3,000 on Pro, more on Team and Enterprise. Minutes are charged per-minute for the runner type - Linux is cheapest, Windows is 2x, macOS is 10x.

A typical CI workflow for a small app takes 3-5 minutes per run. At 20 runs per day across a team, that is 100 minutes per day, 3,000 per month - right at the free tier limit. Add a few longer jobs or more frequent pushes and you will exceed it.

When you exceed the free tier: the cost is $0.008 per minute for Linux runners, so 1,000 extra minutes costs $8. For most small teams this is not a meaningful expense.

When to Move Beyond GitHub Actions

GitHub Actions is enough for: single applications, small-to-medium teams, standard CI/CD pipelines, repositories already on GitHub.

Consider dedicated CI when: you need custom hardware (GPU tests, specific OS versions), your build times are consistently over 20 minutes, you need more control over the runner environment, or you are at a scale where the per-minute pricing becomes significant.

CircleCI offers better caching and more CPU options for long builds. Buildkite runs CI on your own infrastructure (faster, no per-minute cost at scale, but requires runner maintenance). Self-hosted GitHub Actions runners give you similar control while keeping the GitHub Actions YAML format.

For most application development teams, GitHub Actions handles everything they need, and the integration with GitHub PRs and the repository makes it the lowest-friction option to start with.

Keep Reading

• CI/CD for Small Engineering Teams - broader CI/CD strategy beyond the mechanics of Actions
• pnpm vs npm vs Yarn Comparison - how to configure pnpm in CI for maximum install speed
• Monorepo with Turborepo Guide - how Turborepo's remote caching integrates with GitHub Actions

Pristren builds AI-powered software for teams. Zlyqor is our all-in-one workspace - chat, projects, time tracking, AI meeting summaries, and invoicing - in one tool. Try it free.