The Ultimate Guide to CI/CD Pipelines with GitHub Actions and AWS

“

Meerako — Dallas-based DevOps experts building automated cloud infrastructure.

How does your company deploy new code to production? If the honest answer involves someone manually logging into a server and pulling from Git, that's a real operational liability, not just an inconvenience — it's slow, error-prone under pressure, and fundamentally impossible to scale as your team and release frequency grow.

The fix is CI/CD — Continuous Integration and Continuous Deployment, and it's genuinely one of the highest-leverage investments an engineering team can make early, since the cost of setting it up properly is fixed while the benefit compounds with every single deploy that follows. A CI/CD pipeline is the automated bridge from a developer's git push to a live, production-ready application, with tests and checks enforced at every step along the way. At Meerako, DevOps isn't an afterthought — we build the pipeline that builds the app, for every client. This guide covers our default modern stack: GitHub Actions plus AWS, including a real security update worth knowing if your existing pipeline still uses long-lived static credentials — OIDC-based authentication is now the recommended 2026 approach, eliminating stored AWS access keys entirely.

• What CI and CD actually mean in practical, business terms.
• Why GitHub Actions has become the default CI tool for most teams.
• A concrete, working pipeline example for a Next.js app deploying to AWS, using current 2026 security best practices.
• Why OIDC authentication should replace static AWS credentials in any pipeline still using them.
• What separates a real enterprise-grade pipeline from a basic example like this one.

Continuous Integration is the build-and-test phase. Every push to a branch triggers an automated process: check out the code, install dependencies, run the full automated test suite, and confirm the change integrates cleanly with the main branch. The business value is direct — bugs get caught before they reach production, and code quality is enforced consistently rather than depending on manual review discipline alone.

Continuous Deployment is the release phase. Once CI passes on the main branch, the pipeline automatically builds the production-ready artifact, packages it (often as a Docker container), and deploys it to your production environment. The business value here is speed: new features and fixes reach customers in minutes, not the days or weeks a manual release process typically requires.

Jenkins and GitLab CI were common defaults for years. Today, we recommend GitHub Actions for the large majority of projects, for a few concrete reasons: it's natively integrated, with code, pull requests, and pipelines all living in one platform; pipelines are defined in YAML files that live directly in your repository — infrastructure as code, versioned alongside everything else; and its marketplace of pre-built actions covers nearly every common deployment task, from AWS CLI operations to Docker builds to Slack notifications. AWS has also continued investing in native GitHub Actions integration — Lambda functions can now deploy directly through GitHub Actions with configuration changes triggering an automated function update, streamlining serverless CI/CD specifically.

Before the working example below, it's worth flagging a genuine security upgrade that a lot of existing pipelines haven't adopted yet. Storing long-lived AWS access keys as GitHub Secrets — the pattern shown in older tutorials and, frankly, plenty of pipelines still running in production — creates a standing credential that, if ever leaked, remains valid until someone manually rotates it. The current recommended approach is OpenID Connect (OIDC) authentication: your workflow exchanges a short-lived, cryptographically verified token for temporary AWS credentials at runtime, with no long-lived secret stored anywhere. If your pipeline still uses static AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY secrets, migrating to OIDC is one of the highest-value, lowest-effort security improvements available, and it's genuinely a same-day change for most projects.

Here's a pipeline deploying a Next.js app to S3/CloudFront, placed in .github/workflows/deploy.yml, using current OIDC-based authentication rather than static credentials:

name: Deploy Next.js to S3

on:
  push:
    branches: [ main ]

permissions:
  id-token: write   # Required for OIDC
  contents: read

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Configure AWS Credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-deploy-role
          aws-region: us-east-1

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install Dependencies
        run: npm ci
      - name: Run Unit Tests
        run: npm test

      - name: Build Next.js App
        run: npm run build

      - name: Sync build to S3
        run: |
          aws s3 sync ./out s3://${{ secrets.AWS_S3_BUCKET_NAME }} --delete

      - name: Invalidate CloudFront
        run: |
          aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_CLOUDFRONT_DIST_ID }} --paths "/*"

