forgejo-contrib/forgejo-helm

Archived

Watch7

Star27

Fork

You've already forked forgejo-helm

9

CodeIssuesReleases 75Packages 1Activity

Migratedhttps://code.forgejo.org/forgejo-helm/forgejo-helm

forgejogiteahelmhelm-charthelm-charts

This repository has been archived on 2026-01-22. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.

1,609 commits2 branches155 tags 2.3 MiB

• Smarty 74.6%

• JavaScript 23.6%

• Makefile 1.6%

• Shell 0.2%

  main

Find a file

HTTPS Download ZIPDownload TAR.GZDownload BUNDLEOpen with VS CodeOpen with VSCodiumOpen with Intellij IDEA

|

Renovate Bot[ 91fcfc2735

](/forgejo-contrib/forgejo-helm/commit/91fcfc2735b2919506179e4b1aff90bb00768251)chore(deps): update dependency prettier to v3.8.0 (main) (#1463) ...

Co-authored-by: Renovate Bot <[email protected]>
Co-committed-by: Renovate Bot <[email protected]>

| 2026-01-21 23:34:33 +00:00 | | --- | --- | | .forgejo | ci(deps): update actions/setup-node action to v6.2.0 (main) (#1459) | 2026-01-21 23:07:58 +00:00 | | .husky | build!: use pnpm | 2024-02-07 12:46:49 +01:00 | | .vscode | ci(deps): update dependency helm-unittest to v1.0.3 (main) (#1392) | 2025-10-05 21:36:20 +00:00 | | ci | test: drop v13 test | 2026-01-15 19:44:40 +01:00 | | docs | docs: refactor HA docs (#1347) | 2025-08-19 12:11:13 +00:00 | | e2e | ci: add chart testing (#111) | 2023-12-06 13:09:34 +00:00 | | templates | feat: add dnsPolicy configuration option (#1455) | 2026-01-13 09:35:54 +00:00 | | tools | build: fix changelog generation | 2024-11-01 16:10:12 +01:00 | | unittests | feat: add dnsPolicy configuration option (#1455) | 2026-01-13 09:35:54 +00:00 | | .editorconfig | ci: add more tests | 2023-12-06 14:15:20 +01:00 | | .gitignore | fix(oauth): handle cli flags while configure (#1254) | 2025-05-23 08:12:18 +00:00 | | .helmignore | build!: use pnpm | 2024-02-07 12:46:49 +01:00 | | .lintstagedrc.json | chore(prettier): use experimental cli | 2025-06-30 16:01:04 +02:00 | | .markdownlint.yaml | chore: fix lint settings | 2024-02-07 11:46:40 +01:00 | | .markdownlintignore | build!: use pnpm | 2024-02-07 12:46:49 +01:00 | | .node-version | chore(deps): update node.js to v24.13.0 (main) (#1457) | 2026-01-13 14:06:52 +00:00 | | .npmrc | build!: use pnpm | 2024-02-07 12:46:49 +01:00 | | .prettierignore | build!: use pnpm | 2024-02-07 12:46:49 +01:00 | | .prettierrc.json | docs: fix readme | 2023-12-06 12:05:14 +01:00 | | .yamllint | Format all files with prettier VSCode plugin and add yamllint in CI (#413) | 2023-03-29 05:18:23 +08:00 | | artifacthub-repo.yml | feat: publish to code.forgejo.org/forgejo-helm/forgejo | 2024-05-30 12:41:10 +02:00 | | artifacthub.config.json | chore: add prettier linting | 2023-12-06 14:32:09 +01:00 | | Chart.lock | feat!: drop built-in Valkey charts (#1346) | 2025-08-19 12:07:39 +00:00 | | Chart.yaml | fix(deps): update forgejo docker tag to v14.0.1 (main) (#1462) | 2026-01-17 18:44:35 +00:00 | | CONTRIBUTING.md | feat!: merge upstream changes | 2023-12-06 11:40:55 +01:00 | | LICENSE | chore: add forgejo authors to license file (#716) | 2024-08-09 15:51:48 +00:00 | | Makefile | feat: merge upstream change week 2024-31 (#688) | 2024-07-31 11:02:10 +00:00 | | package.json | chore(deps): update dependency prettier to v3.8.0 (main) (#1463) | 2026-01-21 23:34:33 +00:00 | | pnpm-lock.yaml | chore(deps): update dependency prettier to v3.8.0 (main) (#1463) | 2026-01-21 23:34:33 +00:00 | | README.md | docs: add v16 upgrade notes | 2026-01-15 19:43:12 +01:00 | | renovate.json | chore(renovate): update preset | 2025-09-02 16:14:37 +02:00 | | uv.toml | chore: fix uv.toml format | 2026-01-09 13:31:51 +01:00 | | values.yaml | feat: add dnsPolicy configuration option (#1455) | 2026-01-13 09:35:54 +00:00 |

README.md

Forgejo Helm Chart

• Introduction

• Update and versioning policy

• Dependencies

• Installing

• High Availability

• 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

  • SSH and Ingress

  • SSH on crio based kubernetes cluster

  • Cache

  • Persistence

  • Admin User

  • LDAP Settings

  • OAuth2 Settings

• Configure commit signing

• Metrics and profiling

• Pod annotations

• Themes

• Using Renovate

• Parameters

  • Global
  • strategy
  • Image
  • Security
  • Service
  • Ingress
  • deployment
  • ServiceAccount
  • Persistence
  • Init
  • Signing
  • Gitea
  • app.ini overrides
  • LivenessProbe
  • ReadinessProbe
  • StartupProbe
  • Advanced

• Contributing

• Upgrading

  • To v16
  • To v15
  • To v14
  • To v13
  • To v12
  • To v11
  • To v10
  • To v9
  • To v8
  • To v7
  • To v6

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

Introduction

This Helm chart is based on the Gitea 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 Forgejo helm chart versioning does not follow Forgejo's versioning. The latest chart version can be looked up in https://code.forgejo.org/forgejo-helm/-/packages/container/forgejo or in the repository releases.

The chart aims to follow Forgejo's releases closely. There might be times when the chart is behind the latest Forgejo 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 Forgejo version earlier than this chart catches up, then change the tag in values.yaml to the latest Forgejo version.

Dependencies

Forgejo can be run with an external database and cache.

Installing

helm install forgejo oci://code.forgejo.org/forgejo-helm/forgejo

In case you want to supply values, you can reference a values.yaml file:

helm install forgejo -f values.yaml oci://code.forgejo.org/forgejo-helm/forgejo

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

High Availability

See the HA Setup document for more details.

Configuration

Forgejo offers lots of configuration options. Every value described in the Cheat Sheet can be set as a Helm value. Configuration sections map to (lowercased) YAML blocks, while the keys themselves remain in all caps.

gitea:
  config:
    # values in the DEFAULT section
    # (https://forgejo.org/docs/latest/admin/config-cheat-sheet/#overall-default)
    # are un-namespaced
    #
    APP_NAME: 'Forgejo: Git with a cup of tea'
    #
    # https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repository
    repository:
      ROOT: '~/forgejo-repositories'
    #
    # https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository---pull-request-repositorypull-request
    repository.pull-request:
      WORK_IN_PROGRESS_PREFIXES: 'WIP:,[WIP]:'

Default Configuration

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

INSTALL_LOCK is always set to true because the configuration in this helm chart makes any configuration via installer superfluous.

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

Database defaults

This chart uses the default SQLite database.

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

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

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

• SSH_LOG_LEVEL environment variable is not injected into the container

Session, Cache and Queue

The chart will fall back to the Forgejo 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 Forgejo instance.

For a production-ready single-pod Forgejo instance without external dependencies (using the built-in SQLite):

#values.yml

persistence:
  enabled: true

gitea:
  config:
    indexer:
      REPO_INDEXER_ENABLED: true

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: forgejo-app-ini-oauth
    - configMap:
        name: forgejo-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 forgejo-app-ini-plaintext could look like this.

apiVersion: v1
kind: ConfigMap
metadata:
  name: forgejo-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: forgejo-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 interacting directly 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.

Environment variables need to be prefixed with FORGEJO.

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

gitea:
  config:
    database:
      HOST: my.own.host
  additionalConfigFromEnvs:
    - name: FORGEJO __DATABASE__ PASSWD
      valueFrom:
        secretKeyRef:
          name: postgres-secret
          key: password

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

1. Environment variables prefixed with FORGEJO

2. Additional config sources

3. Values defined in gitea.config

External Database

A supported external database can be used instead of the built-in SQLite. We recommend to use a PostgreSQL or MySQL database if you are planning a longterm use with 5+ active users and more than a few dozen repos.

Best practice is to use an Operator for database deployments, as this approach has many advantages for DB management in k8s compared to a standalone static one.

For Postgres, we can recommend the following ones:

• CloudNative PG
• Crunchy Postgres Operator

For MySQL:

• MySQL k8s Operator
• Vitess

The following values settings must be used to reference an external DB:

gitea:
  config:
    database:
      DB_TYPE: <dbtype> # supported values are mysql, postgres, mssql, sqlite3
      HOST: <host>
      NAME: <name>
      USER: <user>
      PASSWD: <passwd>
      SCHEMA: <schema> # optional

Usually you do not want to pass the credentials directly in the values file. Instead, these can be referenced from a secret via

gitea:
  additionalConfigSources:
    - secret:
        secretName: database

Note that when using this option, all DB options must be set in the secret.

External Redis/Valkey

Tip

For most use cases, the included adapters are fine. We only recommend this for medium-large instances. You can also start with the default ones and migrate at some point via a simple switchover - no data migration is necessary.

Instead of relying on the default adapters for cache & session, external Redis/Valkey instances can be used.

Note

The name adapter 'redis' is hardcoded from within Forgejo and works just fine with a Valkey instance.

gitea:
  queue:
    TYPE: redis
    CONN_STR: redis://<url>:<port>/0?

  cache:
    ADAPTER: redis
    HOST: redis://<url>:<port>/1

  session:
    PROVIDER: redis
    PROVIDER_CONFIG: redis://<url>:<port>/2

Examples for the sentiel and cluster variants:

gitea:
  queue:
    TYPE: redis
    CONN_STR: redis+sentinel://<url>:<port>/0?mastername=<mastername>

  cache:
    ADAPTER: redis
    HOST: redis+sentinel://<url>:<port>/1?mastername=<mastername>

  session:
    PROVIDER: redis
    PROVIDER_CONFIG: redis+sentinel://<url>:<port>/2?mastername=<mastername>

Note

The cluster variant can only use DB '0'

gitea:
  queue:
    TYPE: redis
    CONN_STR: redis+cluster://<url>:<port>/0

  cache:
    ADAPTER: redis
    HOST: redis+cluster://<url>:<port>/0

  session:
    PROVIDER: redis
    PROVIDER_CONFIG: redis+cluster://<url>:<port>/0

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.

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.io/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 [email protected]: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 can be found at gitea/helm-chart#161.

Cache

The chart will fall back to the Forgejo defaults which use "memory" for session and cache and "level" for queue.

Persistence

Forgejo 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: MyAwesomeForgejoClaim

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

Admin User

This chart creates a default admin user (gitea_admin) with a random password. It is also possible to update the password for this user by upgrading or redeploying the chart. You cannot use admin as username.

gitea:
  admin:
    username: 'MyAwesomeForgejoAdmin'
    password: 'AReallyAwesomeForgejoPassword'
    email: '[email protected]'

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

apiVersion: v1
kind: Secret
metadata:
  name: forgejo-admin-secret
type: Opaque
stringData:
  username: MyAwesomeForgejoAdmin
  password: AReallyAwesomeForgejoPassword

gitea:
  admin:
    existingSecret: forgejo-admin-secret

To delete the admin user, set gitea.admin.username to an empty value and delete the user in the UI. gitea.admin.existingSecret must also be unset.

Whether you use the existing Secret or specify a username and password directly, 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://forgejo.org/docs/latest/admin/command-line/#admin are available.

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

gitea:
  ldap:
    - name: MyAwesomeForgejoLdap
      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: forgejo-ldap-secret
type: Opaque
stringData:
  bindDn: CN=ldap read,OU=Spezial,DC=example,DC=com
  bindPassword: JustAnotherBindPw

gitea:
  ldap:
    - existingSecret: forgejo-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 Forgejo 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 are available.

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

gitea:
  oauth:
    - name: 'MyAwesomeForgejoOAuth'
      provider: 'openidConnect'
      key: 'hello'
      secret: 'world'
      autoDiscoverUrl: 'https://forgejo.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: forgejo-oauth-secret
type: Opaque
stringData:
  key: hello
  secret: world

gitea:
  oauth:
    - name: 'MyAwesomeForgejoOAuth'
      existingSecret: forgejo-oauth-secret

Compatibility with OCP (OKD or OpenShift)

Normally OCP is automatically detected and the compatibility mode set accordingly. To enforce the OCP compatibility mode use the following configuration:

global:
  compatibility:
    openshift:
      adaptSecurityContext: force

An OCP route to access Forgejo can be enabled with the following config:

route:
  enabled: true

Configure commit signing

When using the rootless image, the GPG key folder is not persistent by default. If you want commits by Forgejo (e.g. initial commit) to be signed, you need to provide a signing key:

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

By default this section is disabled to maintain backwards compatibility.

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 referring to an existing secret containing the key data with signing.existingSecret.

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

signing:
  existingSecret: custom-forgejo-gpg-key

To use the GPG key, Forgejo needs to be configured accordingly. A detailed description can be found in the 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

Pod annotations

Annotations can be added to the Forgejo 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: forgejo-themes
    secret:
      secretName: forgejo-themes

extraVolumeMounts:
  - name: forgejo-themes
    readOnly: true
    mountPath: '/data/gitea/public/assets/css'

The secret can be created via terraform:

resource "kubernetes_secret" "forgejo-themes" {
  metadata {
    name = "forgejo-themes"
    namespace = "forgejo"
  }

  data = {
    "my-theme.css" = data.http.forgejo-theme-light.body
    "my-theme-dark.css" = data.http.forgejo-theme-dark.body
    "my-theme-auto.css" = data.http.forgejo-theme-auto.body
  }

  type = "Opaque"
}

data "http" "forgejo-theme-light" {
  url = "<raw theme url>"

  request_headers = {
    Accept = "application/json"
  }
}

data "http" "forgejo-theme-dark" {
  url = "<raw theme url>"

  request_headers = {
    Accept = "application/json"
  }
}

data "http" "forgejo-theme-auto" {
  url = "<raw theme url>"

  request_headers = {
    Accept = "application/json"
  }
}

or natively via kubectl:

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

Using Renovate

Care must be taken when using renovate in combination with the image.digest field. A custom "regex" Manager is required to reference the correct underlying image reference. By default, the tag of the rootful image is fetched. This does not play well with image.rootless: true (the default), i.e. renovate fetches the tag of a different images than the one actually in use! This will result in the rooless image being pulled behind the scences, even though image.rootless: true is set.

Here's an examplary values.yml definition which makes use of a digest:

image:
  registry: code.forgejo.org
  repository: forgejo/forgejo
  tag: <tag>
  digest: sha256:f597c14a403c2fdee9a62dae8bae29d6442f7b2cc85872cc9bb535a24cb1630e

To account for this circumstance, .Values.image.tag should be expliclity suffixed with -rootless, e.g., tag: <tag>-rootless.

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

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

Parameters

Global

strategy

Do not use RollingUpdate for strategy.type, it will cause issues with the deployment.

Image

Security

Security context is only usable with rootless image due to image design.

Service

Ingress

Gateway-API HTTPRoute

Route

deployment

Do not set replicaCount greater than 1, Forgejo is not HA ready and this will cause issues with the deployment.

ServiceAccount

Persistence

Init

Signing

Gitea

app.ini overrides

Every value described in the Cheat Sheet can be set as a Helm value. Configuration sections map to (lowercased) YAML blocks, while the keys themselves remain in all caps.

LivenessProbe

ReadinessProbe

StartupProbe

Advanced

Contributing

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

See CONTRIBUTORS GUIDE for details.

Hop into our Matrix room if you have any questions or want to get involved.

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!

To v16

This chart now uses Forgejo v14 by default.

To v15

This chart now uses Forgejo v13 by default.

The admin password is now randomly generated if not set explicitly. Because gitea.admin.passwordMode is set to keepUpdated by default the upgrade will set a new random admin password if you haven't set one explicitly. If you like to disable the admin user you now need to set gitea.admin.username to an empty value.

To v14

PostgreSQL and PostgreSQL HA subcharts have been removed. You need to manually migrate to an external PostgreSQL instance.

Valkey and Valkey Cluster charts have been removed. You need to provide your own instances if you like to continue to use Valkey. This also changes the default issue indexer type back to bleve.

The rationale behind this change is Bitnami's decision to discontinue free images which are the core element of all referenced charts of theirs. Besides, this change also does not align with the open philosophy of Forgejo. In addition, removing included sub-charts reduces maintaince overhead for this chart in general and forces users to think about the desired architecture in more detail rather than just switching a toggle.

If you are using one of the included subcharts, our recommendations are as follows:

• For the Valkey charts: either deploy your own standalone instances (NB: right now, no good alternatives exists yet) or switch to the built-in defaults. You should likely be just fine and not face any usage issues.
• For the DB charts: Migration efforts are needed as the DB is a core compenent of the overall deployment. Regardless of the type, we recommend to follow these steps:
  1. (optional) Plan for a downtime.
  2. Stop the deployment, i.e. scale down the instances to 0 to avoid writes during the migration.
  3. Export a full DB dump. One option to extract the dump out of the cluster is to use kubectl cp. Many operators allow restoring/bootstrapping from a dump in S3, so storing the dump there is advisable.
  4. Decide for an operator.
  5. Check the operator docs how to bootstrap/restore from a dump.

More detailed migrations instructions are out-of-scope for this document as they would differ between operators and DB type. Feel free to open an issue if you need assistance of certain steps are unclear.

We again apologize for the inconvenience this causes but there is no real alternative path for us to take, regardless of whether we would keep sub-charts in general or not.

To v13

This chart now uses Forgejo v12 by default.

The PostgreSQL HA got a major version bump. Please read the migration guide https://artifacthub.io/packages/helm/bitnami/postgresql-ha#to-16-0-0.

Migrated from Redis/Redis Cluster to Valkey/Valkey Cluster charts. While marked as breaking, there should be no need to migrate data explicity. Cache will start to refill automatically.

Forgejo v7 and Forgejo helm chart v7 are now EOL.

To v12

You need Forgejo v11+ to use this Helm Chart version. Forgejo v10 is now EOL.

To v11

PostgreSQL and PostgreSQL HA are now using PostgreSQL v17. Please read PostgresSQL upgrade guide before upgrading.

You need Forgejo v10+ to use this Helm Chart version. Forgejo v9 is now EOL.

ClusterIP is now empty instead of None for http and ssh service. Unsupported api versions for Ingress and PodDisruptionBudget are removed. Ingress and Service are now using named ports. The ReadinessProbe is now using the /api/healthz endpoint.

To v10

You need Forgejo v9+ to use this Helm Chart version. Forgejo v8 is now EOL.

To v9

Namespaces for all resources are now set to common.names.namespace by default.

To v8

You need Forgejo v8+ to use this Helm Chart version. Use the v7 Helm Chart for Forgejo v7.

To v7

The Forgejo docker image is pulled from code.forgejo.org instead of codeberg.org.

To v6

You need Forgejo v7+ to use this Helm Chart version. Use the v5 Helm Chart for Forgejo v1.21.