Taiga is a project management platform for agile developers & designers and project managers who want a beautiful tool that makes work truly enjoyable.

This chart is a community effort, and is not endorsed by the taiga project developers.

Be sure to have a working Helm installation with cluster connectivity first.

$ helm repo add mvitale1989-helm-taiga https://mvitale1989.github.io/helm-taiga
$ helm repo update
$ helm install taiga mvitale1989-helm-taiga/helm-taiga --set persistence.enabled=false --set postgresql.persistence.enabled=false

Wait for the taiga and database pods to come up, then execute:

$ kubectl port-forward service/taiga 8080:80

You will now be able to access your taiga instance at http://localhost:8080.

This chart bootstrap a taiga Deployment on a Kubernetes cluster using the Helm package manager. It provisions a basic taiga installation (taiga-events is not currently provisioned), which by default has no persistence, but can be configured to do so.

Check out the official taiga website for informations on how to use and configure your installation.

• Kubernetes 1.10+
• Helm 3+
• Optionally, you can use your own pre-provisioned instance of PostgreSQL, for data storage. This chart provision a dedicated PostgreSQL database for you, by default.
• Optionally, you can rely on a dynamic PV provisioner, for the persistence of both the taiga and PostgreSQL data.

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

$ helm repo add mvitale1989-helm-taiga https://mvitale1989.github.io/helm-taiga
$ helm repo update
$ helm install my-taiga mvitale1989-helm-taiga/helm-taiga

To uninstall/delete the my-taiga release:

$ helm uninstall my-taiga

Refer to the Helm project documentation for more usage notes.

The following table lists the configurable parameters of the helm-taiga chart, and their default values. It also includes some useful options of the deployable PostgreSQL dependency, but any configuration valid for the bitnami/postgresql chart can be used.

Specify each parameter using the --set key=value[,key=value] argument to helm install, or in alternative, persist them inside of a YAML file, which you can then reference during installs/upgrades by using the -f ./values.yaml flag.

By default, this chart deploys both a taiga API server and a PostgreSQL database instance, generating the following PVCs:

• An 8Gi volume dedicated to the taiga media directory
• A 2Gi volume for PostgreSQL storage

You can tune the parameters associated with these volumes, or also choose to rely on already existing volumes instead, by using the persistence and postgresql.persistence parameters.

By default, no storage class is set for these PVCs, so the default dynamic volume provisioner is expected to create the corresponding PV. But you can optionally declare a storageClass name to use, if you prefer.

If needed, you can choose to use an existing PostgreSQL instance instead of provisioning one, by disabling the persistence.deployPostgres parameter, and setting the taiga.db* parameters with the correct address and credentials.

1. Why do i need to explicitly specify taiga.apiserver and taiga.behindTlsProxy? The taiga frontend will need this information, to generate the URLs used for reaching the taiga backend API server (respectively for the host/port and scheme part of the URL). This chart provisions both frontend and backend under the same service, and thus behind the same host/port and scheme, but in the general case the frontend wouldn't know how to find the API server if you didn't specify it in those parameters, as they may be deployed separately.
2. Why do all web clients need to be able to reach what i specified in taiga.apiserver? As mentioned in question 1, the frontend will use those parameters to generate the URLs pointing to the API server. This means that no matter what name you type in your browser to reach the frontend: the web client will attempt to reach the API server backend based on the taiga.apiserver and taiga.behindTlsProxy parameters. Note that despite this, you can still connect to the frontend in any way you prefer (public name, kubectl port-forward, etc): just make sure it's also reachable through the name specified in the taiga.apiserver parameter.
3. Can i configure multiple instances of taiga behind the same name, but with different paths? No, path multiplexing is currenty not supported.

The following configuration is an example that produces a taiga installation, satisfying the following requirements:

• Taiga instance is publicly available, through an ingress controller (requires manual deployment and configuration of an ingress controller on the cluster, e.g. ingress-nginx)
• Automatic provisioning of letsencrypt TLS certificates (requires manual deployment and configuration of cert-manager or equivalent)
• Persistence for both taiga media files and PostgreSQL database (requires manual deployment of a dynamic volume provisioner, e.g. rbd-provisioner)
• Keep the PVCs, when deleting the taiga release.

ingress:
  enabled: true
  annotations:
    kubernetes.io/tls-acme: "true"
  hosts:
  - taiga.mycompany.com
  tls:
  - secretName: tls-taiga
    hosts:
    - taiga.mycompany.com

taiga:
  apiserver: taiga.mycompany.com
  behindTlsProxy: true
  dbName: taiga
  dbUser: taiga
  dbPassword: verySecureDatabasePassword
  emailEnabled: true
  emailFrom: [email protected]
  emailSmtpHost: smtp.gmail.com
  emailSmtpUser: [email protected]
  emailSmtpPassword: verySecureSmtpPassword
  secretKey: verySecureSecretKey

persistence:
  deployPostgres: true
  enabled: true
  size: 50Gi
  annotations:
    "helm.sh/resource-policy": keep

postgresql:
  postgresqlPassword: verySecureDatabasePassword
  persistence:
    enabled: true
    size: 8Gi
  annotations:
    "helm.sh/resource-policy": keep
  networkPolicy:
    enabled: false

Save the above in the values.yaml file, and then deploy your taiga instance on the cluster by executing the following:

$ helm install my-taiga mvitale1989-helm-taiga/helm-taiga -f values.yaml

After everything's been initialized, you will be able to access your taiga instance at https://taiga.mycompany.com.

Be sure to configure a DNS record taiga.mycompany.com, pointing to your ingress controller.