Gitea Helm Chart

• Introduction
• Update and versioning policy
• Dependencies
  • HA Dependencies
  • Non-HA Dependencies
  • Dependency Versioning
• Installing
• High Availability
• Limit resources
• Configuration
  • Default Configuration
    • Database defaults
    • Server defaults
    • Metrics defaults
    • Rootless Defaults
    • Session, Cache and Queue
  • Single-Pod Configurations
  • Additional app.ini settings
    • User defined environment variables in app.ini
  • External Database
  • Ports and external url
  • ClusterIP
  • SSH and Ingress
  • SSH on crio based kubernetes cluster
  • Cache
  • Persistence
  • Admin User
  • LDAP Settings
  • OAuth2 Settings
• Configure commit signing
• Metrics and profiling
  • Secure Metrics Endpoint
• Pod annotations
• Themes
• Renovate
• Parameters
  • Global
  • strategy
  • Image
  • Security
  • Service
  • Ingress
  • deployment
  • ServiceAccount
  • Persistence
  • Init
  • Signing
  • Gitea
  • LivenessProbe
  • ReadinessProbe
  • StartupProbe
  • valkey-cluster
  • valkey
  • PostgreSQL HA
  • PostgreSQL
  • Advanced
• Contributing
• Upgrading

Gitea is a community managed lightweight code hosting solution written in Go. It is published under the MIT license.

Introduction

This helm chart has taken some inspiration from jfelten's helm chart. Yet it takes a completely different approach in providing a database and cache with dependencies. Additionally, this chart allows to provide LDAP and admin user configuration with values.

Update and versioning policy

The Gitea helm chart versioning does not follow Gitea's versioning. The latest chart version can be looked up in https://dl.gitea.com/charts or in the repository releases.

The chart aims to follow Gitea's releases closely. There might be times when the chart is behind the latest Gitea release. This might be caused by different reasons, most often due to time constraints of the maintainers (remember, all work here is done voluntarily in the spare time of people). If you're eager to use the latest Gitea version earlier than this chart catches up, then change the tag in values.yaml to the latest Gitea version. Note that besides the exact Gitea version one can also use the :1 tag to automatically follow the latest Gitea version. This should be combined with image.pullPolicy: "Always". Important: Using the :1 will also automatically jump to new minor release (e.g. from 1.13 to 1.14) which may eventually cause incompatibilities if major/breaking changes happened between these versions. This is due to Gitea not strictly following semantic versioning as breaking changes do not increase the major version. I.e., "minor" version bumps are considered "major". Yet most often no issues will be encountered and the chart maintainers aim to communicate early/upfront if this would be the case.

Dependencies

Gitea is most performant when run with an external database and cache. This chart provides those dependencies via sub-charts. Users can also configure their own external providers via the configuration.

HA Dependencies

These dependencies are enabled by default:

• PostgreSQL HA (Bitnami PostgreSQL-HA)
• Valkey-Cluster (Bitnami Valkey-Cluster)

Non-HA Dependencies

Alternatively, the following non-HA replacements are available:

• PostgreSQL (Bitnami PostgreSQL)
• Valkey (Bitnami Valkey)

Dependency Versioning

Updates of sub-charts will be incorporated into the Gitea chart as they are released. The reasoning behind this is that new users of the chart will start with the most recent sub-chart dependency versions.

Note If you want to stay on an older appVersion of a sub-chart dependency (e.g. PostgreSQL), you need to override the image tag in your values.yaml file. In fact, we recommend to do so right from the start to be independent of major sub-chart dependency changes as they are released. There is no need to update to every new PostgreSQL major version - you can happily skip some and do larger updates when you are ready for them.

We recommend to use a rolling tag like :<majorVersion>-debian-<debian major version> to incorporate minor and patch updates for the respective major version as they are released. Alternatively you can also use a versioning helper tool like renovate.

Please double-check the image repository and available tags in the sub-chart:

• PostgreSQL-HA
• PostgreSQL
• Valkey Cluster
• Valkey

and look up the image tag which fits your needs on Dockerhub.

Installing

helm repo add gitea-charts https://dl.gitea.com/charts/ helm repo update helm install gitea gitea-charts/gitea 

