Operations
Runbook 02 — Forgejo (self-hosted git)
Your own private "GitHub", on Vidot, managed by Coolify. The source of deployments.
Access
| Field | Value |
|---|---|
| Web | https://git.soconnective.com (HTTPS Let's Encrypt) |
| Admin user | feedback |
| Password | in your password manager (fs-secrets/forgejo-admin.txt → move it) |
| Main repo | feedback/soconnective |
| Data engine | SQLite (/data/gitea/gitea.db) |
| Coolify service | forgejo (uuid pkvt258fd4sl0zwvh952ucap) |
How the code was pushed
git remote add origin https://git.soconnective.com/feedback/soconnective.git
git push -u origin main # authenticating with Forgejo username/password
⚠️ Durability warning (IMPORTANT)
To start Forgejo headless, app.ini was edited directly inside the container:
INSTALL_LOCK = trueDOMAIN/SSH_DOMAIN=git.soconnective.comSECRET_KEY= (generated; it was empty and caused HTTP 500)
And the domain was set in the Coolify DB (service_applications.fqdn = https://git.soconnective.com:3000).
Risk: if the Forgejo service is redeployed from Coolify, it may regenerate app.ini and leave SECRET_KEY empty again → HTTP 500.
Pending task (hardening): make this durable by adding the following as environment variables on the service in Coolify:
FORGEJO__security__SECRET_KEY= (the current value)FORGEJO__security__INSTALL_LOCK= trueFORGEJO__server__DOMAIN= git.soconnective.com
Emergency fix if Forgejo returns 500 after a redeploy:
C=forgejo-pkvt258fd4sl0zwvh952ucap
KEY=$(docker exec -u git $C forgejo generate secret SECRET_KEY)
docker exec $C sed -i "s|^SECRET_KEY = .*|SECRET_KEY = $KEY|" /data/gitea/conf/app.ini
docker exec $C sed -i 's/INSTALL_LOCK = false/INSTALL_LOCK = true/' /data/gitea/conf/app.ini
docker restart $C
Next step
Connect Coolify to this repo (deploy key) to deploy apps/web automatically (push → build → deploy).