Gogs

Gogs lets a team host its own Git repositories and use a web interface for the surrounding collaboration. Developers can still clone, push and pull with normal Git clients while the service manages users, permissions and project information. It is useful when a team wants a compact source-hosting service under its own administration. Related products such as Gitea are separate applications, so moving between them requires more than substituting a container image.

Deployment and operating notes

The current Gogs repository identifies a self-hosted Git service with binary releases and project documentation. The retired incubator/gogs chart is a separate deployment package. Do not substitute a similarly related Git forge image on existing Gogs data without a documented migration path; repository files are only part of a forge’s state.

Inventory database, repositories, attachments, application configuration, SSH host keys, hooks, webhooks and authentication integrations. Preserve those together and rehearse restoration before changing server or database versions. Verify both SSH and HTTPS clone and push, permissions, issue data and webhook delivery on a private restored instance. Check the container image’s data paths and ownership before reusing volumes. If moving to another forge, compare its supported import process and identify which users, issues, releases or settings require separate migration. Keep the old instance read-only during final reconciliation and retain backups. A successful clone alone does not prove that access control or the rest of the project history survived.