Alternatively, the chart can also be installed from Dockerhub (since v9.6.0)

helm install gitea oci://registry-1.docker.io/giteacharts/gitea 

To avoid potential Dockerhub rate limits, the chart can also be installed via docker.gitea.com (since v9.6.0)

helm install gitea oci://docker.gitea.com/charts/gitea 

When upgrading, please refer to the Upgrading section at the bottom of this document for major and breaking changes.

High Availability

Since version 9.0.0 this chart supports running Gitea and it's dependencies in HA mode. Care must be taken for production use as not all implementation details of Gitea core are officially HA-ready yet.

Deploying a HA-ready Gitea instance requires some effort including using HA-ready dependencies. See the HA Setup document for more details.

Limit resources

If the application is deployed with a CPU resource limit, Prometheus may throw a CPU throttling warning for the application. This has more or less to do with the fact that the application finds the number of CPUs of the host, but cannot use the available CPU time to perform computing operations.

The application must be informed that despite several CPUs only a part (limit) of the available computing time is available. As this is a Golang application, this can be implemented using GOMAXPROCS. The following example is one way of defining GOMAXPROCS automatically based on the defined CPU limit like 1000m. Please keep in mind, that the CFS rate of 100ms - default on each kubernetes node, is also very important to avoid CPU throttling.

Further information about this topic can be found under this link.

Note

The environment variable GOMAXPROCS is set automatically, when a CPU limit is defined. An explicit configuration is not anymore required.

Please note that a CPU limit < 1000m can also lead to CPU throttling. Please read the linked documentation carefully.

deployment:  env:  # Will be automatically defined!  - name: GOMAXPROCS  valueFrom:  resourceFieldRef:  divisor: "1" # Is required for GitDevOps systems like ArgoCD/Flux. Otherwise throw the system a diff error. (k8s-default=1)  resource: limits.cpu  resources:  limits:  cpu: 1000m  memory: 512Mi  requests:  cpu: 100m  memory: 512Mi 

Configuration

Gitea offers lots of configuration options. This is fully described in the Gitea Cheat Sheet.

gitea:  config:  APP_NAME: "Gitea: With a cup of tea."  repository:  ROOT: "~/gitea-repositories"  repository.pull-request:  WORK_IN_PROGRESS_PREFIXES: "WIP:,[WIP]:" 

Default Configuration

This chart will set a few defaults in the Gitea configuration based on the service and ingress settings. All defaults can be overwritten in gitea.config.

INSTALL_LOCK is always set to true, since we want to configure Gitea with this helm chart and everything is taken care of.

All default settings are made directly in the generated app.ini, not in the Values.

Database defaults

If a builtIn database is enabled the database configuration is set automatically. For example, PostgreSQL builtIn will appear in the app.ini as:

[database] DB_TYPE = postgres HOST = RELEASE-NAME-postgresql.default.svc.cluster.local:5432 NAME = gitea PASSWD = gitea USER = gitea 

Server defaults

The server defaults are a bit more complex. If ingress is enabled, the ROOT_URL, DOMAIN and SSH_DOMAIN will be set accordingly. HTTP_PORT always defaults to 3000 as well as SSH_PORT to 22.

[server] APP_DATA_PATH = /data DOMAIN = git.example.com HTTP_PORT = 3000 PROTOCOL = http ROOT_URL = http://git.example.com SSH_DOMAIN = git.example.com SSH_LISTEN_PORT = 22 SSH_PORT = 22 ENABLE_PPROF = false 

Metrics defaults

The Prometheus /metrics endpoint is disabled by default.

[metrics] ENABLED = false 

Rootless Defaults

If .Values.image.rootless: true, then the following will occur. In case you use .Values.image.fullOverride, check that this works in your image:

• $HOME becomes /data/gitea/git

  see deployment.yaml template inside (init-)container "env" declarations

• START_SSH_SERVER: true (Unless explicity overwritten by gitea.config.server.START_SSH_SERVER)

  see _helpers.tpl in gitea.inline_configuration.defaults.server definition

• SSH_LISTEN_PORT: 2222 (Unless explicity overwritten by gitea.config.server.SSH_LISTEN_PORT)

  see _helpers.tpl in gitea.inline_configuration.defaults.server definition

