A dependency install leaves the hosting decision open
Gitea can put repositories, code review, issues and packages on infrastructure your team controls. The README describes those capabilities and CI/CD that can reuse GitHub Actions. The adoption question is whether your team can operate that service and preserve the workflow behavior it needs.
Our recorded run answers a narrower question: the selected pnpm dependency-install step completed. It does not establish that Gitea's Go server built, started or accepted a push.
What our recorded run established
The run took place on 2026-10-11 at commit 8a9e8c4e8ce3d535e98ea775fdf994b66ce5dd40. The install step exited successfully after 24,579 ms, rounded to 25 seconds in the stored summary. The parser recorded 881 dependencies and a 612 MB installation footprint. These are development-installation measurements, not production image size, repository storage requirements or hosting performance.
The install output ends with "Done in 3.8s using pnpm v12.8.1". That internal pnpm timing and the harness's full step duration measure different scopes. Neither is a server-startup measurement. The complete harness run was recorded as 45 seconds.
The checkout measured 33 MB across 6,351 files and approximately 547,283 source lines. Detection found Node, Python and Go but selected Node/pnpm as the primary path. It also recorded a Makefile, 18 CI workflow files, a Dockerfile, a tests directory and workspaces. These are parser observations, not evidence that any upstream checks passed.
Build and test steps were skipped with the reason "no script". This does not mean Gitea has no build step or runnable tests. Its README explicitly points to build prerequisites, local development, linting, testing and source-build instructions. The recorded run contains no compiler result, passing-test count, installed-binary check, server-startup check, Git workload or Actions execution. No audit result or coverage was recorded.
The sandbox configuration was 3 CPUs, 8 GB memory and image lab-node:22. The image name does not establish the runtime version actually used. There was no new execution for this correction.
Deployment needs persistent data
The Docker installation guide describes a persistent volume and browser-based installation. SQLite can serve the basic setup without a separate database service; the guide also provides MySQL and PostgreSQL configurations. These are documented deployment routes, not configurations tested in our sandbox.
For host volumes, match ownership to the configured UID and GID. The documentation warns that incorrect permissions may prevent startup and that rootful and rootless images are not interchangeable by changing the image value. The README also distinguishes dynamic settings from static app.ini settings, which require an instance restart.
Check Actions behavior before migrating
Gitea Actions delegates jobs to a separately deployed runner. Treat the runner as another service your team must configure and maintain.
The GitHub Actions comparison identifies differences that can affect a release process. Job environments are ignored. GitHub-only permission scopes, including id-token, are unsupported. The guide also says GITEA_TOKEN cannot publish to its repository's package registry and directs users to a personal access token instead.
Review workflows that rely on deployment environments, identity tokens or package publishing before moving a release repository. Successful parsing alone would not demonstrate equivalent behavior. We did not execute workflows in this run.
Rehearse recovery before relying on the host
The backup and restoration guide requires stopping the instance for backup consistency. Its explanation is concrete: a database dump and a repository copy can disagree if a migration is in progress.
Restoration is documented as a manual process involving files and a database dump. The guide warns about possible restoration problems with XORM-generated database dumps and discusses native database tools. It also calls for regenerating repository hooks when installation paths or methods change.
A useful next step is a recovery rehearsal on a separate instance, followed by a Git push check. That is a recommendation, not a test completed for this review.
Choose alternatives by workflow
Gogs lists repository issues, pull requests, protected branches and mirroring. Consider it when those collaboration features match your requirements and you will evaluate automation separately. Its README does not give us a measured comparison with Gitea.
GitLab Community Edition is identified as freely available under the MIT Expat license. The repository overview describes merge requests and CI/CD pipelines. Consider it when retaining a GitLab pipeline workflow matters, while checking which edition provides each required feature. We have no comparative resource-use or security measurement supporting a preference between GitLab and Gitea.
How to read the scores
These are editorial ratings of the evidence available for this review, not benchmark results. Across each category, 1 means insufficient evidence for an adoption recommendation; 2 means documented capability or support routes with substantial uncertainty; 3 means concrete guidance or a bounded successful observation with important checks remaining; 4 requires broader corroboration; and 5 requires comprehensive evidence within the stated scope. Missing measurements do not establish a product defect.
Setup receives 3/5 because dependency installation completed and deployment guidance is concrete, but server operation was not checked. Documentation receives 3/5 because the supplied instructions explain deployment, compatibility and recovery limits, although we did not execute those procedures. Community receives 2/5 because the README identifies contribution and support routes without establishing response quality or current adoption. Maturity receives 3/5 because the supplied documentation covers operational concerns, while our run leaves runtime behavior and recovery unverified.