CI/CD for Spring Boot with GitHub Actions

By Khimananda Oli | Last reviewed: August 2026

Shipping Java microservices reliably requires more than just running mvn package; it demands a reproducible, secure automation layer that catches regressions before they reach production. Implementing CI/CD for Spring Boot with GitHub Actions gives you tight integration with your repository, native Maven/Gradle caching, and OIDC-based cloud authentication without managing Jenkins servers. This guide walks through building a hardened, audit-ready pipeline that handles everything from unit tests to containerized deployments.

How do you structure a CI/CD for Spring Boot with GitHub Actions workflow?

A common mistake is cramming every step into a single job, which prevents parallelism and makes debugging painful. Split your pipeline into logical jobs: test, build-image, and deploy. Use explicit needs dependencies so the image only builds after tests pass, and deployment only occurs after a successful image push. Pin all third-party actions to full commit SHAs rather than mutable tags like v4 to prevent supply-chain attacks — a critical practice for any team pursuing SOC 2 or ISO 27001 compliance.

Core workflow skeleton

name: Spring Boot CI/CD
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

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

jobs:
  test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'
          cache: 'maven'
      - name: Run tests
        run: ./mvnw -B verify --file pom.xml

  build-and-push:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
      - name: Push to GHCR
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

This structure ensures that broken code never produces a deployable artifact. The if guard on the build job prevents unnecessary image creation on pull requests, saving both time and registry storage costs.

How do you optimize Maven builds and dependency caching in GitHub Actions?

Spring Boot projects pull hundreds of transitive dependencies. Without caching, each workflow run downloads 200–500 MB of JARs, adding 2–4 minutes of pure network latency. The actions/setup-java action includes built-in Maven caching that hashes your pom.xml files automatically. However, many teams miss that the cache key must account for multi-module projects correctly.

• Use the wrapper: Always invoke ./mvnw instead of system mvn to guarantee version consistency between local dev and CI.
• Enable batch mode: Pass -B to suppress interactive prompts and reduce log noise.
• Parallelize modules: Add -T 1C to use one thread per CPU core during compilation and testing.
• Skip redundant plugins: In CI, disable reporting plugins not needed for verification: -DskipITs=false -Denforcer.skip=true.

If your project uses Gradle instead of Maven, swap cache: 'maven' for cache: 'gradle' in the setup-java step. The underlying mechanism is identical, but the cache keys differ. For monorepos with multiple Spring Boot services, consider using monorepo strategies with path filters to avoid rebuilding unchanged services.

What is the best Dockerfile strategy for Spring Boot in CI?

Never copy your entire source tree into a Docker image and run mvn package inside the container. This bloats layers, slows builds, and leaks build tools into production images. Use a multi-stage build where compilation happens in an ephemeral stage and only the runtime JRE plus the final JAR survive to the output image.

# Stage 1: Build
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app
COPY .mvn .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline -B
COPY src src
RUN ./mvnw package -DskipTests -B

# Stage 2: Runtime
FROM eclipse-temurin:21-jre-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
USER appuser
EXPOSE 8080
ENTRYPOINT ["java", "-XX:+UseContainerSupport", "-jar", "app.jar"]

The dependency:go-offline step creates a dedicated layer for dependencies. Since application code changes far more frequently than dependencies, this layer stays cached across commits. The Alpine JRE base reduces the final image to ~90 MB versus ~300 MB for full JDK images. Always run as a non-root user (appuser) — this is a non-negotiable security baseline for containerized workloads.

How do you manage secrets and credentials securely in Spring Boot pipelines?

Hardcoding database passwords or API keys in workflow files is the fastest way to fail a security audit. GitHub Actions provides encrypted secrets at the repository and organization level, but how you inject them matters. Never echo secrets to logs. Use environment variables scoped to specific steps, and prefer OIDC over static access keys whenever possible.

For AWS deployments, configure an IAM role trust policy that accepts GitHub’s OIDC provider. Then use aws-actions/configure-aws-credentials@v4 with role-to-assume instead of aws-access-key-id. This eliminates long-lived credentials entirely. For database migrations in CI, create a dedicated read-write user scoped to the test schema — never reuse production credentials. Teams handling sensitive data should review secrets management best practices before going live.

How do you deploy Spring Boot applications safely from GitHub Actions?

Deployment is where most pipelines break under real-world pressure. A naive docker run or kubectl apply causes downtime and offers no rollback path. Structure deployments as discrete jobs with health checks, and always tag images with immutable identifiers (commit SHA), not mutable tags like latest.

1. Tag immutably: Use ${{ github.sha }} as the primary tag. Optionally add main-${{ github.run_number }} for human readability.
2. Separate deploy job: Keep deployment logic out of the build job. This allows re-running a failed deploy without rebuilding.
3. Add health verification: After deploying, curl the /actuator/health endpoint. Fail the job if it doesn’t return 200 within 60 seconds.
4. Implement rollback: Store the previous working SHA. On health check failure, redeploy that SHA automatically.
5. Gate production: Use GitHub Environments with required reviewers for production deploys. Staging can auto-deploy on merge to main.

For Kubernetes targets, integrate with GitOps tools like ArgoCD rather than applying manifests directly from Actions. This keeps the cluster state declarative and auditable. See setting up GitOps with ArgoCD for a pattern that pairs well with GitHub Actions as the CI provider. For traditional VPS deployments, use SSH with key-based auth stored in secrets, and always restart via systemd with --wait to confirm service activation.

Making Your CI/CD for Spring Boot with GitHub Actions Production-Ready

A working pipeline is just the starting point. To make your CI/CD for Spring Boot with GitHub Actions truly production-grade, add observability from day one: emit structured logs during builds, track pipeline duration metrics, and alert on repeated failures. Integrate static analysis with SonarQube as a quality gate before merging. Sign your container images with Sigstore cosign to establish supply chain provenance. Review your workflow permissions quarterly — remove packages: write from PR-triggered runs and restrict environment access to protected branches only. If you need help hardening your Java delivery pipeline or preparing for a compliance audit, reach out to discuss your infrastructure.