• SSH_LOG_LEVEL environment variable is not injected into the container

  see deployment.yaml template inside container "env" declarations

Session, Cache and Queue

The session, cache and queue settings are set to use the built-in Valkey Cluster sub-chart dependency. If Valkey Cluster is disabled, the chart will fall back to the Gitea defaults which use "memory" for session and cache and "level" for queue.

While these will work and even not cause immediate issues after startup, they are not recommended for production use. Reasons being that a single pod will take on all the work for session and cache tasks in its available memory. It is likely that the pod will run out of memory or will face substantial memory spikes, depending on the workload. External tools such as valkey-cluster or memcached handle these workloads much better.

Single-Pod Configurations

If HA is not needed/desired, the following configurations can be used to deploy a single-pod Gitea instance.

1. For a production-ready single-pod Gitea instance without external dependencies (using the chart dependency postgresql and valkey):

   values.yml

   valkey-cluster:  enabled: false valkey:  enabled: true postgresql:  enabled: true postgresql-ha:  enabled: false  persistence:  enabled: true  gitea:  config:  database:  DB_TYPE: postgres  indexer:  ISSUE_INDEXER_TYPE: bleve  REPO_INDEXER_ENABLED: true 

2. For a minimal DEV installation (using the built-in sqlite DB instead of Postgres):

   This will result in a single-pod Gitea instance without any dependencies and persistence. Do not use this configuration for production use.

   values.yml

   valkey-cluster:  enabled: false valkey:  enabled: false postgresql:  enabled: false postgresql-ha:  enabled: false  persistence:  enabled: false  gitea:  config:  database:  DB_TYPE: sqlite3  session:  PROVIDER: memory  cache:  ADAPTER: memory  queue:  TYPE: level 

Additional app.ini settings

The generic section cannot be defined that way.

Some settings inside app.ini (like passwords or whole authentication configurations) must be considered sensitive and therefore should not be passed via plain text inside the values.yaml file. In times of GitOps the values.yaml could be stored in a Git repository where sensitive data should never be accessible.

The Helm Chart supports this approach and let the user define custom sources like Kubernetes Secrets to be loaded as environment variables during app.ini creation or update.

gitea:  additionalConfigSources:  - secret:  secretName: gitea-app-ini-oauth  - configMap:  name: gitea-app-ini-plaintext 

This would mount the two additional volumes (oauth and some-additionals) from different sources to the init container where the app.ini gets updated. All files mounted that way will be read and converted to environment variables and then added to the app.ini using environment-to-ini.

The key of such additional source represents the section inside the app.ini. The value for each key can be multiline ini-like definitions.

In example, the referenced gitea-app-ini-plaintext could look like this.

apiVersion: v1 kind: ConfigMap metadata:  name: gitea-app-ini-plaintext data:  session: |  PROVIDER=memory  SAME_SITE=strict  cron.archive_cleanup: |  ENABLED=true 

Or when using a Kubernetes secret, having the same data structure:

apiVersion: v1 kind: Secret metadata:  name: gitea-security-related-configuration type: Opaque stringData:  security: |  PASSWORD_COMPLEXITY=off  session: |  SAME_SITE=strict 

User defined environment variables in app.ini

Users are able to define their own environment variables, which are loaded into the containers. We also support to directly interact with the generated app.ini.

To inject self defined variables into the app.ini a certain format needs to be honored. This is described in detail on the env-to-ini page.

Prior to Gitea 1.20 and Chart 9.0.0 the helm chart had a custom prefix ENV_TO_INI. After the support for a custom prefix was removed in Gite core, the prefix was changed to GITEA.

For example a database setting needs to have the following format:

gitea:  additionalConfigFromEnvs:  - name: GITEA__DATABASE__HOST  value: my.own.host  - name: GITEA__DATABASE__PASSWD  valueFrom:  secretKeyRef:  name: postgres-secret  key: password 

Priority (highest to lowest) for defining app.ini variables:

1. Environment variables prefixed with GITEA
2. Additional config sources
3. Values defined in gitea.config

External Database

