CI/CD Pipeline Setup for a Next.js SaaS in Under 1 Hour

A working CI/CD pipeline is one of the highest-leverage investments a SaaS team can make in its first month. It turns deployment from a stressful weekly event into a boring background activity that happens dozens of times a day. It catches bugs before they reach customers. It gives every engineer confidence that their changes will not break the app. And done right, it takes less than an hour to set up for a modern Next.js SaaS. Founders who defer CI/CD as "we will do it later" almost always regret it, because every week without a pipeline compounds into merge conflicts, missed bugs, and the kind of manual deploy anxiety that slows a team down without anyone noticing. This post walks through the exact setup we use on every 45-day SaaS launch: GitHub Actions for CI, Vercel or Railway for deployment, Playwright for end-to-end tests, and a small set of guardrails that catch the mistakes that would otherwise reach production. If you follow along, you will end up with a pipeline that lints, tests, builds, deploys previews for every PR, and pushes to production on merge to main. All of that in under an hour of work.

Why CI/CD matters more than founders think

Every SaaS team without CI/CD develops the same bad habits. Deploys become events that require a specific person to be online. Small changes get batched into large releases because nobody wants to deploy twice in a day. Bugs slip through because tests were skipped in the rush to ship. Engineers grow reluctant to refactor because they cannot easily verify their changes did not break anything. All of these problems compound quietly, and the cost only becomes visible months later when velocity has dropped by half.

CI/CD fixes all of them by making deployment safe and cheap. When any engineer can push a change, watch it pass tests, and see it deploy automatically, small changes become the norm. Small changes are easier to review, easier to debug, and less likely to break things. This is the compound interest of engineering velocity, and it takes a real pipeline to unlock it.

The other benefit is developer experience. A team with proper CI/CD attracts and retains better engineers. Nobody wants to work on a codebase where every deploy is a manual ceremony. The pipeline is a hiring signal as much as an operational one.

The setup in one hour: what you need first

Before you start, have these things ready. A Next.js SaaS in a GitHub repository. A Vercel or Railway account connected to the repo. A test suite: unit tests with Vitest or Jest and end-to-end tests with Playwright. Environment variables documented in a .env.example file. That is it. If you do not have tests yet, start with a smoke test that hits the homepage and checks it returns 200. You can add more tests over time.

The pipeline will do the following on every pull request: lint the code, run type checks, run unit tests, build the app, run end-to-end tests against a preview deployment, and post a comment with the preview URL and test results. On merge to main, it will deploy to production and run smoke tests against the production URL. If anything fails at any step, the deploy stops.

You will use GitHub Actions for the CI orchestration. GitHub Actions is free for public repos and generous for private ones. For a typical small SaaS, you will not exceed the free tier. If you do, the cost is under 50 dollars a month at most, which is trivial compared to the value.

Step 1: Configure the base pipeline in GitHub Actions

Create a file at .github/workflows/ci.yml in your repo. Configure it to trigger on pull requests to main and on pushes to main. The pipeline has three jobs: lint, test, and build. Each job runs in parallel where possible to keep the total pipeline time under 5 minutes.

The lint job runs your ESLint and Prettier commands. Fail on any linting error. This is the cheapest guardrail in the pipeline and catches an enormous number of small bugs. The type check step runs the TypeScript compiler in check mode. Fail on any type error. If you are on JavaScript rather than TypeScript, migrate. The type checker is worth more than any single test.

The test job runs your unit tests. Use Vitest or Jest depending on your setup. Aim for the full unit suite to run in under 60 seconds. If it takes longer, most likely you are hitting a real database or external service in tests, which is a signal to add better mocks or use an in-memory database for unit tests.

The build job runs the Next.js build. This catches bugs that only surface at build time, like missing environment variables or bad imports. It also verifies that the app will actually deploy. Do not skip this step even though it feels redundant with deployment.

Step 2: Wire up Vercel or Railway for preview deployments

Preview deployments are the single most valuable feature of modern hosting platforms. Every PR gets its own URL where you can click around and see the change in a real environment. Reviewers can test the change without pulling the branch locally. QA can validate before merge. Founders can preview features and give feedback.

On Vercel, this is enabled by default when you connect a GitHub repo. Every push to a branch creates a preview. Every PR gets a comment with the preview URL. No configuration needed. On Railway, enable preview environments in the project settings. The setup takes a few minutes and gives you similar per-PR previews.

Preview environments need their own environment variables and their own database if the app is data-heavy. For most SaaS MVPs, a shared staging database is fine. For anything more mature, use per-branch databases via Neon branches or a similar feature. This lets each PR test data migrations safely without affecting other branches.

Step 3: End-to-end tests against the preview

Once preview deployments work, add an end-to-end test job that runs Playwright against the preview URL. This is where the pipeline earns its keep, because unit tests only cover code paths they know about, but end-to-end tests exercise the actual user flows.

Start with the smoke tests: user can sign up, user can log in, user can complete the primary action of your product. These three tests catch 80 percent of the bugs that would embarrass you in production. Add more tests over time as you discover regressions worth preventing.

Configure Playwright to fail loudly on any assertion failure. Post the test output as a PR comment so reviewers can see what happened without digging into the Actions log. If a test fails intermittently, fix it or delete it. Flaky tests are worse than no tests because they teach the team to ignore failures. Our software development team follows a zero-tolerance policy on flaky tests, and it keeps our CI signal clean.