Note the permissions: id-token: write block and the role-to-assume configuration — this replaces static keys with a temporary role assumption, requiring a corresponding IAM role in AWS configured to trust GitHub's OIDC provider for your specific repository.

For backend workloads running on Lambda specifically, AWS's newer native GitHub Actions integration is worth calling out separately from the general S3/CloudFront example above. Rather than scripting Lambda deployment through a series of AWS CLI calls, function code and configuration changes can now trigger an automated deployment directly through GitHub Actions with considerably less custom pipeline scripting than was previously required — a genuine simplification for teams running a serverless-first backend architecture, and one more reason a Lambda-heavy stack and a well-built CI/CD pipeline pair naturally together.

Beyond security, build speed directly affects how often your team is willing to iterate — a pipeline that takes fifteen minutes to run discourages the frequent, small commits that make CI/CD genuinely valuable in the first place. A deliberate caching strategy — caching node_modules via npm's built-in cache action, caching Docker layers for containerized builds, and caching any downloaded build tools — routinely cuts pipeline run time significantly, and it's a genuinely easy addition to a pipeline that's already working but slower than it needs to be.

This example is a genuine starting point, not a finished production pipeline. What we typically add for client projects:

• Staging environments. develop branch pushes deploy to a separate staging environment for manual QA before anything merges to main and reaches production, often with a manual approval gate for the production deployment step specifically.
• Containerization for SaaS backends. Docker images pushed to Amazon ECR — which integrates seamlessly with ECS and EKS, handles authentication automatically through IAM, and includes built-in vulnerability scanning — deployed with zero-downtime rolling deployments, not a single-shot replacement that risks a brief outage.
• Security scanning built into the pipeline itself — dependency vulnerability checks and secret-exposure scanning run automatically on every push, not as a separate periodic audit.
• Team notifications, so a failed deploy surfaces immediately in Slack rather than being discovered later when something's already broken in production.

Since OIDC is the genuine security upgrade most existing pipelines are missing, it's worth walking through what the AWS side actually requires, not just the GitHub Actions side. First, create an IAM OIDC identity provider in your AWS account pointing at GitHub's token issuer, if one doesn't already exist. Then create an IAM role with a trust policy scoped specifically to your repository and branch — not a broad trust policy that would let any GitHub Actions workflow assume it, which would defeat much of the security benefit. The trust policy's sub condition should reference your specific repo:your-org/your-repo:ref:refs/heads/main pattern, ensuring only workflows running against your main branch in your specific repository can assume the deployment role. Finally, attach a permissions policy to that role scoped to exactly what the deployment needs — S3 write access to the specific bucket, CloudFront invalidation rights for the specific distribution — following the principle of least privilege rather than attaching a broad administrative policy out of convenience. This setup takes perhaps thirty minutes longer than pasting in static keys, and it's thirty minutes genuinely well spent — a small, one-time investment against the very real, ongoing risk of a leaked long-lived credential sitting quietly in a compromised secrets store.

A pipeline that only handles the happy path is an incomplete pipeline. Every production deployment strategy needs a clear, tested rollback path — for a static site deployment like the S3 example above, this can be as simple as keeping the previous build artifact available and scripting a quick re-sync; for containerized deployments on ECS, this typically means keeping the previous task definition revision available so a rollback is a single command rather than a full rebuild. The teams that handle production incidents calmly are consistently the ones who tested their rollback procedure before they needed it under pressure, not the ones improvising a recovery plan while a production issue is actively affecting customers.

A reliable CI/CD pipeline isn't just an engineering nicety — it directly enables business agility. Teams with mature CI/CD can ship a critical bug fix within the hour; teams without it are stuck waiting for a scheduled deploy window or a risky manual process, which has real cost when a production issue is actively affecting customers.

A manual deployment process is a real business liability; an automated CI/CD pipeline is a strategic asset that enforces quality, reduces human error, and gives your team genuine confidence to ship frequently. Building it on current best practices — OIDC authentication instead of long-lived credentials, deliberate caching, and real staging gates — is a core part of how we deliver every project, not an optional add-on considered after launch.

Ready to automate your way to better, faster, and genuinely more secure software delivery?