Any external database listed in https://docs.gitea.com/installation/database-prep can be used instead of the built-in PostgreSQL. In fact, it is highly recommended to use an external database to ensure a stable Gitea installation longterm.

If an external database is used, no matter which type, make sure to set postgresql.enabled to false to disable the use of the built-in PostgreSQL.

gitea:  config:  database:  DB_TYPE: mysql  HOST: <mysql HOST>  NAME: gitea  USER: root  PASSWD: gitea  SCHEMA: gitea  postgresql:  enabled: false  postgresql-ha:  enabled: false 

Ports and external url

By default port 3000 is used for web traffic and 22 for ssh. Those can be changed:

service:  http:  port: 3000  ssh:  port: 22 

This helm chart automatically configures the clone urls to use the correct ports. You can change these ports by hand using the gitea.config dict. However you should know what you're doing.

ClusterIP

By default the clusterIP will be set to None, which is the default for headless services. However if you want to omit the clusterIP field in the service, use the following values:

service:  http:  type: ClusterIP  port: 3000  clusterIP:  ssh:  type: ClusterIP  port: 22  clusterIP: 

SSH and Ingress

If you're using ingress and want to use SSH, keep in mind, that ingress is not able to forward SSH Ports. You will need a LoadBalancer like metallb and a setting in your ssh service annotations.

service:  ssh:  annotations:  metallb.universe.tf/allow-shared-ip: test 

SSH on crio based kubernetes cluster

If you use crio as container runtime it is not possible to read from a remote repository. You should get an error message like this:

$ git clone git@k8s-demo.internal:admin/test.git Cloning into 'test'... Connection reset by 192.168.179.217 port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 

To solve this problem add the capability SYS_CHROOT to the securityContext. More about this issue under this link.

Cache

The cache handling is done via valkey-cluster (via the bitnami chart) by default. This deployment is HA-ready but can also be used for single-pod deployments. By default, 6 replicas are deployed for a working valkey-cluster deployment. Many cloud providers offer a managed valkey service, which can be used instead of the built-in valkey-cluster.

valkey-cluster:  enabled: true 

⚠️ The valkey charts do not work well with special characters in the password. Consider omitting such or open an issue in the Bitnami repo and let us know once this got fixed.

Persistence

Gitea will be deployed as a deployment. By simply enabling the persistence and setting the storage class according to your cluster everything else will be taken care of. The following example will create a PVC as a part of the deployment.

Please note, that an empty storageClass in the persistence will result in kubernetes using your default storage class.

If you want to use your own storage class define it as follows:

persistence:  enabled: true  storageClass: myOwnStorageClass 

If you want to manage your own PVC you can simply pass the PVC name to the chart.

persistence:  enabled: true  claimName: MyAwesomeGiteaClaim 

In case that persistence has been disabled it will simply use an empty dir volume.

PostgreSQL handles the persistence in the exact same way. You can interact with the postgres settings as displayed in the following example:

postgresql:  persistence:  enabled: true  existingClaim: MyAwesomeGiteaPostgresClaim 

Admin User

This chart enables you to create a default admin user. It is also possible to update the password for this user by upgrading or redeploying the chart. It is not possible to delete an admin user after it has been created. This has to be done in the ui. You cannot use admin as username.

gitea:  admin:  username: "MyAwesomeGiteaAdmin"  password: "AReallyAwesomeGiteaPassword"  email: "gi@tea.com" 

You can also use an existing Secret to configure the admin user:

apiVersion: v1 kind: Secret metadata:  name: gitea-admin-secret type: Opaque stringData:  username: MyAwesomeGiteaAdmin  password: AReallyAwesomeGiteaPassword 

gitea:  admin:  existingSecret: gitea-admin-secret 

Whether you use the existing Secret or specify a user name and password, there are three modes for how the admin user password is created or set.

• keepUpdated (the default) will set the admin user password, and reset it to the defined value every time the pod is recreated.
• initialOnlyNoReset will set the admin user password when creating it, but never try to update the password.
• initialOnlyRequireReset will set the admin user password when creating it, never update it, and require that the password be changed at the initial login.

These modes can be set like the following:

gitea:  admin:  passwordMode: initialOnlyRequireReset 

