This Helm chart deploys the Lago billing system with optional dependencies on MinIO. Below are details about configuring the chart for different environments.

• Kubernetes 1.19+
• Helm 3.5+
• Persistent storage provisioner enabled in the cluster
• Optionally: Minio service for staging environments

⚠️ Please note that we strongly recommend to use managed PostgreSQL, Redis and S3 in a production environment.

To install the chart with the release name my-lago-release:

helm install my-lago-release .

You can customize the installation by overriding values in values.yaml with your own. The full list of configurable parameters can be found in the following sections.

helm install my-lago-release . \
  --set apiUrl=mydomain.dev \
  --set frontUrl=mydomain.dev

You can use the provided Taskfile.yaml to easily set up a local development environment with Task.

• Task installed (brew install go-task or see their docs)
• kind (Kubernetes in Docker)
• kubectl
• helm
• ct (chart-testing)
• helm-unittest

• List all task: task --list
• Run end to end tests: task e2e
• Run lint: task lint
• ...

Note on Readiness Probes: Currently, readiness probes are not explicitly configured for any of the components in this Helm chart.

When deploying MinIO with this Helm chart, it is recommended to align the fullnameOverride and the name of the first bucket with the release name to ensure proper resource naming and organization.

If you are installing the release with the name old-lago:

helm install old-lago ./lago-helm-charts --values value_old.yaml

Your values.yaml for MinIO should include:

minio:
  enabled: true
  fullnameOverride: "old-lago-minio"  # Matches the release name
  buckets:
    - name: "old-lago-minio"          # Matches the fullnameOverride
      policy: none
      purge: false
      versioning: false
      objectlocking: false
  endpoint: "http://minio.yourdomain.tld"

• fullnameOverride: This parameter allows you to set a custom name for MinIO resources. For better traceability, align it with the release name.
• First Bucket Name: The first bucket in the buckets list should match the fullnameOverride to ensure consistent bucket naming conventions.
• Ingress Configuration: Make sure the hosts in the ingress section match your MinIO endpoint URL.

The chart supports using an existing secret to store sensitive values such as database URLs, Redis URLs, AWS keys, and SMTP credentials. To use an existing secret, set the global.existingSecret parameter to the name of the secret. If you use an existing secret, the following keys are expected:

• databaseUrl (required)
• redisUrl (required)
• awsS3AccessKeyId (optional)
• awsS3SecretAccessKey (optional)
• smtpUsername (optional)
• smtpPassword (optional)
• googleAuthClientId (optional)
• googleAuthClientSecret (optionals)

If you want to provide an existing secret for the encryption keys, you can also set the encryption.existingSecret parameter to the name of the secret. The following keys are expected:

• encryptionPrimaryKey (required)
• encryptionDeterministicKey (required)
• encryptionKeyDerivationSalt (required)

We strongly recommend using either Amazon S3 alternatives for object storage when deploying Lago. These solutions provide reliable, scalable storage that can be accessed by multiple pods without encountering issues.

If neither S3 nor MinIO is configured, the system will default to using a Persistent Volume Claim (PVC). However, this approach is strongly discouraged as it can lead to issues such as multi-attach errors when volumes are accessed by more than one pod simultaneously. For this reason, it is important to configure S3 or MinIO to avoid potential complications with PVCs.

By opting for S3 or alternatives, you ensure better reliability and scalability for your deployment.

For additional customization, refer to the comments in values.yaml.

To uninstall/delete the my-lago-release:

helm delete my-lago-release