Ghostfolio Helm Chart

This project provides a Helm chart for deploying Ghostfolio: the Open Source Wealth Management Software into any Kubernetes cluster. It integrates the official Docker images built by the Ghostfolio team and hosted on DockerHub. It also includes PostgreSQL and Redis servers that use the Bitnami charts, but it is easy to provide your own.

The charts are built and then published to these project GitHub Pages, allowing anyone to quickly deploy and test the application.

Table of content

• Ghostfolio Helm Chart
  • 1.1. Prerequisite
  • 1.2. Configure the application
    • 1.2.1. Secret management
    • 1.2.2. Use an external PostgreSQL server
    • 1.2.3. Use an external Redis server
    • 1.2.4. Extra manifests
  • 1.3. Install the application
    • 1.3.1. Add the GitHub Helm repository (optional)
    • 1.3.2. Install the chart
      • 1.3.2.1. Install a specific version of Ghostfolio
    • 1.3.3. Verify the deployment
  • 1.4. Uninstall the application
  • 1.5. License
  • 1.6. Contact

1.1. Prerequisite

• A Kubernetes cluster,
• A PostgreSQL server (optional),
• A Redis instance (optional),
• The Helm client installed locally (see Quickstart Guide),
• The kubectl command-line tool installed locally (optionnal, see Install Tools)

back to top

1.2. Configure the application

Like any other Helm chart, the available configuration options can be found in the charts/ghostfolio/values.yaml configuration file. I recommend you to override any values in a dedicated ghostfolio.values.yaml file before deploying the chart:

1. Start by retrieving the chart default values: helm show values charts/ghostfolio > ghostfolio.values.yaml

2. Edit the ghostfolio.values.yaml values, and specially the following ones:

   ghostfolio:
     # ACCESS_TOKEN_SALT and JWT_SECRET_KEY are auto-generated if left empty.
     # See section 1.2.1 for more options.
     ACCESS_TOKEN_SALT: ""
     JWT_SECRET_KEY: ""
   
   # For more information checkout: https://artifacthub.io/packages/helm/bitnami/postgresql
   postgresql:
     enabled: true
     auth:
       username: ghostfolio-user
       password: ghostfolio-password
       database: ghostfolio-db
       secretRef:
         name: "" # When defined, override the .postgresql.auth.username and .postgresql.auth.password keys
         usernameKey: "username"
         passwordKey: "password"
   
   # For more information checkout: https://artifacthub.io/packages/helm/bitnami/redis
   redis:
     enabled: true
     architecture: standalone
     auth:
       enabled: true
       password: redis-password
       secretRef:
         name: "" # When defined, override the .redis.auth.password key
         passwordKey: "password"
   
   ingress:
     enabled: true
     hosts:
       - host: ghostfolio.domain.tld
         paths:
           - path: /
             pathType: ImplementationSpecific

1.2.1. Secret management

By default, ACCESS_TOKEN_SALT and JWT_SECRET_KEY are automatically generated (64-character random strings) on first install. They are preserved across upgrades — if the values are left empty and a secret already exists in the cluster, the existing values are reused.

You have three options:

1. Auto-generated (default): leave ACCESS_TOKEN_SALT and JWT_SECRET_KEY empty.

   ghostfolio:
     ACCESS_TOKEN_SALT: ""
     JWT_SECRET_KEY: ""

2. Explicit values: provide your own strings.

   ghostfolio:
     ACCESS_TOKEN_SALT: mysuperrandomstring
     JWT_SECRET_KEY: mysuperrandomstring

3. Existing secret: reference a pre-existing Kubernetes Secret (e.g. managed by ExternalSecrets, SealedSecrets, or Vault). When set, the chart does not create its own Secret resource. The existing secret must contain at least ACCESS_TOKEN_SALT and JWT_SECRET_KEY keys, plus all other keys the deployment expects (e.g. REDIS_HOST, POSTGRES_HOST, etc.).

   ghostfolio:
     existingSecret: my-ghostfolio-secret
     # Override key names if your secret uses different keys:
     # existingSecretAccessTokenSaltKey: ACCESS_TOKEN_SALT
     # existingSecretJwtSecretKeyKey: JWT_SECRET_KEY

