GitHub Actions CI/CD for Nepal (2026)

From Praxium Labs — Nepal's AI and automation consultancy in Lalitpur. We design and build the systems described in this guide for Nepali businesses and for international teams operating from Nepal.

At Praxium Labs we build this for Nepali businesses every month; this is the field-tested version. Most Nepali engineering teams adopt GitHub Actions reflexively. With reasonable defaults it just works; with bad defaults it leaks secrets, costs more than it should, or fails silently.

A starter workflow file

.github/workflows/ci.yml

name: CI
on:
  push:
    branches: [main]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

Deployment patterns

To Cloudflare Pages: use cloudflare/pages-action@v1 with an API token; deploy on every push to main
To Vercel: Vercel-GitHub integration; no manual workflow needed
To Hetzner / DigitalOcean VPS: SSH-based deploy via appleboy/ssh-action or rsync; or push to a Docker registry and pull on the VPS
To AWS: use OIDC authentication (no long-lived secrets) via aws-actions/configure-aws-credentials@v4
To Kubernetes: ArgoCD pulling from git (GitOps), or kubectl apply from the workflow

Secret management

Never commit secrets to repo files; not even in .env.example
Repository secrets for static API keys
Environment secrets for prod / staging separation
OIDC for cloud deployments — no AWS access keys stored in GitHub at all
Limit secret scope: a workflow only sees the secrets in its environment
Audit: who has admin access to add / view repo secrets? Restrict to 2-3 people max

Cost control

GitHub Actions free tier (2026): 2,000 CI minutes / month for private repos on Free plan; 3,000 on Team. Beyond that you pay per minute. Patterns to stay inside the free tier:

Cache aggressively: actions/setup-node@v4 with cache: 'npm' halves install time
Run only what changed: path-based filters skip CI on docs-only PRs
Avoid matrix bloat: matrix over 3 OS × 4 Node versions = 12x cost. Run matrix on schedule, not every PR
Self-hosted runners on a Hetzner / DO VPS: free per-minute cost, you pay only for the VPS. Worth it above 2,000 minutes/month

Security pitfalls

pull_request_target trigger: runs workflows from the base branch with the secrets of the base branch — but on PR code. Easy way to leak secrets. Use only when you must
Action pinning: reference actions by commit SHA (actions/checkout@b80ff79f1755d06ba70441c368a6fe801f5f3a62) rather than tag (@v4) for the most security-conscious projects
Workflow permissions: set permissions: contents: read at top of workflow; opt in to write permissions only where needed
Untrusted PR code execution: never run untrusted code with secrets attached. Use a manual approval gate for external contributors

Useful actions

actions/cache — for build artifacts and dependencies
actions/upload-artifact / download-artifact — pass files between jobs
peter-evans/create-pull-request — bot-generated PRs (dependency updates, release notes)
nick-fields/retry — retry flaky steps with backoff
aquasecurity/trivy-action — vulnerability scanning of containers and code
github/codeql-action — static code analysis (free for public repos)

Cost considerations

GitHub Actions includes 2,000-3,000 free minutes per month for public repos; private repos consume your paid quota. For a typical Nepali startup with active CI: 5-15k minutes / month is realistic; consider GitHub Team or higher tier. Self-hosted runners on a Nepali VPS bypass the metering entirely for predictable cost — but require maintenance. The right pattern: hosted runners for typical workloads, self-hosted runners for heavy build jobs (Docker images, ML training). For broader CI / deployment context, see our cloud guide.

Workflow patterns we use

Cache aggressively — node_modules, pip cache, docker layers; cuts typical workflow time by 40-70%
Path filters — only run the test job that's affected by changed files
Matrix builds for multi-version testing (Node 18 / 20, Python 3.10 / 3.11)
Secrets via OIDC rather than long-lived AWS keys — short-lived tokens reduce blast radius
Required checks on main — branch protection that demands green CI before merge
Deploy from CI not from developer laptops; reduces deploy variance

Frequently asked questions

Is GitHub Actions cheaper than CircleCI / GitLab CI?

For most Nepali teams: yes, especially on private repos where GitHub bundles minutes with the existing GitHub plan. Pure-CI pricing comparison favours GitHub for typical small-team workloads.

Can I run workflows from Nepali infrastructure?

Yes — self-hosted runners on any internet-connected machine. Useful for cost optimisation and for workloads that need network access to internal Nepali resources.

How do I handle large monorepos?

Path filters to run only affected workflows. Use tools like Nx or Turborepo for build-graph caching. Above ~50 packages, consider a dedicated build server with build caches like Bazel's remote cache.

Are GitHub Actions logs sensitive?

Yes — never log secrets. GitHub auto-masks anything matching a registered secret value, but log content is otherwise visible to anyone with repo access. Treat logs as semi-public.

What about CI for compliance (ISO 27001, SOC 2)?

GitHub Actions workflow runs serve as audit evidence — they show that tests ran, who approved the deploy, when the deploy happened. Configure branch protection + required approvals + signed commits for compliance-tight repos.

GitHub Actions vs GitLab CI vs Jenkins?

For Nepali startups on GitHub: stick with Actions. GitLab CI is comparable if you're already on GitLab. Jenkins is heritage / specialised — only choose if you have specific reasons (existing pipelines, on-prem requirement).

Can we use self-hosted runners safely?

For private repos, yes — runners can be on your own VPS, no security concern. For public repos, never run untrusted PR code on self-hosted runners (use only managed runners for forks).

About Praxium Labs

Praxium Labs is Nepal's AI and automation consultancy, based in Lalitpur, Nepal. We help Nepali businesses — and international teams operating from Nepal — ship AI chatbots, n8n workflow automations, machine-learning systems, web and mobile applications, cloud infrastructure, and DevOps pipelines that work in Nepal's real conditions: NPR pricing, eSewa / Khalti / Fonepay integrations, NRB / IRD / SSF compliance, Devanagari language handling, and the network and talent realities most international playbooks miss.

This guide was written by the Praxium Labs engineering team from direct production experience deploying systems for Nepali banks, e-commerce, hospitality, healthcare, NGOs, and startups. If you need this implemented for your team, talk to us for a free 30-minute scoping call — or browse our full services.