Gitea

Overview

Gitea is a lightweight self-hosted Git service — repositories, pull requests, issues and a built-in package registry. This template deploys one Gitea server (the rootless image) on a persistent volume, a bundled PostgreSQL database from the PostgreSQL template, a public HTTPS endpoint serving the web UI, Git-over-HTTPS and the package registry, and optional Git-over-SSH. The site administrator’s login and Gitea’s three long-lived signing keys are not template values. They come from one dictionary secret you create before installing, so they never pass through Helm and never land in the release. The bundled database’s credentials are internal plumbing: the template builds that secret for you from plain values.

This template deploys into an existing GVC that you already have. It does not create or manage a GVC.

What Gets Created

Resource	Name	Purpose	Optional
Workload	`RELEASE_NAME-gitea`	Gitea server (stateful, 1 replica, container `gitea`): web UI, Git-over-HTTPS and package registry on HTTP `3000`; built-in SSH server on `2222` when SSH is enabled	—
Workload	`RELEASE_NAME-postgres`	Bundled PostgreSQL 18 (stateful, 1 replica, container `postgresql`, TCP `5432`), wired to Gitea automatically	—
Volume Set	`RELEASE_NAME-gitea-vs`	`/var/lib/gitea` — repositories, LFS objects, attachments and SSH host keys on an `ext4` general-purpose SSD volume; a final snapshot is taken when the volume set is deleted and kept 7 days	—
Volume Set	`RELEASE_NAME-pg-vs`	PostgreSQL data	—
Secret	`RELEASE_NAME-gitea-bootstrap`	Opaque secret holding the admin-bootstrap script mounted into the Gitea container	—
Secret	`my-gitea-db-credentials`	Dictionary secret with the bundled database’s `username`, `password` and `database`, built from `postgres.credentials.*`; its name is `postgres.config.credentialsSecretName`	—
Identity	`RELEASE_NAME-gitea-identity`	Bound to the Gitea workload	—
Policy	`RELEASE_NAME-gitea-policy`	Grants the Gitea identity `reveal` on exactly three secrets: the bootstrap script, the database credentials and the auth secret you created	—
Identity	`RELEASE_NAME-pg-identity`	Bound to the database and backup workloads; carries the cloud account binding when backups use AWS or GCP	—
Policy	`RELEASE_NAME-pg-policy`	Grants the database identity `reveal` on the database credentials secret	—
Workload	`RELEASE_NAME-postgres-backup`	Scheduled `pg_dumpall` of the bundled database to S3, GCS or MinIO (cron)	`postgres.backup.enabled: true`

The template creates no credential secret for Gitea itself — the admin login and signing keys live only in the auth secret you create.

Prerequisites

One secret must exist before you install. Secrets are org-level, so no GVC flag is involved.

Create the auth secret

A dictionary secret holding exactly six keys. The three admin* keys create the first site-admin account on first boot; the other three are Gitea’s signing keys:

cpln secret create-dictionary --name GITEA_AUTH_SECRET_NAME \
  --entry adminUsername=gitea_admin \
  --entry adminEmail=admin@example.com \
  --entry adminPassword="$(openssl rand -hex 24)" \
  --entry secretKey="$(openssl rand -hex 32)" \
  --entry internalToken="$(openssl rand -hex 32)" \
  --entry jwtSecret="$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')"

Key	What it is
`adminUsername` / `adminPassword` / `adminEmail`	The first site-admin account, created once at first boot. Its login form is on the public endpoint.
`secretKey`	Encrypts 2FA secrets, access tokens and mirror credentials. Any random string. Cannot be rotated.
`internalToken`	Shared token for Gitea’s internal API. Any random string.
`jwtSecret`	Signs OAuth2 tokens. Must be base64url of exactly 32 bytes (43 characters, no padding). Cannot be rotated.

Set gitea.auth.secretName to this name. Read it back later with cpln secret reveal GITEA_AUTH_SECRET_NAME -o yaml — a bare cpln secret reveal prints only a summary table, not the values.

jwtSecret has a format constraint the other keys do not. It must be base64url of exactly 32 bytes, or Gitea refuses to start. That is what openssl rand -base64 32 | tr '+/' '-_' | tr -d '=' produces, and it is why the command pipes through tr. Do not substitute a hex string or a passphrase for this key.

