# CodeFever and the case for hosting your own Git server

> CodeFever Community is a self-hosted Git hosting service written in PHP, distributed under the MIT licence and installable with a single Docker command on a one core machine. It covers merge requests, branch protection, webhooks and an admin console, but the default compose file ships a trivial database password and an old PHP base image.

**PGYER/codefever** — CodeFever 是完全免费开源的 Git 代码托管服务，支持一行命令安装到自己服务器！CodeFever Community Edition (A Self-hosted Git Services)!

- Repository: https://github.com/PGYER/codefever
- Website: https://codefever.cn
- Stars: 2,751 · Forks: 284
- Language: PHP
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/pgyer-codefever

## A Git server sized for one core and one gigabyte

CodeFever Community is a self-hosted Git code hosting service written in PHP, and the design target is unusually small. The README states that it is very fast and that it requires very few server resources, with 1 CPU core and 1 GB of memory being enough to run it, and that the install is lightweight by design with heavy redundant features removed.

The other half of the positioning is that the code is completely open source, with no compiled or encrypted code, and that there are no limits on the number of repositories or on usage. For an organisation that has decided Git hosting belongs on its own servers, the argument is straightforward: a hosted service is one more vendor with one more price list, and a self-hosted one is a PHP application an administrator can read.

The feature list is what you would expect from a serious internal Git server rather than a minimal one. It includes code diff with syntax highlighting, native support for Git branches and tags, merge requests for collaboration, branch protection to make review meaningful, per-member roles and permissions, webhooks for integration with other systems, a super administrator backend for managing projects and users, and a bilingual interface in Chinese and English.

History explains the split in naming. The project was developed and maintained by the PGYER developer service platform, launched in June 2020, and open sourced in February 2022 after nearly two years of work. The open source edition is called CodeFever Community, while the public cloud service continued under the CodeFever name. The README says the community edition keeps most of the features of the hosted product and has been optimised for single machine deployment, and that it receives community contributions alongside updates to the hosted product.

The audience is a team with its own server and a preference for owning its infrastructure. It is not a product for a public code hosting business.

## A PHP application with two Go gateways in front of it

The repository layout shows the architecture more clearly than the prose does, and it is a three part system. The application/ directory holds the PHP application, www/ is the web root, and system/ holds supporting code. Alongside them sit two Go programs, http-gateway/ and ssh-gateway/, which the Dockerfile compiles with the Go toolchain.

The split follows the protocols. Git over HTTP goes through the http-gateway, and Git over SSH goes through ssh-gateway, whose shell directory holds the second Go main. The Dockerfile compiles both with the same two steps, fetching the YAML library and then building the main package:

```bash
go get gopkg.in/yaml.v2
go build main.go
```

Storage is separated into a dedicated git-storage directory, and the compose file mounts a host path for it so the repository data survives a container rebuild. The same is done for the application logs, which land under application/logs. That separation is the operational shape of the whole thing: mutable data lives in two host directories, everything else is disposable image content.

The base image is a PHP and nginx image, and the Dockerfile enables both SSH and cron inside the container, which is why the compose file publishes port 22 alongside port 80. The image also installs git, mariadb-client, sendmail, vim and the YAML PHP extension, and it pulls in Node.js 16.15.1 with corepack enabled, which is used for the front end assets bundled with yarn.lock and package.json.

The result is a single container that serves web, SSH and the build tooling together. That is what makes the one machine install work, and it is also the reason the image is large for what it does.

## The Docker install the compose file describes

The README offers two installation routes, a Docker image install that it recommends as the simplest option requiring a single command, and a from scratch install for people who want to learn the system, do research, or customise it. The actual one line command lives in the Docker installation document, and that document is not reproduced in the README text available here, so the compose file is the concrete reference for what gets installed.

The compose file runs two services, the application and a database. The application half:

```yaml
version: "3"
services:
  codefever:
    image: pgyer/codefever-community-lite:latest
    ports:
      - "80:80"
      - "22:22"
    depends_on:
      - db
    volumes:
      - /data/git-storage:/data/www/codefever-community/git-storage
      - /data/logs:/data/www/codefever-community/application/logs
```

The environment block that configures the database connection follows:

```yaml
    environment:
      DB_HOST: "db"
      DB_PORT: "3306"
      DB_USER: "root"
      DB_PASS: "123456" # Need to be the same as MYSQL_ROOT_PASSWORD
      DB_NAME: "codefever_community"
```

The database service is MySQL 5.7.31 with a data volume at /data/mysql, a root password that must match the application side, and server flags for utf8mb4 and a maximum of 3000 connections:

```yaml
  db:
    image: mysql:5.7.31
    restart: always
    volumes:
      - /data/mysql:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: "123456"
```

Two things in that file need attention before any deployment. The database password is the literal string 123456, and the application connects as the MySQL root user, so the shipped configuration gives the web application full database privileges with a guessable credential. The image is also tagged latest, which means a redeploy can pull a different build than the one you tested. The README does document a separate update path that keeps existing data, so upgrades are a supported operation rather than a reinstall, and the configuration lives in config.template.yaml and env.template.yaml, both of which are shipped as templates rather than filled in files.

## Merge requests, branch protection and the Git feature set

The collaboration features are the reason this is more than a git-http-backend wrapper, and they are what a team actually notices after the install.

Merge requests are supported, which is the pull request model under a different name, and the README pairs it with native support for Git branches and tags so the branch model is not hidden behind a proprietary abstraction. Branch protection exists to make code review enforceable, which in practice means protected branches that cannot be pushed to directly. Roles and permissions are set per member, so a team can distinguish a member from a maintainer without touching the Git server configuration. Webhooks are supported for integration with other systems, which covers the common case of triggering a pipeline on push.

