---
title: Deploy Label Studio Enterprise on Kubernetes
short: Install using Kubernetes
tier: enterprise
type: guide
order: 0
order_enterprise: 69
meta_title: Deploy Label Studio Enterprise on Kubernetes
meta_description: Deploy Label Studio Enterprise on Kubernetes, such as on Amazon Elastic Container Service for Kubernetes, to create machine learning and data science projects in a scalable containerized environment.
section: "Install & Setup"
parent_enterprise: "install_enterprise"
Deploy Label Studio Enterprise on a Kubernetes Cluster using Helm 3. You can use this Helm chart to set up Label Studio Enterprise for deployment onto a Kubernetes cluster and install, upgrade, and manage the application.
Your Kubernetes cluster can be self-hosted or installed somewhere such as Amazon EKS. See the Amazon tutorial on how to Deploy a Kubernetes Application with Amazon Elastic Container Service for Kubernetes for more about deploying an app on Amazon EKS.
!!! note
On-prem deployments of Label Studio Enterprise are not supported for Academic licenses.
This high-level architecture diagram that outlines the main components of a Label Studio Enterprise deployment.
!!! warning
Label Studio Enterprise 2.2.9 decommissioned MinIO as a service.
Label Studio Enterprise runs on Python and uses rqworkers to perform additional tasks. Metadata and annotations are stored in a bundled version of PostgreSQL that functions as persistent storage. If you host Label Studio Enterprise in the cloud, use persistent storage in the cloud instead of MinIO.
If you want to install Label Studio Enterprise on Kubernetes and you have unrestricted access to the internet from your K8s cluster, follow these steps.
If you use a proxy to access the internet from your Kubernetes cluster, or it is airgapped from the internet, see how to Install Label Studio Enterprise without public internet access.
This chart has been tested and confirmed to work with the NGINX Ingress Controller and cert-manager. See Set up an ingress controller for Label Studio Kubernetes deployments for more on ingress settings with Label Studio.
Your Kubernetes cluster can be self-hosted or installed somewhere such as Amazon EKS.
To plan the capacity of your Kubernetes cluster, refer to these guidelines.
Label Studio Enterprise has the following default configurations for resource requests, resource limits, and replica counts:
Before you make changes to these values, familiarize yourself with the Resource Management for Pods and Containers guidelines in the Kubernetes documentation.
If you choose to make changes to these default settings, consider the following:
| For this case | Adjust this |
|---|---|
| More than 10 concurrent annotators | Adjust the requests and limits for resources in the app pod |
| Increase fault tolerance | Increase the number of replicas of app and/or rqworker services |
| Production deployment (replicas) | Replicas equivalent or greater than the number of availability zones in your Kubernetes cluster |
The default queue is the most extensive queue. It is recommended to use 4 times more replicas for the default queue compared to the other queues. The other queues (critical, high, low) can have the same number of replicas. You can start with 1 replica for each of them.
Before installing Label Studio, prepare the Kubernetes cluster with kubectl.
Install Label Studio Enterprise and set up a PostgreSQL and Redis databases to store relevant Label Studio Enterprise configurations and annotations using the Helm chart. You must configure specific values for your deployment in a YAML file that you specify when installing using Helm.
Add the Helm chart repository to easily install and update Label Studio.
shell helm repo add heartex https://charts.heartex.com/ helm repo update heartex shell helm search repo heartex/label-studio To configure Label Studio Enterprise to use TLS for end-client connections with PostgreSQL, do the following:
<PATH_TO_CA>, <PATH_TO_CLIENT_CRT> and <PATH_TO_CLIENT_KEY> with paths to your certificates:kubectl create secret generic <YOUR_SECRET_NAME> --from-file=ca.crt=<PATH_TO_CA> --from-file=client.crt=<PATH_TO_CLIENT_CRT> --from-file=client.key=<PATH_TO_CLIENT_KEY>
ls-values.yaml file with your newly-created Kubernetes secret:!!! note
If POSTGRE_SSL_MODE: verify-ca, the server is verified by checking the certificate chain up to the root certificate stored on the client. If POSTGRE_SSL_MODE: verify-full, the server host name will be verified to make sure it matches the name stored in the server certificate. The SSL connection will fail if the server certificate cannot be verified. verify-full is recommended in most security-sensitive environments.
global:
pgConfig:
ssl:
pgSslMode: "verify-full"
pgSslSecretName: "<YOUR_SECRET_NAME>"
pgSslRootCertSecretKey: "ca.crt"
pgSslCertSecretKey: "client.crt"
pgSslKeySecretKey: "client.key"
To configure Label Studio Enterprise to use TLS for end-client connections with Redis, do the following:
<PATH_TO_CA>, <PATH_TO_CLIENT_CRT> and <PATH_TO_CLIENT_KEY> with paths to your certificates:kubectl create secret generic <YOUR_SECRET_NAME> --from-file=ca.crt=<PATH_TO_CA> --from-file=client.crt=<PATH_TO_CLIENT_CRT> --from-file=client.key=<PATH_TO_CLIENT_KEY>
ls-values.yaml file with your newly-created Kubernetes secret:!!! note
In the case if you are using self-signed certificates that host cannot verify you have to set redisSslCertReqs to None
global:
redisConfig:
ssl:
redisSslCertReqs: "required"
redisSslSecretName: "<YOUR_SECRET_NAME>"
redisSslCaCertsSecretKey: "ca.crt"
redisSslCertFileSecretKey: "client.crt"
redisSslKeyFileSecretKey: "client.key"
Use one of these options to set a password and a username for Redis:
1. Password via Kubernetes Secret. Use this when:
* You want to avoid embedding credentials in values.yaml
* You already manage Secrets in your cluster
* You need a simple auth without multiple Redis users and you don't have username
global:
redisConfig:
host: "redis://redis.example.com:6379/1"
password:
secretName: "my-redis-secret" # Kubernetes Secret name
secretKey: "redis-password" # Key inside Secret
2. Username + password in URL. Use this when:
* Redis v.7 or later, and with ACL-enabled users
* You need a dedicated Redis user for permission scoping
* You need a quick, throwaway setup or local testing
global:
redisConfig:
host: "redis://myuser:mypassword@redis.example.com:6379/1"
3. Username in environment variables + password in secret. Use this when:
* Redis v.7 or later, and with ACL-enabled users
* You want to keep the password secret but still specify a username
global:
redisConfig:
host: "redis://redis.example.com:6379/1"
password:
secretName: "my-redis-secret" # Kubernetes Secret name
secretKey: "redis-password" # Key inside Secret
extraEnvironmentVars:
REDIS_USERNAME: "myuser" # Injected into pod env
Use Helm to install Label Studio Enterprise on your Kubernetes cluster. Provide your custom resource definitions YAML file. Specify any environment variables that you need to set for your Label Studio Enterprise installation using the --set argument with the helm install command.
!!! note
If you are deploying to a production environment, you should set the SSRF_PROTECTION_ENABLED: true environment variable. See Secure Label Studio.
From the command line, run the following:shell helm install <RELEASE_NAME> heartex/label-studio -f ls-values.yaml
After installing, check the status of the Kubernetes pod creation:shell kubectl get pods
Restart your Helm release by doing the following from the command line:
shell helm list shell kubectl rollout restart deployment/<RELEASE_NAME>-ls-rqworker shell kubectl rollout restart deployment/<RELEASE_NAME>-ls-app To uninstall Label Studio Enterprise using Helm, delete the configuration.
From the command line, run the following:shell helm delete <RELEASE_NAME>