Create the secret before installing, or the deployment wedges silently. The chart refuses to render when gitea.auth.secretName is blank, but a name pointing at a secret that does not exist installs successfully and then never starts. The container never runs, so cpln logs returns zero lines. The one place the reason appears is status.versions[].message:

cpln workload get-deployments RELEASE_NAME-gitea --gvc GVC_NAME -o yaml

The secret GITEA_AUTH_SECRET_NAME no longer exists. Workload updates are paused until the
secret is added or the reference to the secret removed.

Use get-deployments — plain cpln workload get has no versions key. Creating the missing secret repairs the deployment on its own within several minutes, or run cpln workload force-redeployment RELEASE_NAME-gitea --gvc GVC_NAME to skip the wait.

The bundled database needs nothing created in advance: the template writes its credentials secret from postgres.credentials.*. Pick a database password at install time (see Installation). Database backups are optional and need a bucket plus, for AWS or GCP, a Control Plane cloud account — see Backing Up.

Installation

Install the chart from the marketplace registry, pointing it at the auth secret and replacing the published database-password placeholder:

cpln helm install RELEASE_NAME oci://ghcr.io/controlplane-com/templates/gitea \
  --version 1.2.0 --gvc GVC_NAME \
  --set gitea.auth.secretName=GITEA_AUTH_SECRET_NAME \
  --set postgres.credentials.password='YOUR-STRONG-DB-PASSWORD'

For a second Gitea release in the same org, also set postgres.config.credentialsSecretName to a name unique to that release — secret names are org-wide, and a second release left on the default is refused at install (see Troubleshooting). Or follow the instructions for your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

Each block below is the shipped default for that part of values.yaml.

Image and Resources

image: gitea/gitea:1.27.1-rootless  # rootless variant: runs as UID 1000, built-in SSH server on 2222

resources:
  minCpu: 250m
  minMemory: 512Mi
  maxCpu: 1000m
  maxMemory: 1024Mi

On a stateful workload the ratio of maxCpu to minCpu may not exceed 4:1. Raising maxCpu without raising minCpu can cross that limit and is rejected when the workload is applied.

Storage

volumeset:
  capacity: 20 # initial capacity in GiB (minimum is 10)
  autoscaling:
    enabled: false # set to true to enable volume autoscaling
    maxCapacity: 200 # maximum capacity in GiB when autoscaling is enabled
    minFreePercentage: 10 # minimum free percentage that triggers scaling
    scalingFactor: 1.2 # how much to grow the volume when scaling is triggered

The volume holds repositories, LFS objects, attachments and the built-in SSH server’s host keys. Packages in the registry and LFS objects are stored here too, so size it for your artifacts, not just your source.

gitea:
  auth:
    secretName: my-gitea-auth
  disableRegistration: true  # true = admin-invite only; false = allow open self-registration

gitea.auth.secretName names the prerequisite dictionary secret from Prerequisites. Its admin* keys are consumed once, at first boot: editing the secret later does not change the existing administrator account — see Rotating the Admin Password.

Public Access

publicAccess:
  enabled: true  # HTTPS web UI + Git-over-HTTPS on the auto *.cpln.app endpoint

Public access is on by default: git clone and git push from laptops and CI are the point of the service, self-registration is closed by default, and the admin login is a credential you created rather than a published default. Set publicAccess.enabled: false to keep Gitea inside the GVC and reach the UI through cpln port-forward (see Connecting). A change to publicAccess can take several minutes to take effect — re-test before concluding it did not apply.

Git-over-SSH

ssh:
  enabled: false     # false = Git-over-HTTPS only (public web UI stays up); true = public SSH takes the endpoint
  externalPort: 22   # public port clients connect to (also advertised in SSH clone URLs)
  domain: ""         # advertised SSH host in clone URLs; empty = use the web domain

A workload has exactly one *.cpln.app canonical endpoint. With ssh.enabled: true that endpoint serves Git-over-SSH on ssh.externalPort instead of HTTPS, so the public web UI and Git-over-HTTPS are no longer reachable at it. SSH is therefore off by default, and Git-over-HTTPS supports full clone, push and pull, so most installs never need it.