1.2.2. Use an external PostgreSQL server

By default, the chart deploys a PostgreSQL server via a subchart dependency. However, if want to use your own instance, you can set the following values:

postgresql:
  enabled: false
externalPostgresql:
  host: postgres.domain.tld
  port: 5432
  auth:
    username: external-ghostfolio-user
    password: external-ghostfolio-password
    database: external-ghostfolio-db
    secretRef:
      name: "" # When defined, override the .postgresql.auth.username and .postgresql.auth.password keys
      usernameKey: "username"
      passwordKey: "password"
  options: connect_timeout=300&sslmode=prefer

1.2.3. Use an external Redis server

By default, the chart deploys a Redis server via a subchart dependency. However, if want to use your own instance, you can set the following values:

redis:
  enabled: false
externalRedis:
  host: redis.domain.fqdn
  port: 6379
  auth:
    enabled: false
    password: ""
    secretRef:
      name: "" # When defined, override the .redis.auth.password key
      passwordKey: "password"

back to top

1.2.4. Extra manifests

You can deploy additional Kubernetes resources alongside the chart by using the extraManifests value. Each entry is a raw Kubernetes manifest that is templated through Helm:

extraManifests:
  - apiVersion: external-secrets.io/v1beta1
    kind: ExternalSecret
    metadata:
      name: ghostfolio-secrets
    spec:
      refreshInterval: 1h
      secretStoreRef:
        name: vault
        kind: SecretStore
      target:
        name: ghostfolio-secrets
      data:
        - secretKey: ACCESS_TOKEN_SALT
          remoteRef:
            key: ghostfolio
            property: access_token_salt
        - secretKey: JWT_SECRET_KEY
          remoteRef:
            key: ghostfolio
            property: jwt_secret_key

When using extraManifests to create a secret that holds ACCESS_TOKEN_SALT and JWT_SECRET_KEY, combine it with the existingSecret option:

ghostfolio:
  existingSecret: ghostfolio-secrets
  existingSecretAccessTokenSaltKey: ACCESS_TOKEN_SALT
  existingSecretJwtSecretKeyKey: JWT_SECRET_KEY

back to top

1.3. Install the application

To deploy the application using Helm, follow these steps:

1.3.1. Add the GitHub Helm repository (optional)

helm repo add ghostfolio https://bythehugo.github.io/ghostfolio-helm/
helm repo update

1.3.2. Install the chart

helm upgrade --install ghostfolio ghostfolio/ghostfolio -f ghostfolio.values.yaml

You can also install the chart directly from sources:

helm upgrade --install ghostfolio charts/ghostfolio -f ghostfolio.values.yaml

1.3.2.1. Install a specific version of Ghostfolio

If you want to install a specific version of Ghostfolio, you must define the .image.tag key in the values.yaml file or directly inline:

helm upgrade --install --set "image.tag=3.0.1" ghostfolio ghostfolio/ghostfolio

1.3.3. Verify the deployment

kubectl get all -l app=ghostfolio

Replace with your target namespace if you specified one.

back to top

1.4. Uninstall the application

To uninstall the Helm chart and remove all associated resources from your Kubernetes cluster, follow these steps:

1. Identify the release name you used when installing the chart. If you haven't changed the release name, it may be the default or the one you specified during installation.

2. Run the following command to uninstall the release:

   helm uninstall ghostfolio

3. Verify that the resources have been removed:

   kubectl get all -l app=ghostfolio

   This should return no resources related to the uninstalled release.

Note: If you used custom namespaces during installation, include the -n <namespace> flag in the commands:

helm uninstall ghostfolio -n <namespace>
kubectl get all -n <namespace> -l app=ghostfolio

back to top

1.5. License

Distributed under the Apache 2.0 License. See LICENSE for more information.

back to top

1.6. Contact

Hugo CHUPIN - [email protected] - hugo.chupin.xyz - @hugo.chupin.xyz

Project link: https://github.com/ByTheHugo/ghostfolio-helm

back to top