# Gitea deployment

The team Git service runs as Gitea 1.27.0 on the existing CVM:

- public URL: `https://git.imagebrewing.com`;
- container HTTP bind: `127.0.0.1:13000`;
- persistent data: `/data/gitea/data`;
- database: Gitea-managed SQLite;
- Git transport: HTTPS only; no extra public SSH port;
- anonymous users may browse public repositories;
- account registration requires administrator approval before sign-in.
- daily backup target: `/chucun/wangzhan-production/backups/gitea/`.

The service is intentionally separate from the FlashOps runtime and database.
Back up `/data/gitea/data` before an image upgrade. Pin the image version and
review the Gitea release notes before changing it.

The current server does not have the Docker Compose plugin. The checked-in
`docker-compose.yml` is the declarative service record for future rebuilds;
the running container was created with the equivalent pinned `docker run`
settings. Routine checks and restarts therefore use Docker directly:

```bash
sudo docker ps --filter name=^gitea$
sudo docker restart gitea
sudo docker logs --tail 100 gitea
curl -fsS http://127.0.0.1:13000/api/healthz
```

Install Compose or recreate the container from the checked-in definition only
during a planned maintenance window, after a verified backup.

Nginx terminates HTTPS and proxies to the loopback-only container port. Run
`nginx -t` before every reload. Credentials and API tokens are never stored in
this directory or committed to Git.

`gitea-backup.timer` runs daily at 03:20 Asia/Shanghai with a randomized delay.
It uses Gitea's own dump command, writes the ZIP and SHA-256 sidecar to the
mounted COS bucket, and removes the temporary local dump after a successful copy.
The live repository and SQLite database remain on the local filesystem because
COSFS is a backup destination, not a POSIX database filesystem.