Step 4: Guardrails and required checks

Set the CI checks as required in the GitHub branch protection for main. This means no PR can merge unless all checks pass. It sounds strict, and it is, but it is what turns CI from a suggestion into a real safety net. Every team that skips this step ends up with someone merging a broken PR at least once a month.

Other guardrails worth setting: require at least one code review, require the branch to be up to date with main before merging, and disable force pushes to main. These take 5 minutes to configure and prevent categories of mistakes that would otherwise happen regularly. Add Dependabot or Renovate for dependency updates so security patches do not sit in your inbox for weeks.

Add a secrets scanner like Gitleaks that runs on every PR. This catches accidentally committed API keys before they reach the main branch. Once a key is on main, you must rotate it, which is expensive and error-prone. Preventing the leak is cheap and easy with the scanner.

Step 5: Production deploys and smoke tests

On merge to main, Vercel or Railway automatically deploys to production. Add a post-deploy job in GitHub Actions that runs a smoke test against the production URL: hit the homepage, verify auth works, verify the primary user action works. If any of these fail, alert immediately in Slack.

Configure Sentry or a similar error tracker to capture any production errors. Set up an alerting rule that pings the on-call channel if error rate spikes above baseline within 15 minutes of a deploy. This gives you a fast feedback loop between deployment and detection, which is what separates teams that recover from bad deploys in minutes from teams that recover in hours.

For higher stakes deploys, add a manual approval step before production deploy. This lets a human confirm the change before it goes live. Most small teams do not need this, but as the SaaS grows and deploys touch payment or auth logic, the added friction is worth it.

Advanced patterns worth adding later

• Canary deploys: route 5 percent of traffic to the new version, monitor for errors, then ramp up.
• Blue-green deploys: run two production environments, cut traffic over instantly, roll back by flipping the switch.
• Feature flags: deploy code dark, enable per-user or per-cohort. LaunchDarkly, Statsig, or PostHog work here.
• Database migration checks: verify migrations are backward-compatible before deploy.
• Load tests in staging: catch performance regressions before they hit production.

Do not add these on day one. Add them once the basic pipeline is boring and reliable. Adding advanced patterns to a broken foundation makes things worse, not better.

Feature flags in particular are worth investing in once the team is deploying multiple times a day. They let you separate the deploy of code from the release of a feature, which means you can merge to main without immediately exposing new behavior to users. This unlocks trunk-based development, one-way rollbacks by toggling a flag, and gradual rollouts to specific customer cohorts. PostHog offers feature flags on its free tier for small teams, which is a good place to start.

Common CI/CD mistakes

Founders make a few predictable mistakes when setting up CI/CD. The first is treating the pipeline as optional. If any deploys happen outside the pipeline, the pipeline is not real. Enforce it in branch protection and never make exceptions. The second is over-instrumenting from day one. A 30-minute pipeline is worse than a 5-minute pipeline that runs 90 percent of the same tests. Keep the pipeline fast so engineers actually watch it.

The third mistake is ignoring test flakiness. Flaky tests train the team to ignore failures, which defeats the whole purpose of CI. Fix or delete flaky tests immediately. Our API and backend team considers a flaky test a bug that needs a ticket, not a nuisance to work around.

Environment variable and secret management

Secrets are where CI/CD projects quietly fail. The right pattern is a secrets manager that all environments read from, not files committed to the repo. Vercel and Railway both include environment variable UIs that work well for small teams. GitHub Actions has its own secrets store for the pipeline itself. Never commit a real credential to the repo, even temporarily. If you do, rotate it immediately and add a secrets scanner to catch it earlier next time.

Structure your environment variables by environment, not by feature. Each environment has its own set of secrets, and the pipeline pulls the right set based on the branch or deployment target. For higher stakes, use a dedicated secrets manager like Doppler, Infisical, or AWS Secrets Manager, which give you audit logs, access controls, and rotation policies that a hosting platform's built-in UI does not provide.

Speed matters: keep the pipeline under 5 minutes

A pipeline that takes 20 minutes is a pipeline nobody watches. Engineers push a change, walk away, and come back to a failure they no longer remember the context for. A pipeline under 5 minutes gets watched, and its feedback loop is tight enough to actually change behavior. Optimize aggressively: parallelize jobs, cache dependencies, skip unnecessary steps for docs-only changes, and split slow tests into a separate nightly run if they cannot be sped up.

Cache node_modules, cache the Next.js build output, cache Playwright browsers, and cache anything else that repeats across runs. Every cache hit saves 30 to 90 seconds. On a pipeline that runs 20 times a day, that saves hours per week of aggregate CI time and, more importantly, keeps every individual run fast enough to matter. See our API and backend team's playbook for more specific optimization tips.

How QwiklyLaunch sets up CI/CD in 45 days

On every 45-day SaaS launch, we set up the basic pipeline in the first week. It runs lint, type check, unit tests, and build on every PR. By week 2, we add end-to-end tests against preview deployments. By week 5, we add production smoke tests and error tracking with Sentry alerts. By launch day, the pipeline is boring and reliable, and the team has confidence to deploy on demand.

This discipline is not a luxury, it is the foundation for shipping fast without breaking things. If you want us to set up your CI/CD or audit an existing pipeline, reach out for a scoping call, or see our projects library for examples of the pipeline in action.