Install on Kubernetes
Deploy Gitea Enterprise to Kubernetes using the upstream Helm chart and container image.
Prerequisites
Section titled “Prerequisites”-
Kubernetes 1.24+ cluster with persistent storage and ingress support.
-
Recommended hardware sized for your expected user base:
Team size (approx.) Memory CPU cores SSD capacity ~10 users 2-4 GB 2-4 cores 50-100 GB ~100 users 4-8 GB 4-8 cores 200-500 GB ~1000 users 16-32 GB 8-16 cores 2-5 TB -
kubectlconfigured for the target cluster. -
Helm 3 installed locally.
-
Access to a container registry that can pull the
commitgo/gitea-eeimage if your cluster requires mirroring. -
Git is bundled inside the Enterprise container image so no extra package install is necessary on the nodes.
-
(Optional) An Enterprise license to enable premium features. Use License Activation to request a trial and upload the license after deployment.
1. Add the Gitea chart repository
Section titled “1. Add the Gitea chart repository”helm repo add gitea https://dl.gitea.io/charts/helm repo updateThe chart documented at gitea/charts supports Enterprise deployments out of the box.
2. Prepare a namespace and secrets
Section titled “2. Prepare a namespace and secrets”kubectl create namespace giteakubectl -n gitea create secret generic gitea-admin \ --from-literal=username=admin \ --from-literal=password='replace-with-strong-password'3. Create a values file
Section titled “3. Create a values file”Save the configuration below as values-enterprise.yaml and adjust domains, storage classes, and database settings for your environment:
image: repository: commitgo/gitea-ee tag: 24.6.0 pullPolicy: IfNotPresent
service: http: type: ClusterIP ssh: type: ClusterIP
ingress: enabled: true className: nginx hosts: - host: gitea.example.com paths: - path: / pathType: Prefix tls: - secretName: gitea-tls hosts: - gitea.example.com
gitea: admin: existingSecret: gitea-admin config: server: DOMAIN: gitea.example.com ROOT_URL: https://gitea.example.com/ SSH_PORT: 3022 database: DB_TYPE: postgres HOST: gitea-postgresql.gitea.svc.cluster.local:5432 NAME: gitea USER: gitea PASSWD: gitea
persistence: size: 20Gi storageClass: standard- Update
tagto the Enterprise release you plan to deploy. - Upload the Enterprise license manually after deployment (see License Activation).
- Swap the database section for MySQL or PostgreSQL according to the chart reference.
MySQL override
Section titled “MySQL override”If your cluster provides MySQL or MariaDB, replace the gitea.config.database section:
gitea: config: database: DB_TYPE: mysql HOST: mysql.internal:3306 NAME: gitea USER: gitea PASSWD: gitea-secret SSL_MODE: disableAdd CA certificates or MySQL client configuration via additionalConfigSources when TLS or custom SSL modes are required.
4. Install the release
Section titled “4. Install the release”helm upgrade --install gitea gitea/gitea \ --namespace gitea \ -f values-enterprise.yamlVerify that the pods are running and the ingress is reachable:
kubectl -n gitea get podskubectl -n gitea get ingress5. Post-installation tasks
Section titled “5. Post-installation tasks”- Sign in to
https://gitea.example.com/with the admin credentials stored ingitea-admin. - Complete License Activation.
- Configure object storage, SMTP, and other integrations using the upstream Helm values.
- Review the upstream Configuration Cheat Sheet for the full list of
app.inioptions and apply them via Helm values oradditionalConfigSources.
6. Upgrades and maintenance
Section titled “6. Upgrades and maintenance”- Update the
image.tagin your values file to the newer Enterprise version, then rerun thehelm upgradecommand. - Back up the persistent volume and database before applying upgrades.
- Use
helm diff upgrade(with the diff plugin) to preview manifest changes in CI/CD pipelines. - Monitor the pods with
kubectl logsand standard Kubernetes observability tooling. - Plan high availability by scaling Redis, object storage, and load balancing components according to your Kubernetes topology and recovery objectives.
Gitea Enterprise follows the same chart structure across releases, so existing GitOps workflows only need the image override to adopt Enterprise features.