The administrative layer is where a hosted service earns its keep, and CodeFever has one: a super administrator backend where a team leader manages all projects and user information. For an organisation hosting several teams, that is the difference between a single shared repository space and a managed internal service.

The Git operations themselves are documented separately from the rest of the usage material, with a Git page among the documentation links alongside repository, repository group and administrator settings pages, plus a common questions page. The README states that new formats and features are accepted as issues, and the contribution section asks for a bug or feature request to be raised before code is sent, with the issue referenced in the pull request, and it asks for tests to be run before submitting.

The test setup in the repository is a little uneven. There is a phpunit.xml, a run_test.sh and a tests/ directory for the PHP side, and the front end has a package.json with yarn.lock, but the npm test script in that file is a placeholder that prints an error and exits, and its devDependency is a commitizen plugin for conventional changelog commits rather than a test runner.

## The stack is old where it is thin

Reading the two deployment files as a set, the version choices are the real constraint. The Dockerfile starts from webdevops/php-nginx:7.4, and PHP 7.4 is a branch that has been end of life for years, so the runtime will not receive upstream fixes. The database is pinned to mysql:5.7.31, a specific old tag of a 5.7 series, and the Node.js toolchain is 16.15.1, also long past its supported window. The Go gateway build uses the module-off switch, ENV GO111MODULE=off, which places the code in the pre-module dependency style.

None of that blocks an installation, and for an internal tool pinned to a private network it may not matter. It does mean that the security story depends on your own network perimeter, because the OS and language runtime underneath the application receive no patches from this project.

The other exposure is the network shape. The service publishes port 80 and port 22 directly from the container, with no reverse proxy or TLS termination in the compose file, and the README does not document how HTTPS is added for a public deployment. A team that puts this on a public IP is terminating TLS somewhere else, and that somewhere else is not described in the files here.

The code layout also deserves a note for anyone tempted to patch it. The application is PHP, the gateways are Go, the front end is built with Node and yarn, and the image compiles the Go binaries at build time from a clone of the repository. Reading and changing the system is feasible. Rebuilding it is a heavier operation than the one command install suggests, because the build pulls source, a Go toolchain, and a Node toolchain into one image.

## Community edition, Chinese first documentation, no releases

The documentation situation is the most likely friction point for an English speaking adopter. The README states that the English documentation is still being improved and invites documentation contributions, and the documentation tree in the repository is organised under doc/ with a zh-cn path segment, which indicates that the Chinese version is the primary one and the English one is a translation in progress. The README also links an English variant, README_EN.md, at the repository root.

The project's own status is described clearly enough to be useful. The open source edition is CodeFever Community, it retains most of the features of the hosted CodeFever service, and it is optimised for single machine deployment. The hosted product continues to exist separately, and the README says the community edition receives contributions from the community alongside updates to the hosted product. For an evaluator, the practical question is whether the community edition lags the hosted one on features, and the answer in the documentation is that it keeps most of them.

Release discipline is the other gap. The repository has no GitHub releases, so there is no tag to pin and no published changelog. The README has a section on updating that keeps existing data, and the update document lives under doc/zh-cn/installation/update.md, but the version story of the software itself is carried by the branch rather than by tags.

On maintenance, the repository is not archived and the last push was on 2026-10-19. On licensing, the project states that CodeFever Community is fully developed by the PGYER team and released completely under the MIT licence, with its own intellectual property, so there is no need to consider whether it infringes the rights of others. The LICENSE file at the repository root is the authoritative text, and note that the front end package.json separately carries an ISC licence field, which is a packaging default rather than a statement about the project as a whole.

## Conclusion

CodeFever fits a team that wants Git hosting on hardware it controls, with merge requests and branch protection in a small PHP application it can read and patch, and it does not fit a group that needs a public SaaS, an English-first documentation set, or a database password left at the shipped default. Before deploying it, change DB_PASS and MYSQL_ROOT_PASSWORD in docker-compose.yml, and pin the image tag instead of following the latest tag.

## FAQ

### How do I install CodeFever on my own server?

The README recommends the Docker image install, which it says takes a single command, and also documents a from scratch install for learning and customisation. The compose file in the repository defines the two services involved, the application on ports 80 and 22 and a MySQL 5.7.31 database, with git storage and logs mounted from host paths.

### Does CodeFever support merge requests and branch protection?

Yes. The feature list includes merge requests for collaboration, branch protection for controlled submissions and clearer review, per member roles and permissions, and webhooks for integrating with other systems, alongside native support for Git branches and tags and diffs with syntax highlighting.

### What are the minimum server requirements for CodeFever?

The README states that it runs with very low resource requirements and that 1 CPU core and 1 GB of memory is enough. The public demo linked from the README also runs on a 1 core and 1 GB cloud server, and the project ships a lite image for the Docker deployment.

### Is CodeFever Community free for commercial and internal use?

The project states that CodeFever Community is released completely under the MIT licence and that it keeps most of the features of the hosted CodeFever service, optimised for single machine deployment. The LICENSE file at the repository root is the authoritative text, and the hosted CodeFever service is a separate product.

### What is the difference between CodeFever and CodeFever Community?

CodeFever is the public cloud service provided by the PGYER developer service platform, which launched in June 2020. CodeFever Community is the self-hosted edition, open sourced in February 2022, that retains most of the hosted features with optimisations for single machine deployment and accepts community contributions.

## Sources

- [Issues](https://github.com/PGYER/codefever/issues)
- [License: MIT](https://github.com/PGYER/codefever/blob/master/LICENSE)
- [PGYER/codefever on GitHub](https://github.com/PGYER/codefever)
- [Project website](https://codefever.cn)
- [README](https://github.com/PGYER/codefever/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pgyer-codefever