Setting Up CI/CD for Next.js with GitHub Actions

Automate testing, building, and deploying Next.js apps — trunk-based development and infrastructure as code for modern web teams

CI/CD Is Not a Luxury
Continuous Integration and Continuous Deployment are not enterprise-only practices. Even a solo developer benefits from automated testing, linting, and deployment. At scale, CI/CD is the difference between shipping features daily and deploying once a month with crossed fingers.

At The Beyond Horizon, every project — from a landing page to a full SaaS platform — ships with CI/CD configured from day one. The cost of setting it up is an afternoon. The cost of not having it compounds every single day.

What CI/CD Actually Means
Continuous Integration (CI): Every code change is automatically tested. When a developer pushes to a branch, the CI pipeline runs linting, type checking, unit tests, and integration tests. If anything fails, the team knows within minutes — not after deployment.

Continuous Deployment (CD): Every change that passes CI is automatically deployed. Merge to main → tests pass → deploy to production. No manual deployment steps, no “deploy Friday” calendar events, no deploy scripts run from a developer laptop.

Our GitHub Actions Pipeline
We standardize on GitHub Actions for CI/CD. Here is the pipeline structure we use for Next.js projects:

On Pull Request

1. Install dependencies: Using npm ci with dependency caching for speed

2. Type check: Run tsc — noEmit to catch TypeScript errors

3. Lint: ESLint with our configured rules

4. Unit tests: Vitest for unit and component tests

5. Build: next build to catch build-time errors

6. Preview deployment: Vercel automatically deploys a preview URL for the PR

Every pull request gets a working preview URL that stakeholders can review before merging. This eliminates “it looked different in my local environment” issues.

On Merge to Main

1. All CI checks run again: Never trust that PR checks still pass after merge

2. Deploy to production: Vercel or Railway automatic deployment

3. Post-deploy smoke tests: Hit critical endpoints to verify the deployment is healthy

4. Notify team: Slack notification with deployment status and changelog

Branch Strategy
We use trunk-based development for most projects:

Become a Medium member
main: Always deployable. Every merge triggers production deployment.

feature/xxx: Short-lived branches (1–3 days maximum). Created from main, merged back to main.

No develop branch: The develop → staging → production pipeline adds delay without adding safety. Feature flags handle incomplete features.

For projects with compliance requirements or longer release cycles, we add a staging branch with its own deployment environment.

Testing Strategy
Not all tests are equal. We follow the testing trophy (not the testing pyramid):

Static analysis (most): TypeScript + ESLint catch entire categories of bugs at write time

Integration tests (many): Test features end-to-end through multiple components and API routes

Unit tests (some): Test complex business logic in isolation — utility functions, calculations, data transformations

E2E tests (few): Playwright tests for critical user flows — signup, checkout, payment

The key insight: integration tests give the most confidence per test. A single test that renders a form, fills it out, submits it, and verifies the API response tests dozens of units simultaneously.

Infrastructure as Code
CI/CD is not just for application code. Infrastructure should be versioned and deployed through the same pipeline.

Terraform: Define cloud resources (databases, storage buckets, networking) as code. Changes go through PR review just like application code.

Docker: Application runtime is defined in a Dockerfile. The exact same container runs locally, in CI, and in production.

Environment variables: Managed through Vercel environment settings or cloud secret managers — never committed to the repository.

Monitoring and Rollback
Deployment is not the end — it is the beginning of observation.

Health checks: Every deployment is verified against a health endpoint within 30 seconds

Error tracking: Sentry captures runtime errors with source maps for precise stack traces

Performance monitoring: Core Web Vitals tracked per deployment to catch performance regressions

Instant rollback: If metrics degrade, the previous deployment is restored within 60 seconds

The goal is not to prevent all bugs from reaching production — that is impossible. The goal is to detect issues in minutes and recover in seconds.

Want CI/CD set up for your project? Contact us.