刘寅生律师1. 为什么我们动了换掉 GitLab 的念头
团队里最早提这事的是后端的老张。那天他要在自己的笔记本上把公司 GitLab 的仓库拉下来改个 bug，结果等容器镜像拉完、服务起来，他先去冲了杯咖啡，回来发现还没起来。这不是段子，是我们真实遭遇。公司那台 GitLab 服务器其实配置不算差：4 核 8G，跑个中小型团队按理说绰绰有余。但实际用起来，内存长期被吃满，动不动就报错，重启一次至少五六分钟，有时候连网页端都打不开，git clone 也是时快时慢。
我们最开始以为是人多导致的，后来一排查才发现，项目仓库也不过几十个，团队也就十几个人。GitLab 本身作为一个全家桶式的 DevOps 平台，带了一堆我们用不着的东西——CI/CD、容器镜像仓库、依赖扫描、安全报表、代码质量分析，甚至还有类似 Trello 的 Issue 板。
这些功能听起来很美好，但问题在于它们全都绑在一个服务里，每一个模块都在按需吃内存、跑后台任务。哪怕你只把 GitLab 装上、不搞任何配置，它光是空载状态下就能让 4G 内存见底。在我们的机器上装完以后，镜像解压完差不多 10GB 磁盘空间没了，内存稳定占用在 4GB 以上。而我们要的核心功能无非就这几个：代码托管、分支管理、权限控制、Merge Request 审阅、简单的问题追踪。有些团队成员甚至不太用网页版操作，基本都是命令行+本地 IDE 的 Git 功能完成流程。
后来机缘巧合，我们接触到了 Gitea——一个从 Gogs 分叉出来的国产开源方案。它把自己定位成"轻量级代码托管工具"，整个服务就一个二进制文件，运行时内存占用一般不超过 200MB，部署时间三分钟。我们的主力服务器上，Docker 方式跑一个实例，磁盘占用量我看了下，大概 600MB 出头。这数据放到一起对比，你根本不需要做太复杂的技术论证就能得出结论。
10GB 对 600MB，不只是数字上的差距，背后反映的是两种完全不同的产品哲学：一个是"什么都要做，但运维成本高、资源占用重"，另一个是"专注核心场景，把资源效率做到极致"。如果你也想换掉自己那台跑得又慢又卡的 GitLab，那我这篇文章基本能帮你把前因后果、迁移步骤和避坑点都讲清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 资源占用对比背后的原理差异
2.1 为什么 GitLab 会占用那么多资源
很多人会认为，GitLab 部署完就只是一个 Web 服务，能有多吃资源？实际拆开来看，GitLab 是一个典型的多进程、多模块架构，部署之后默认会同时拉起十几个子服务协同工作。除了核心的 Web 前端和后端 API 之外，它还包括：
- PostgreSQL 数据库，保存用户、项目、权限、Issue、Merge Request 等所有元数据。
- Redis 缓存，用于处理会话状态、后台队列和缓存热数据。
- Sidekiq 后台任务队列，专门执行异步任务，比如仓库统计、邮件通知、Webhook 触发、CI 队列处理等等。
- GitLab Workhorse，负责处理 Git HTTP 请求、文件上传下载等加速转发逻辑。
- Prometheus 监控采集器，默认会收集自身的运行指标。
- Grafana 面板，展示监控图表，即便你从来不看它，它也照样跑。
每个服务各自占用一份 CPU 和内存资源，之间还要保持网络通信和共享磁盘。所以在 Docker 部署时，GitLab 官方推荐的容器本身就是一个完整的操作系统镜像，里面打包了以上所有组件。而 Gitea 走的是另一条路——它的架构极简到不能再简：一个主进程负责 Web、Git SSH、内部数据库连接，所有功能模块都跑在同一个进程内，不拆分。
从设计初衷来比，GitLab 更像一个集成度极高的 DevOps 平台，它默认你就需要完整的研发生命周期管理功能，所以宁可资源开销大也要把所有模块预置好。而 Gitea 是典型的"够用就好"路线，它把代码托管最核心的部分做到极致，其他扩展能力全部提供可插拔的选项——比如 CI/CD 它本身不内置，而是通过和 Drone、Jenkins 这类外部工具做 Webhook 联动来实现。
这个差异直接体现到最终效果上：GitLab 在任何官方支持的部署方式下都建议至少 4GB 内存，如果是生产环境多人并发，官方推荐 8GB 起步。Gitea 官方只建议 2GB 内存即可流畅运行，实际我们用 1GB 内存的机器也能带得动十几个人的日常使用。
磁盘占用更是差距惊人。GitLab 一个 Docker 镜像的体积在 2.5GB 左右，解压后运行实例通常会占据 6GB 到 10GB 不等，这还不算上 Git 仓库自身、日志文件、依赖缓存的数据。而 Gitea 的运行时主体就一个几十 MB 的二进制文件，加上自定义配置和模板，整体装完占用不超过 500MB 到 600MB。
有人说拿它们这样对比不太公平，毕竟 GitLab 功能多太多了。但这就是现实：大部分中小团队真正高频使用的，只是其中 20% 都不到的能力。为了 20% 的功能付 100% 的资源代价，这笔账怎么算都不划算。
2.2 Gitea 的部署形态和优化思路
从部署方式来看，Gitea 足够灵活。它官方提供三种主流玩法：直接下载二进制包在物理机运行、用 Docker Compose 一键拉起、还有就是通过系统包管理器直接装（比如 apt 或 yum）。
二进制运行方式我印象最深。因为它本身就是一个可执行文件，把文件放在 /usr/local/bin 目录，配好环境变量和服务管理脚本，系统启动时由 systemd 拉起即可。它不需要 Java 运行时、不需要 Ruby、不需要 Node.js，甚至连外部数据库都可以省略——默认使用 SQLite3 嵌入式数据库，单文件存储。这意味着你可以把它装在树莓派、NAS、甚至一台跑着老版本 Ubuntu 的旧笔记本上。
我们的实际部署选择是 Docker Compose 方案。原因很简单：团队已有的服务器上跑着不少 Docker 容器，统一用 Compose 管理环境更一致，重装迁移也只需要备份一个目录即可。和 GitLab 那套庞大的容器编排参数来比，Gitea 的 Compose 配置看起来简直寒酸，但它能解决所有问题。
我需要特别说一下 Gitea 的扩展机制。它有一个名字叫"钩子"（Hook）的东西，分为 Git 钩子和 Web 钩子。比如你可以在仓库里配置 Webhook，当有人提交代码时自动触发你内网的 Jenkins 任务做一次构建。再比如配合 Drone CI，直接在 Gitea 里点击"构建状态"标签页看到流水线进度。这种"核心精简+外部扩展"的思路，既保证了基础功能的轻量，也不用牺牲功能性。
我最喜欢的一点是 Gitea 自带一个"迁移外部仓库"的功能。在创建新仓库时，你可以直接填一个远程仓库地址，比如 GitLab、GitHub、Bitbucket 等平台的已有项目链接。它会自动把仓库内的 Git 历史、分支、标签乃至 Issue 都拉取过来。这个功能在我们切到 Gitea 的时候发挥了巨大作用，后面我会细讲。
2.3 什么样的情况可以换，什么时候劝你别换
在做技术选型替换之前，先搞清楚自己的真实需求边界，比急着动手重要得多。如果你遇到下面这些情况，换成 Gitea 大概率是体验提升