An AI development team: GitHub or Gitea?
Updated October 31, 2026. Design guidance and source-inspection notes, not a newly rehearsed deployment tutorial.
The useful pattern is not “let five models loose.” It is a small chain of inspectable handoffs:
Issue → bounded triage and plan → approval → branch and implementation → cross-family review → real CI checks → human merge and deployment decision.
Triage and planning may be one step. Testing often needs ordinary tools rather than another model. Deployment can be automated after the appropriate approval, but a reviewer saying “looks good” is not permission to release.
Choose a home for the work
| Choice | Good fit | What you own or must verify |
|---|---|---|
| GitHub and GitHub Actions | Collaborating with external contributors and using hosted repository services | Repository visibility, runner access, service permissions, usage charges, and release gates |
| Self-hosted Gitea and its Actions runner | Controlling repository storage, access, and runner placement | Host maintenance, backups, runner isolation, authentication, action dependencies, and release gates |
Gitea Actions aims for GitHub Actions compatibility, but workflow syntax and behavior are not identical. In particular, do not assume a GitHub deployment-environment approval gate transfers unchanged. Check the documentation for your installed version and exercise both paths. Gitea comparison.
Self-hosted is not automatically offline
You can keep repositories and runners on hardware you control. If an agent then submits code or context to a hosted model, that selected material still leaves the machine. Actions, package downloads, telemetry, and artifact storage also deserve inspection.
A genuinely offline workflow needs local inference, locally available dependencies and actions, and verified network boundaries. A private repository is not an isolation boundary for every process that can read it. See deployment isolation and model routing.
Define the handoff before the automation
- Limit issue intake to the intended sources. Issue text, comments, and pull-request code are untrusted input, not permission grants.
- Give planning only the access it needs. Require a scoped plan and an authorized approval tied to the current issue revision.
- Build on an isolated branch. Do not let the implementation rewrite its own trusted permission rules or publish credentials.
- Review the exact commit against the requirements, ideally with a different model family when useful. Record the model and findings; agreement is not proof.
- Run real project checks. A model's claim that tests passed is not a CI result. Invalidate review when the reviewed commit changes.
- Separate model execution and untrusted project code from write and deployment credentials. Make merge and release permissions explicit.
- Bound retries, concurrent jobs, runtime, and model allowance. Leave an actionable blocker instead of an endless repair loop.
GitHub's secure-use reference explains credential scope, untrusted inputs, and action dependencies. Do not copy private runner credentials or enable a privileged self-hosted runner for arbitrary outside contributions.
What has been inspected here
Adam's May 2026 self-hosted team article already describes the issue-to-plan-to-code-to-review loop. On October 31, source inspection found both Gitea planning/build/review workflows and GitHub planning/build/cross-family-review templates. Their controls and triggers differ; some older Gitea workflows include low-risk automatic plan approval. They are not one identical, universally human-gated implementation.
This inspection does not establish that every current repository has working credentials, a healthy runner, or a successful recent end-to-end release. Before publishing a copyable tutorial, use a disposable sample repository, pin a version, and demonstrate one real change and one deliberately failing check on each platform. Keep private project names and configuration out of that example.