Enable ssh.enabled: true only if you either serve the web UI through a custom domain, which leaves the canonical endpoint free for SSH, or only need Git-over-SSH. Turning it on makes the public HTTPS web UI unreachable at the *.cpln.app endpoint; the UI stays reachable through cpln port-forward.

When SSH is enabled, Gitea’s built-in SSH server listens on container port 2222 behind a direct TCP load balancer on ssh.externalPort, and the SSH user is git. Clone URLs advertise ssh.domain, or the web host when it is empty — with the default of 22 the repository page shows the familiar form:

git clone git@SSH_HOST:OWNER/REPO.git

Copy the exact URL from the repository’s clone widget rather than assembling it, and add your public key under Settings → SSH / GPG Keys first. Set ssh.domain to a custom domain that points at the SSH endpoint if you want clean git@ URLs that do not change with the endpoint.

With ssh.enabled: false, Gitea’s REST API still reports a placeholder ssh://git@localhost:2222/... clone URL on repository objects. It is cosmetic — the web UI’s clone widget offers only the HTTPS URL — and affects only scripts that read ssh_url from the API.

Internal Access

internalAccess: # internal firewall scope
  type: same-gvc # options: none, same-gvc, same-org, workload-list
  workloads:  # only used when type is same-gvc or workload-list
    #- //gvc/GVC_NAME/workload/WORKLOAD_NAME

Type	Who can reach port `3000` internally
`none`	No workload
`same-gvc`	Every workload in the same GVC
`same-org`	Every workload in the same org
`workload-list`	Only the workloads listed in `internalAccess.workloads`

Bundled Database

The database is internal plumbing: it serves Gitea only, is unreachable from outside the GVC, and no human types its password into a client — so the credentials stay plain values and the template writes them into the dictionary secret named by postgres.config.credentialsSecretName. The password is used as-is, so change it before installing.

postgres:
  image: postgres:18
  credentials:
    username: gitea
    password: change-me-gitea-db
    database: gitea
  config:
    credentialsSecretName: my-gitea-db-credentials
  resources:
    minCpu: 200m
    minMemory: 256Mi
    maxCpu: 500m
    maxMemory: 512Mi
  volumeset:
    capacity: 10 # initial capacity in GiB (minimum is 10)
    autoscaling:
      enabled: false
      maxCapacity: 100
      minFreePercentage: 10
      scalingFactor: 1.2
  internalAccess:
    type: same-gvc

PostgreSQL applies postgres.credentials.* only when its volume is first initialized. Changing them afterwards rewrites the secret but not the running database’s password — rotate inside PostgreSQL first, as described in the PostgreSQL template, then update the value and force a redeployment of RELEASE_NAME-gitea so it reconnects with the new password.

Database Backup

Every knob of the PostgreSQL template is available under postgres.*, including its scheduled backup. It is off by default; enabling it adds one cron workload that runs pg_dumpall and uploads a gzip-compressed dump to your bucket. The job authenticates with the chart-created database credentials secret, and the database identity picks up the bucket-scoped policy or cloud account automatically.

postgres:
  backup: # compatible with Postgres 17+
    enabled: false
    image: ghcr.io/controlplane-com/backup-images/postgres-backup:18.1.0 # tag 18.1.0 = Postgres 18, 17.1.0 = Postgres 17
    schedule: "0 2 * * *"   # daily at 2am UTC

    resources:
      cpu: 100m
      memory: 128Mi

    provider: aws # Options: aws, gcp, or minio

    aws:
      bucket: my-postgres-bucket
      region: us-east-1
      cloudAccountName: my-s3-cloud-account
      policyName: my-postgres-backup-policy # bucket-scoped IAM policy, see README
      prefix: postgres/backups # folder name where your backups will be stored

    gcp:
      bucket: my-postgres-bucket
      cloudAccountName: my-gcs-cloud-account
      prefix: postgres/backups # folder name where your backups will be stored

    minio: # Backup to a self-hosted MinIO workload (or any S3-compatible endpoint)
      endpoint: http://my-minio-workload:9000 # e.g. http://WORKLOAD_NAME:9000 for an internal MinIO template deployment
      bucket: my-postgres-bucket
      # REQUIRED PREREQUISITE SECRET when provider is `minio` — a `dictionary`
      # secret holding `accessKey` and `secretKey`. See Storage setup in the README.
      credentialsSecretName: my-postgres-minio-credentials
      prefix: postgres/backups # folder name where your backups will be stored

