The project has been moved to https://github.com/backstage/charts.
We recommend you to switch to the new Backstage Helm Chart repository as described here.
Backstage is an open platform for building developer portals. Powered by a centralized software catalog, Backstage restores order to your microservices and infrastructure and enables your product teams to ship high-quality code quickly — without compromising autonomy.
Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.
helm repo add backstage https://vinzscam.github.io/backstage-chart
helm install my-release backstage
This chart bootstraps a Backstage deployment on a Kubernetes cluster using the Helm package manager.
- Kubernetes 1.19+
- Helm 3.2.0+
- PV provisioner support in the underlying infrastructure
- Backstage container image
To install the chart with the release name my-backstage-release
:
helm repo add backstage https://vinzscam.github.io/backstage-chart
helm install my-backstage-release backstage/backstage
Tip: List all releases using
helm list
To uninstall/delete the my-backstage-release
deployment:
helm delete my-backstage-release
The command removes all the Kubernetes components associated with the chart and deletes the release.
Name | Description | Value |
---|---|---|
global.imageRegistry |
Global Docker image registry | "" |
global.imagePullSecrets |
Global Docker registry secret names as an array | [] |
global.storageClass |
Global StorageClass for Persistent Volume(s) | "" |
Name | Description | Value |
---|---|---|
kubeVersion |
Override Kubernetes version | "" |
nameOverride |
String to partially override common.names.fullname | "" |
fullnameOverride |
String to fully override common.names.fullname | "" |
clusterDomain |
Default Kubernetes cluster domain | cluster.local |
commonLabels |
Labels to add to all deployed objects | {} |
commonAnnotations |
Annotations to add to all deployed objects | {} |
extraDeploy |
Array of extra objects to deploy with the release | [] |
diagnosticMode.enabled |
Enable diagnostic mode (all probes will be disabled and the command will be overridden) | false |
diagnosticMode.command |
Command to override all containers in the statefulset | ["sleep"] |
diagnosticMode.args |
Args to override all containers in the statefulset | ["infinity"] |
Name | Description | Value |
---|---|---|
backstage.image.registry |
Backstage image registry | "" |
backstage.image.repository |
Backstage image repository (required) | "" |
backstage.image.tag |
Backstage image tag (required immutable tags are recommended) | "" |
backstage.image.pullPolicy |
Backstage image pull policy | IfNotPresent |
backstage.image.pullSecrets |
Specify docker-registry secret names as an array | [] |
backstage.command |
Override Backstage container command | ["node", "packages/backend"] |
backstage.args |
Override Backstage container arguments | ["--config", "app-config.yaml", "--config", "app-config.production.yaml"] |
backstage.extraEnvVars |
Extra environment variables to add to Backstage pods | [] |
backstage.extraAppConfig |
ConfigMap with extra environment variables | [] |
backstage.extraEnvVarsSecrets |
Array of existing secrets containing sensitive environment variables | [] |
Name | Description | Value |
---|---|---|
ingress.enabled |
Enable ingress | false |
ingress.className |
Name of the IngressClass cluster resource (e.g nginx) | "" |
ingress.annotations |
Additional annotations for the Ingress resource | {} |
ingress.host |
Hostname of the backstage application (e.g backstage..nip.io) | "" |
service.type |
Kubernetes Service type | ClusterIP |
service.ports.backend |
Port for client connections | 7007 |
service.nodePorts.backend |
Node port for client connections | "" |
service.sessionAffinity |
Control where client requests go, to the same pod or round-robin | None |
service.clusterIP |
Backstage service Cluster IP | "" |
service.loadBalancerIP |
Backstage service Load Balancer IP | "" |
service.loadBalancerSourceRanges |
Backstage service Load Balancer sources | [] |
service.externalTrafficPolicy |
Backstage service external traffic policy | Cluster |
service.annotations |
Additional custom annotations for Backstage service | {} |
service.extraPorts |
Extra ports to expose in Backstage | [] |
The Backstage Chart makes it possible to configure your backstage instance by passing extra environment variables or static configuration files, without rebuilding the docker image.
Use backstage.extraEnvVars
to pass extra environment variables. This is used for environment variables containing non sensitive information:
backstage:
+ extraEnvVars:
+ - name: MY_PLUGIN_HOST
+ value: http://my-plugin-host
It is possible to override values defined in your app-config.yaml
by appending the APP_CONFIG
prefix to each environment variable, as described in the official documentation.
For example, to override the backend.cache.store
property defined in your app-config.yaml
, do:
backstage:
extraEnvVars:
+ - name: APP_CONFIG_backend_cache_store
+ value: memory
In case your environment variables contain sensitive information, such as BACKEND_SECRET
or POSTGRES_PASSWORD
it is recommended store them in a Kubernetes Secret.
Create a new file named my-backstage-secrets.yaml
containing the secrets you want to store:
# my-backstage-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: my-backstage-secrets
type: Opaque
data:
BACKEND_SECRET: YmFja3N0YWdl
POSTGRES_PASSWORD: aHVudGVyMg==
Make sure to customize the name of the secret by changing metadata.name
properly.
Now create the new secret in your Kubernetes cluster by running the following command:
$ kubectl apply -f my-backstage-secrets.yaml`
Once the secret has been created, pass the secret's reference to your backstage instance by adding the following lines to your values.yaml
:
backstage:
+ extraEnvVarsSecrets:
+ - my-backstage-secrets
The chart will make sure to pass the secrets to your Backstage instance.
A generated Backstage docker image contains some static configuration files, such as app-config.yaml
and app-config.production.yaml
.
It is possible to pass extra configuration files by defining them as ConfigMap, without rebuilding the Docker image.
To do so, run:
$ kubectl create configmap my-app-config --from-file=app-config.extra.yaml=./local/path/to/your/app-config.extra.yaml`
This command parses your local app-config.extra.yaml
and creates a new ConfigMap called my-app-config
which internally contains a file called app-config.extra.yaml
with the content of the parsed file.
Now that the ConfigMap has been created on your Kubernetes cluster, you can reference the ConfigMap:
backstage:
+ extraAppConfig:
+ - filename: app-config.extra.yaml
+ configMapRef: my-app-config
The chart will mount the content of the ConfigMap as a new app-config.extra.yaml
file and automatically pass the extra configuration to your instance.
With the Backstage Helm Chart, it offers - as a subchart - a Bitnami PostgreSQL database. This can be enabled by switching postgresql.enabled
to true (it is false
by default). If switched on, the Helm Chart, on deployment, will automatically deploy a PostgreSQL instance and configure it with the credentials you specify. There are multiple ways of doing this that will be detailed below.
This is the easiest of the configuration options. Here, the credentials for both the Admin and Database users will be automatically generated and put into a Kubernetes secret. This will then be automatically used by Backstage. In order to use this method, ensure the following:
- Keep
postgresql.auth.existingSecret
&postgresql.auth.password
empty.
Here, you can specify the password that you want PostgreSQL to use for its Database User (The user that Backstage will use to connect to the database). In order to use this method, ensure the following:
- Keep
postgresql.auth.existingSecret
empty. - Set
postgresql.auth.password
to your desired User password value.
NOTE: Be careful that you provide this value securely.
Here, you can specify an existing Kubernetes secret that you have created which contains the Password that you want PostgreSQL to use. The secret must be in the same namespace as where you are deploying the Helm Chart. In order to use this method, ensure the following:
- Create the Kubernetes secret with the Password inside.
- Set
postgresql.auth.existingSecret
to the name of the Secret - PostgreSQL by default will look for the relevant Password keys that are set by default here
postgresql.auth.secretKeys
. So make sure that the Keys in the Secret match the defaultsecretKeys
values. More information here - For example, if you want PostgreSQL to use an existing Secret called
my-user-secret
that has the User password that you want to use inside it: make sure that you create a Key inside that secret calleduser-password
(this key can be found herepostgresql.auth.secretKeys.userPasswordKey
). i.e.user-password=Password123
.