Deploying a Spring Boot Application with GitHub Actions
Fast recall
Quick revision
Core answer
Whether you can connect the build pipeline all the way through to a real deployment target.
Running the build and deploy in a single job without an artifact handoff, which makes rollbacks harder and mixes concerns.
Mention environment protection rules for production approval, blue-green or rolling deployment strategies, and health-check verification steps after deployment.
Interview-ready guide
Interview answer
A GitHub Actions deployment workflow takes a built and tested artifact, packages it as a Docker image, and deploys it to Kubernetes. The workflow separates CI (build and test) from CD (deploy) using GitHub environments for approval gates and traceability.
Image build and push
- Build the Docker image after tests pass:
docker build -t registry.io/payment-service:${{ github.sha }} .— use the full Git SHA as the image tag, not a semantic version orlatest; the SHA is immutable, traceable to the exact commit, and avoids the image pull behavior issues with mutable tags - Push to the registry using OIDC-based authentication when the registry supports it (AWS ECR with
aws-actions/amazon-ecr-login@v2); fall back todocker/login-action@v3with a stored secret for other registries - The image SHA tag is the link between the CI artifact and what runs in production —
kubectl describe podshows the image tag, and you can immediately identify which commit is deployed
Environment gates
- Define
environment: stagingorenvironment: productionin the deploy job — GitHub tracks all deployments to each environment, shows the deployment history on the repository page, and optionally requires a reviewer approval before the job runs - Use
environment: productionwith a required reviewer for the production deploy job — the job waits for manual approval beforePROD_KUBECONFIGsecrets are injected; this is the standard mechanism for human-in-the-loop production deployments in GitHub Actions
Kubernetes deploy and verification
kubectl set image deployment/payment-service app=registry.io/payment-service:${{ github.sha }} -n productionupdates the Deployment with the new image SHAkubectl rollout status deployment/payment-service -n production --timeout=300swaits for completion and fails the workflow if the rollout does not succeed within 5 minutes — the workflow shows red if deployment failed, not just if thekubectlcommand ran- On failure,
kubectl rollout undo deployment/payment-service -n productionin theif: failure()step automatically rolls back to the previous version; this keeps the production state consistent even when the workflow reports failure
Deploying a Spring Boot Application with GitHub Actions
Direct Answer
You deploy a Spring Boot app with GitHub Actions by building a JAR or Docker image in the CI job and then running a deployment job that pushes to your target platform — AWS Elastic Beanstalk, ECS, a bare VM via SSH, or a PaaS — using stored credentials from GitHub Secrets.
Common Mistakes & Pitfalls
Running the build and deploy in a single job without an artifact handoff, which makes rollbacks harder and mixes concerns.
Check your understanding
Answer these without looking back at the article.
- How do you implement a rollback in GitHub Actions if a deployment fails?
- How do you pass the Docker image tag from the build job to the deploy job?
- What is the difference between using ECS versus Elastic Beanstalk for Spring Boot deployments?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.