The bucket, cloud account and IAM policy steps for each provider are in the PostgreSQL template’s Backing Up section — the keys are identical, nested under postgres.backup. A database dump alone is not a full Gitea backup: repositories, LFS objects and attachments live on the Gitea volume. See Backing Up.

Connecting

What	Address	Notes
Web UI, Git-over-HTTPS, package registry	`status.canonicalEndpoint` of the Gitea workload	Auto-assigned `*.cpln.app` hostname when `publicAccess.enabled: true`. Read it with `cpln workload get RELEASE_NAME-gitea --gvc GVC_NAME -o yaml`.
Local access (public access off)	`http://localhost:3000` through `cpln port-forward RELEASE_NAME-gitea 3000:3000 --gvc GVC_NAME`	Works regardless of the firewall settings.
Git-over-SSH	`git@SSH_HOST:OWNER/REPO.git` on `ssh.externalPort`	Only when `ssh.enabled: true`; see Git-over-SSH.
Internal (same GVC)	`RELEASE_NAME-gitea.GVC_NAME.cpln.local:3000`	Reachable from other workloads per `internalAccess.type`.
Admin login	`adminUsername` / `adminPassword`	`cpln secret reveal GITEA_AUTH_SECRET_NAME -o yaml`
Bundled database	`RELEASE_NAME-postgres.GVC_NAME.cpln.local:5432`	Credentials: `cpln secret reveal my-gitea-db-credentials -o yaml` (or the name you set in `postgres.config.credentialsSecretName`).

To verify from your own machine, read the canonical endpoint and call Gitea’s health endpoint on it — the same path the readiness probe uses:

cpln workload get RELEASE_NAME-gitea --gvc GVC_NAME -o yaml

curl -sS https://CANONICAL_ENDPOINT/api/healthz

With public access off, open a tunnel instead and use http://localhost:3000 in place of the canonical endpoint:

cpln port-forward RELEASE_NAME-gitea 3000:3000 --gvc GVC_NAME

First Run

There is no web install wizard — the chart locks installation and creates the site administrator from your auth secret on first boot.

Open the canonical endpoint (or http://localhost:3000 through the tunnel) and sign in with adminUsername and adminPassword from the auth secret.
Self-registration is closed by default (gitea.disableRegistration: true). Create accounts under Site Administration → Identity & Access → User Accounts, or set gitea.disableRegistration: false and upgrade the release to allow open sign-up.
Create a repository and push to it over HTTPS. The clone widget gives the URL; authenticate with your Gitea username and password, or generate an access token under Settings → Applications.

The administrator account exists in the database from this point on. Changing its password later is done in the Gitea UI, not in the secret — see Rotating the Admin Password.

Operations

Backing Up

The chart schedules no backups of its own. A complete Gitea backup has two halves: the database (users, issues, pull requests, settings) and the Gitea volume (repositories, LFS objects, attachments, packages). Database. Enable the bundled PostgreSQL’s scheduled pg_dumpall with postgres.backup.enabled: true as described under Database Backup, or take a one-off dump through the database container. The dump is base64-encoded in transit because cpln workload exec is not binary-safe:

cpln workload exec RELEASE_NAME-postgres --gvc GVC_NAME --container postgresql --quiet -- \
  sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc | base64' | base64 -d > gitea-db.dump

Gitea volume. Take a snapshot of the volume set before upgrades or risky changes:

cpln volumeset snapshot create RELEASE_NAME-gitea-vs --gvc GVC_NAME --snapshot-name gitea-before-upgrade

Portable full backup. Gitea’s own gitea dump bundles the database and the volume contents into one archive. The commands below are built from the image’s paths (GITEA_APP_INI is set in the container; the container user owns /var/lib/gitea) but have not been exercised against this template — rehearse on a throwaway release first. Write the archive, then stream it out base64-encoded:

cpln workload exec RELEASE_NAME-gitea --gvc GVC_NAME --container gitea -- \
  sh -c 'cd /tmp && gitea -c "$GITEA_APP_INI" dump --file /tmp/gitea-dump.zip'

cpln workload exec RELEASE_NAME-gitea --gvc GVC_NAME --container gitea --quiet -- \
  sh -c 'base64 < /tmp/gitea-dump.zip' | base64 -d > gitea-dump.zip

Back up the auth secret as well: secretKey is the only way to read the 2FA secrets, access tokens and mirror credentials in any database dump.

Restoring a Backup

No restore path has been exercised end to end against this template. The steps are built from the chart’s configuration and the upstream procedure, which upstream itself describes as manual. Verify on a throwaway release before relying on them.

Restore into a fresh release that points at the same auth secret the backup was taken under — a different secretKey makes the restored tokens and 2FA secrets unreadable. Then:

Database. For a scheduled pg_dumpall object, follow the PostgreSQL template’s Restoring a Backup against RELEASE_NAME-postgres.GVC_NAME.cpln.local. For a pg_dump archive taken as above, load it through the database container (--stdin is required):

base64 < gitea-db.dump | cpln workload exec RELEASE_NAME-postgres --gvc GVC_NAME \
  --container postgresql --stdin --quiet -- \
  sh -c 'base64 -d | pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists'

Gitea volume. Either restore the volume set snapshot taken earlier (cpln volumeset snapshot restore — check --help; not exercised here), or unpack a gitea dump archive and copy its repos/ contents to /var/lib/gitea/git/repositories and its data/ contents to /var/lib/gitea/data in the Gitea container, as described in the upstream backup and restore guide.

Regenerate hooks and restart. After repositories are in place, run the upstream post-restore step and restart Gitea so it re-reads the database:

cpln workload exec RELEASE_NAME-gitea --gvc GVC_NAME --container gitea -- \
  sh -c 'gitea -c "$GITEA_APP_INI" admin regenerate hooks'

cpln workload force-redeployment RELEASE_NAME-gitea --gvc GVC_NAME

Rotating the Admin Password

The bootstrap script creates the administrator once; on later starts the account already exists and the secret’s adminPassword is not re-applied. Change the password in the Gitea UI: sign in as the administrator and use Settings → Account. Updating adminPassword in the secret afterwards keeps your records consistent but has no effect on the live account. Never change secretKey or jwtSecret — the first makes every stored 2FA secret, access token and mirror credential permanently unreadable, the second invalidates every issued OAuth2 token.

Upgrading from 1.0.0

Template version 1.0.0 took the admin login and all three security values as plain Helm values and shipped published defaults for every one of them. Version 1.1.0 moved them into the prerequisite auth secret and rejects each old key at render with a message naming its replacement, so the upgrade fails before anything is applied and the running release is left untouched. There are no compatibility fallbacks.

Removed in 1.1.0	Key in the auth secret
`gitea.admin.username`	`adminUsername`
`gitea.admin.password`	`adminPassword`
`gitea.admin.email`	`adminEmail`
`gitea.security.secretKey`	`secretKey`
`gitea.security.internalToken`	`internalToken`
`gitea.security.jwtSecret`	`jwtSecret`

Put your existing values into the secret — do not generate new ones for a live install. Changing secretKey makes every 2FA secret, access token and mirror credential already in the database permanently unreadable, and changing jwtSecret invalidates every OAuth2 token already issued.If your install still carries the published 1.0.0 defaults, everything it has encrypted is protected by values printed in a public repository — and rotating them in place is destructive in exactly the way above. The safe path is a fresh install with new key material and a repository migration onto it. At minimum, change the administrator’s password immediately.

Create the auth secret from your current values

Follow Prerequisites, using the gitea.admin.* and gitea.security.* values your 1.0.0 release was installed with.

Remove the six old keys from your values

Delete gitea.admin.* and gitea.security.*, and set gitea.auth.secretName to the secret’s name.

Apply the 1.1.0 database rename too

A jump straight to 1.2.0 also needs the change under Upgrading from 1.1.0. Then upgrade the release.

Upgrading from 1.1.0

Version 1.2.0 adopted the PostgreSQL template 3.4.1 as its bundled database. That template no longer takes credentials as values, and Gitea absorbed the change rather than passing it on: there is no new prerequisite, only a rename. The database keeps the credentials it was initialized with, so carry the same three values over under the new keys.

Removed key	Replacement
`postgres.config.username`	`postgres.credentials.username`
`postgres.config.password`	`postgres.credentials.password`
`postgres.config.database`	`postgres.credentials.database`

The chart now writes those values into a dictionary secret named by postgres.config.credentialsSecretName (default my-gitea-db-credentials) and hands only the name to the database. Secret names are org-wide, so give each Gitea release its own.

A values file that still carries the old keys fails with the PostgreSQL template’s message, not this template’s. It tells you to create a dictionary secret yourself — ignore that advice here, because this template creates the secret for you. Move the three keys and the upgrade proceeds; the auth secret is unchanged.

Scaling and Availability

Gitea is pinned to one replica. Do not raise it — each replica would get its own repository volume, and there is no shared storage between them.
The first cpln helm upgrade after an install can restart the bundled database, so expect Gitea to be briefly unreachable during it. Treat every upgrade as a short planned outage.
A node failure reschedules the server and reattaches the same volume. The exposure is minutes of downtime, not data loss. The Gitea volume set takes one final snapshot when it is deleted, kept for seven days; it is not snapshotted on a schedule, so use the backup steps above for point-in-time copies.

Troubleshooting

Workload never becomes ready and cpln logs returns nothing

Symptom: the install succeeds, RELEASE_NAME-gitea stays not ready indefinitely, and cpln logs '{gvc="GVC_NAME", workload="RELEASE_NAME-gitea"}' --limit 50 --since 10m returns zero lines.Cause: gitea.auth.secretName names a secret that does not exist, so the container is never started. The reason is visible only in status.versions[].message:

cpln workload get-deployments RELEASE_NAME-gitea --gvc GVC_NAME -o yaml

The secret GITEA_AUTH_SECRET_NAME no longer exists. Workload updates are paused until the
secret is added or the reference to the secret removed.

Fix: create the secret as in Prerequisites. The deployment recovers on its own within several minutes, or run cpln workload force-redeployment RELEASE_NAME-gitea --gvc GVC_NAME.

Gitea restarts at startup complaining about the JWT secret

Symptom: the container starts, exits, and cpln logs shows Gitea failing while decoding the OAuth2 JWT_SECRET.Cause: the jwtSecret key in your auth secret is not base64url of exactly 32 bytes — a hex string or passphrase was used.Fix: this key can be changed safely before any OAuth2 token has been issued. Regenerate it with openssl rand -base64 32 | tr '+/' '-_' | tr -d '=', update the secret, and run cpln workload force-redeployment RELEASE_NAME-gitea --gvc GVC_NAME — a running replica does not pick up a changed secret on its own.

Upgrade fails with 'gitea.admin.username was removed in 1.1.0'

Symptom: cpln helm upgrade stops before touching any resource:

Error: execution error at (gitea/templates/workload.yaml:1:4): gitea.admin.username was removed
in 1.1.0. Put it in the prerequisite dictionary secret named by gitea.auth.secretName
(key: adminUsername) — see the README.

gitea.admin.password, gitea.admin.email, gitea.security.secretKey, gitea.security.internalToken and gitea.security.jwtSecret each produce the same kind of message under their own name.Cause: your values still carry keys that were removed in 1.1.0.Fix: follow Upgrading from 1.0.0. Your running release is unaffected until the upgrade succeeds.

Upgrade fails with 'config.username was REMOVED in postgres 3.4.0'

Symptom: cpln helm upgrade to 1.2.0 stops at render with a message from the bundled PostgreSQL chart:

Error: execution error at (gitea/charts/postgres/templates/workload-postgres.yaml:1:4):
config.username was REMOVED in postgres 3.4.0. Database credentials are no longer values:
create a `dictionary` secret holding the keys `username`, `password` and `database`, and set
config.credentialsSecretName to its name. ...

Cause: your values still set postgres.config.username, postgres.config.password or postgres.config.database, which moved to postgres.credentials.* in 1.2.0.Fix: rename the three keys as in Upgrading from 1.1.0. Do not create a database secret yourself — this template creates it.

Second release refused: 'cannot be updated because it is being managed by a different release'

Symptom: installing a second Gitea release in the same org fails and creates nothing.Cause: both releases render the same database credentials secret name, postgres.config.credentialsSecretName (default my-gitea-db-credentials), and secret names are org-wide. The first release owns it; nothing is shared, overwritten or deleted.Fix: install the second release with --set postgres.config.credentialsSecretName=UNIQUE_NAME.

Admin password changed in the secret but the old one still works

Symptom: you updated adminPassword in the auth secret, but Gitea still accepts the previous password.Cause: the bootstrap script creates the administrator only once; afterwards the password lives in the database, not the secret.Fix: change it in the Gitea UI — see Rotating the Admin Password.

Enabled SSH and the public web UI stopped responding

Symptom: after setting ssh.enabled: true, HTTPS requests to the *.cpln.app endpoint no longer reach Gitea, while git clone over SSH works.Cause: by design — the single canonical endpoint now serves SSH instead of HTTPS. See Git-over-SSH.Fix: serve the web UI through a custom domain, reach it through cpln port-forward RELEASE_NAME-gitea 3000:3000 --gvc GVC_NAME, or set ssh.enabled: false again to get the public web UI back. Allow several minutes for the change to take effect.

Important Notes

Create the auth secret before installing. A reference to a secret that does not exist wedges the workload with no log output; see Prerequisites for the one command that shows the reason.
Never rotate secretKey or jwtSecret after install. The first makes stored 2FA secrets, tokens and mirror credentials permanently unreadable; the second invalidates issued OAuth2 tokens.
jwtSecret must be base64url of exactly 32 bytes — use the command in Prerequisites.
Change postgres.credentials.password before installing. The shipped change-me-gitea-db is a published placeholder used as-is.
Give each Gitea release its own postgres.config.credentialsSecretName. Secret names are org-wide; a second release on the default name is refused at install.
Public SSH and the public web UI cannot share the canonical endpoint — SSH is off by default. See Git-over-SSH.
Do not scale past one replica. Replicas would each get a separate repository volume.
Editing the auth secret after first boot does not change the administrator account. Change the password in Gitea — see Rotating the Admin Password.
cpln helm uninstall deletes both volume sets — repositories and database alike. Your auth secret is yours and is left alone.

External References

Gitea Documentation

Official Gitea product documentation

Configuration Cheat Sheet

Full reference of Gitea configuration options

Backup and Restore

Upstream guidance on gitea dump and the manual restore procedure

Package Registry

Using Gitea’s built-in package registry

Gitea Template

View the source files, default values, and chart definition

Template Catalog

Templates

Gitea

Overview

What Gets Created

Prerequisites

Installation

UI

CLI

Terraform

Pulumi

Configuration

Image and Resources

Storage

Gitea

Public Access

Git-over-SSH

Internal Access

Bundled Database

Database Backup

Connecting

First Run

Operations

Backing Up

Restoring a Backup

Rotating the Admin Password

Upgrading from 1.0.0

Upgrading from 1.1.0

Scaling and Availability

Troubleshooting

Important Notes

External References

Gitea Documentation

Configuration Cheat Sheet

Backup and Restore

Package Registry

Gitea Template

​Overview

​What Gets Created

​Prerequisites

​Installation

UI

CLI

Terraform

Pulumi

​Configuration

​Image and Resources

​Storage

​Gitea

​Public Access

​Git-over-SSH

​Internal Access

​Bundled Database

​Database Backup

​Connecting

​First Run

​Operations

​Backing Up

​Restoring a Backup

​Rotating the Admin Password

​Upgrading from 1.0.0

​Upgrading from 1.1.0

​Scaling and Availability

​Troubleshooting

​Important Notes

​External References

Gitea Documentation

Configuration Cheat Sheet

Backup and Restore

Package Registry

Gitea Template

Overview

What Gets Created

Prerequisites

Installation

Configuration

Image and Resources

Storage

Gitea

Public Access

Git-over-SSH

Internal Access

Bundled Database

Database Backup

Connecting

First Run

Operations

Backing Up

Restoring a Backup

Rotating the Admin Password

Upgrading from 1.0.0

Upgrading from 1.1.0

Scaling and Availability

Troubleshooting

Important Notes

External References