Date: 2026-02-06
This runbook describes a safe migration with clear verification and rollback steps.
- Preferred: "backup/restore" cutover.
- Goal: keep downtime short and predictable.
- Collect current deployment config from
kryptovisor:
- compose/run config
- Gitea version
- data path
- DB type and location
- Decide target hostnames:
gitea.<domain>- decide if SSH clones must be preserved.
- Create the target Kubernetes namespace (
gitea) and storage objects.
- Prepare Kubernetes manifests or Helm values, but do not apply until ready.
- Deploy Gitea in Kubernetes with a new hostname (or internal-only) to validate it boots.
- Verify:
- UI loads
- login works (after restore)
- repo clone/push works (after restore)
- Put old Gitea into maintenance mode / stop writes (announce short downtime).
- Create backup:
- Gitea app data
- DB dump if using Postgres/MySQL
app.ini
- Record backup artifact checksums and storage location.
- Restore database (if applicable).
- Restore
/data into the Kubernetes PVC.
- Verify application config:
ROOT_URL- SSH domain/port (if using SSH clones)
- mailer settings (no secrets in docs)
- Start Gitea and validate:
- UI login
- repo list visible
- clone/push over HTTP(S)
- SSH clone if enabled
- webhooks delivery
- Switch DNS/reverse-proxy to point
gitea.<domain> to the Kubernetes ingress.
- If SSH is used, switch TCP forwarding to new NodePort/endpoint.
- Keep old instance stopped (but intact) for rollback window.
- Create repo
- Push commit
- Create issue/comment
- Webhook delivery test
- Runner registration and a test pipeline (optional)
- After an agreed soak period, archive old docker deployment.