LDAP Settings

Like the admin user the LDAP settings can be updated. All LDAP values from https://docs.gitea.com/administration/command-line#admin are available.

Multiple LDAP sources can be configured with additional LDAP list items.

gitea:  ldap:  - name: MyAwesomeGiteaLdap  securityProtocol: unencrypted  host: "127.0.0.1"  port: "389"  userSearchBase: ou=Users,dc=example,dc=com  userFilter: sAMAccountName=%s  adminFilter: CN=Admin,CN=Group,DC=example,DC=com  emailAttribute: mail  bindDn: CN=ldap read,OU=Spezial,DC=example,DC=com  bindPassword: JustAnotherBindPw  usernameAttribute: CN  publicSSHKeyAttribute: publicSSHKey 

You can also use an existing secret to set the bindDn and bindPassword:

apiVersion: v1 kind: Secret metadata:  name: gitea-ldap-secret type: Opaque stringData:  bindDn: CN=ldap read,OU=Spezial,DC=example,DC=com  bindPassword: JustAnotherBindPw 

gitea:  ldap:  - existingSecret: gitea-ldap-secret  ... 

⚠️ Some options are just flags and therefore don't have any values. If they are defined in gitea.ldap configuration, they will be passed to the Gitea CLI without any value. Affected options:

• notActive
• skipTlsVerify
• allowDeactivateAll
• synchronizeUsers
• attributesInBind

OAuth2 Settings

Like the admin user, OAuth2 settings can be updated and disabled but not deleted. Deleting OAuth2 settings has to be done in the ui. All OAuth2 values, which are documented under this link, are available.

Multiple OAuth2 sources can be configured with additional OAuth list items.

gitea:  oauth:  - name: "MyAwesomeGiteaOAuth"  provider: "openidConnect"  key: "hello"  secret: "world"  autoDiscoverUrl: "https://gitea.example.com/.well-known/openid-configuration"  #useCustomUrls:  #customAuthUrl:  #customTokenUrl:  #customProfileUrl:  #customEmailUrl: 

You can also use an existing secret to set the key and secret:

apiVersion: v1 kind: Secret metadata:  name: gitea-oauth-secret type: Opaque stringData:  key: hello  secret: world 

gitea:  oauth:  - name: "MyAwesomeGiteaOAuth"  existingSecret: gitea-oauth-secret  ... 

Configure commit signing

When using the rootless image the gpg key folder is not persistent by default. If you consider using signed commits for internal Gitea activities (e.g. initial commit), you'd need to provide a signing key. Prior to PR186, imported keys had to be re-imported once the container got replaced by another.

The mentioned PR introduced a new configuration object signing allowing you to configure prerequisites for commit signing. By default this section is disabled to maintain backwards compatibility.

signing:  enabled: false  gpgHome: /data/git/.gnupg 

Regardless of the used container image the signing object allows to specify a private gpg key. Either using the signing.privateKey to define the key inline, or refer to an existing secret containing the key data by using signing.existingSecret.

apiVersion: v1 kind: Secret metadata:  name: custom-gitea-gpg-key type: Opaque stringData:  privateKey: |-  -----BEGIN PGP PRIVATE KEY BLOCK-----  ...  -----END PGP PRIVATE KEY BLOCK----- 

signing:  existingSecret: custom-gitea-gpg-key 

To use the gpg key, Gitea needs to be configured accordingly. A detailed description can be found in the official Gitea documentation.

Metrics and profiling

A Prometheus /metrics endpoint on the HTTP_PORT and pprof profiling endpoints on port 6060 can be enabled under gitea. Beware that the metrics endpoint is exposed via the ingress, manage access using ingress annotations for example.

To deploy the ServiceMonitor, you first need to ensure that you have deployed prometheus-operator and its CRDs.

gitea:  metrics:  enabled: true  serviceMonitor:  enabled: true   config:  server:  ENABLE_PPROF: true 

Secure Metrics Endpoint

Metrics endpoint /metrics can be secured by using Bearer token authentication.

Note: Providing non-empty TOKEN value will also require authentication for ServiceMonitor.

gitea:  metrics:  token: "secure-token"  enabled: true  serviceMonitor:  enabled: true 

