Deploying Spring Boot applications to Kubernetes with Helm charts

Spring Boot has become the go-to framework for REST APIs and microservices across Australian fintech startups in Sydney and Brisbane, while Helm remains the standard way to package resources for a Kubernetes cluster. Combining the two lets a small team ship a fat jar as a container, parameterise every environment-specific value, and roll back releases with a single command. This guide walks through preparing the application, building a Docker image, structuring a chart, configuring templates, and deploying to a managed cluster hosted in the AWS Sydney region (ap-southeast-2).

The workflow suits teams operating clusters in ap-southeast-2 or australia-southeast1 that need a reproducible path from mvn package to a live endpoint. A well-designed chart abstracts namespaces, ingress, and secret management, which matters when complying with the Privacy Act 1988 and the Notifiable Data Breaches scheme. The result is a deployment pipeline that developers can trust without leaning on bespoke shell scripts.

Preparing the Spring Boot application

Before thinking about container orchestration, the application itself should be production-ready. Enable the actuator dependency so liveness and readiness probes have something to call, and externalise every connection string into environment variables or a ConfigMap. A typical application.yml for an Australian e-commerce platform might pull the database URL from SPRING_DATASOURCE_URL, the Stripe key from a Kubernetes Secret, and the logging level from a profile activated by SPRING_PROFILES_ACTIVE=prod.

Build a single executable jar with mvn clean package -DskipTests so the resulting target/app.jar is ready to be copied into a slim container. If the application serves traffic across multiple time zones, including AEST, format timestamps with ZoneId.of("Australia/Sydney"). This detail prevents log analysis headaches when an on-call engineer in Melbourne triages an incident at 2 a.m.

Building and pushing the Docker image

A multi-stage Dockerfile keeps the final image small and the build cache efficient. The first stage uses a Maven image with OpenJDK 21 to compile the project, while the second copies only the jar into an eclipse-temurin:21-jre-alpine base. Tag the image with both the commit SHA and the semantic version, so a Helm release can be traced back to a specific build.

Push the image to a registry reachable from the target cluster. Many Australian shops use Amazon ECR in Sydney, Azure Container Registry in Australia East, or the GitHub Container Registry for simpler pipelines. After docker push, confirm the digest with crane digest and store it in the Helm values.yaml so deployments are reproducible.

Structuring the Helm chart and configuring values

A chart is a directory with a Chart.yaml describing metadata and a templates/ folder holding Kubernetes manifests rendered by the Go templating engine. Run helm create springboot-app to scaffold the layout, then prune anything that is not needed. For a simple microservice, keep deployment.yaml, service.yaml, ingress.yaml, and configmap.yaml, while dropping the probe-heavy defaults if the actuator already exposes /actuator/health.

The values.yaml file is where every environment-specific knob lives. Typical entries include replicaCount, image.repository, image.tag, service.port, ingress.host, and resources.requests. For an Australian retailer serving both Sydney and Perth users, you might set replicaCount: 3 and configure an ingress class of nginx with a TLS secret issued by Let's Encrypt. The breakdown below clarifies which settings belong in the chart versus which should come from external sources:

Concern Source of truth Example
Container image tag values.yaml tag: "1.4.2"
Database password Kubernetes Secret db-password: <base64>
Replica count values.yaml replicaCount: 3
TLS certificate cert-manager + Secret auto-rotated
Logging level ConfigMap + env LOGGING_LEVEL_ROOT=INFO
Region endpoint values.yaml awsRegion: ap-southeast-2

Helm supports nested values, conditionals, and range loops, which makes it easy to expose optional features such as a sidecar for log shipping to an Elasticsearch cluster in Melbourne. Secrets should never live in plain text inside the chart; use Sealed Secrets, External Secrets Operator, or a managed vault so credentials stay encrypted at rest, satisfying internal security policies and guidance from the Office of the Australian Information Commissioner.

Rolling out to a Kubernetes cluster

With the chart packaged, install it into a target namespace using helm install springboot-app ./chart --namespace prod --create-namespace. Helm renders the templates, sends them to the Kubernetes API, and records the release. Subsequent upgrades use helm upgrade --install, which atomically applies the diff and rotates pods when the pod template changes.

Monitoring the rollout matters as much as the deployment itself. Wire the actuator endpoints into Prometheus, scrape them with the kube-prometheus-stack, and alert on http_server_requests_seconds_count anomalies. If a release misbehaves, helm rollback springboot-app 1 restores the previous revision within seconds, which is the safety net a payments team needs when a midnight deploy in Sydney affects customers logging in from Adelaide.

Operational best practices for Kubernetes-native Java services

Treat the chart as code: store it in the same repository as the application, run helm lint in CI, and version it with Conventional Commits so audit trails under APRA CPS 234 remain clear. Pinning an appVersion to the image tag prevents confusion when several releases live side by side in the same namespace. These small disciplines turn a chart from a one-off script into a reusable artefact that new joiners can understand.

Beyond versioning, a handful of habits keep the pipeline reliable once the first release is live. Teams that operate across Australian regions particularly benefit from immutable tags and explicit rollback drills: