GOTRS 0.5.1 shipped with a production-ready Helm chart. Here’s what went into making it robust.

The Problem

We started with Kustomize manifests in a k8s/ directory. They worked for simple deployments but became unwieldy as configuration options grew. Database selection, replica counts, resource limits, ingress configuration - each variation required overlay files.

Users wanted to deploy to Kubernetes without becoming experts in our directory structure. They wanted helm install and reasonable defaults.

Our Solution

We built a proper Helm chart with sensible defaults and extensive customisation options:

Tag Mirroring - The chart’s appVersion matches the git ref. Install --version main and you get :main images. Install --version v0.5.1 and you get :v0.5.1 images. No separate image tag configuration.

Database Selection - MySQL by default, PostgreSQL via database.type. Same schema, same code, your choice of engine.

Security Contexts - readOnlyRootFilesystem, allowPrivilegeEscalation: false, capabilities: drop: [ALL]. These should be defaults. Our chart makes them defaults.

HPA Support - Horizontal Pod Autoscaler with CPU and memory targets. Scale automatically under load.

Extra Resources - Need a ServiceMonitor for Prometheus? The extraResources value accepts arbitrary Kubernetes resources with full Helm templating.

The 22 Kustomize files have been retired.

The Benefits

Users run helm install gotrs oci://ghcr.io/gotrs-io/charts/gotrs and get a working deployment. Configuration happens through values, not file surgery.

Security defaults mean new deployments start hardened. HPA support means scaling happens automatically.

This release also converted 1,800 queries across 127 files for database portability, and upgraded the thumbnail service to libvips for 4x faster image processing with AVIF/HEIC support.

If you’re deploying applications to Kubernetes, investing in a proper Helm chart pays dividends in operational simplicity.