Pod annotations

Annotations can be added to the Gitea pod.

gitea:  podAnnotations: {} 

Themes

Custom themes can be added via k8s secrets and referencing them in values.yaml.

The http provider is useful here.

extraVolumes:  - name: gitea-themes  secret:  secretName: gitea-themes  extraVolumeMounts:  - name: gitea-themes  readOnly: true  mountPath: "/data/gitea/public/assets/css" 

The secret can be created via terraform:

resource "kubernetes_secret" "gitea-themes" { metadata {  name = "gitea-themes"  namespace = "gitea" }  data = {  "my-theme.css" = data.http.gitea-theme-light.body  "my-theme-dark.css" = data.http.gitea-theme-dark.body  "my-theme-auto.css" = data.http.gitea-theme-auto.body }  type = "Opaque" } data "http" "gitea-theme-light" {  url = "<raw theme url>"  request_headers = {  Accept = "application/json" } } data "http" "gitea-theme-dark" {  url = "<raw theme url>"  request_headers = {  Accept = "application/json" } } data "http" "gitea-theme-auto" {  url = "<raw theme url>"  request_headers = {  Accept = "application/json" } } 

or natively via kubectl:

kubectl create secret generic gitea-themes --from-file={{FULL-PATH-TO-CSS}} --namespace gitea 

Renovate

To be able to use a digest value which is automatically updated by Renovate a customManager is required. Here's an examplary values.yml definition which makes use of a digest:

image:  repository: gitea/gitea  tag: 1.20.2  digest: sha256:6e3b85a36653894d6741d0aefb41dfaac39044e028a42e0a520cc05ebd7bfc3f 

By default Renovate adds digest after the tag. To comply with the Gitea helm chart definition of the digest parameter, a "customManagers" definition is required:

"customManagers": [ { "customType": "regex", "description": "Apply an explicit gitea digest field match", "fileMatch": ["values\\.ya?ml"], "matchStrings": ["(?<depName>gitea\\/gitea)\\n(?<indentation>\\s+)tag: (?<currentValue>[^@].*?)\\n\\s+digest: (?<currentDigest>sha256:[a-f0-9]+)"], "datasourceTemplate": "docker", "autoReplaceStringTemplate": "{{depName}}\n{{indentation}}tag: {{newValue}}\n{{indentation}}digest: {{#if newDigest}}{{{newDigest}}}{{else}}{{{currentDigest}}}{{/if}}" } ] 

Parameters

Global

strategy

Image

Security

Service

Ingress

deployment

ServiceAccount

Persistence

Init

Signing

Gitea

LivenessProbe

ReadinessProbe

StartupProbe

valkey-cluster

Valkey cluster and Valkey cannot be enabled at the same time.

valkey

Valkey and Valkey cluster cannot be enabled at the same time.

PostgreSQL HA

PostgreSQL

Advanced

Contributing

Expected workflow is: Fork -> Patch -> Push -> Pull Request

See CONTRIBUTORS GUIDE for details.

Upgrading

This section lists major and breaking changes of each Helm Chart version. Please read them carefully to upgrade successfully, especially the change of the default database backend! If you miss this, blindly upgrading may delete your Postgres instance and you may lose your data!

gitea:  config:  session:  PROVIDER: redis-cluster  PROVIDER_CONFIG: redis+cluster://:gitea@gitea-valkey-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&   cache:  ENABLED: true  ADAPTER: redis-cluster  HOST: redis+cluster://:gitea@gitea-valkey-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s&   queue:  TYPE: redis  CONN_STR: redis+cluster://:gitea@gitea-valkey-cluster-headless.<namespace>.svc.cluster.local:6379/0?pool_size=100&idle_timeout=180s& 

memcached:  enabled: true  postgresql:  enabled: true  mysql:  enabled: false  mariadb:  enabled: false 

gitea: + livenessProbe:  podAnnotations: {} 

ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" - hosts: - - git.example.com + hosts: + - host: git.example.com + paths: + - path: / + pathType: Prefix  tls: [] # - secretName: chart-example-tls # hosts: # - git.example.com 

paths:  - path: /  pathType: Prefix