GitHub Actions — The Complete Guide
every push runs tests, builds and deploys — without a separate CI server, free for open source
GitHub Actions is a CI/CD (continuous integration / continuous deployment) system built directly into GitHub. CI/CD is the name for the automation that, every time you push code, runs tests, builds the application, and if everything is green — deploys it to production. Once upon a time, building such a pipeline required a separate CI server (Jenkins, TeamCity), hours of setup, and ongoing maintenance. With GitHub Actions, it's a single YAML file inside the repo (`.github/workflows/`) and GitHub itself runs everything on their servers — free for open source projects, and with 2,000 free minutes per month for private projects. For me (Elad), GitHub Actions builds this site (Next.js) every time something is pushed to main, deploys it automatically to Vercel, runs TypeScript checks, and verifies that no secrets accidentally leaked into the code. I also have actions that run daily tasks (cron triggers), open PRs automatically when dependencies are out of date (Dependabot) — all without a single server of mine. It's the tool that makes the difference between 'I'm just hacking alone' and 'I have a professional process'.
What this guide covers
What is GitHub Actions: workflow, jobs, steps
The hierarchy every YAML file describes
GitHub Actions is built from three levels. Workflow = a single YAML file triggered by an event (push, PR, schedule, manual). Jobs = work units inside a workflow that can run in parallel or sequentially. Steps = commands inside a job. Each job runs on a runner — a brand-new VM GitHub provides, with Linux/Windows/macOS to choose from. After the workflow finishes, the runner is destroyed — clean slate every run.
First workflow: TypeScript check on every PR
5 minutes from zero to real CI
The best way to learn is to see a simple workflow that does something real. The example below runs `tsc --noEmit` and `eslint` on every push and every PR — so nothing ever merges to main that doesn't pass type-check.
Auto-deploy Next.js to Vercel
Push to main = production deploy in under two minutes
Once CI is working, the next step is automatic deploy. Vercel supports a GitHub integration that deploys on every push without a special workflow — but if you want full control (deploy only after tests pass, to a specific environment, with custom build args), a YAML workflow gives you that.
Secrets & OIDC: don't put API keys in code
How to give CI cloud access without static credentials
Every workflow that does a deploy needs access to some cloud (Vercel, AWS, Cloudflare). The old way is static tokens stored in GitHub Secrets — it works but isn't ideal (a leaked token = full account access). The modern way is OIDC (OpenID Connect): GitHub issues a unique JWT per workflow run, and you configure trust in the cloud that 'if this JWT came from repo X, branch Y, you can assume it's me'.
Advanced: matrix, reusable, self-hosted
The features that make a difference
Once you have a basic working workflow, here are the features that level you up.
Field tips
What I've learned from three years of GitHub Actions
After three years of using GitHub Actions, here are the things I wish I knew at the start.
