# GitPrep: a self hosted GitHub clone for a Unix server

> GitPrep is a Perl application that reproduces the GitHub interface, including repositories, pull requests, issues and wikis, and runs on your own Unix or Linux server with its own web server, CGI mode or behind a reverse proxy. It is a small tool with old dependencies, a 10MB push limit and an upgrade path that means copying files over the old ones.

**yuki-kimoto/gitprep** — Portable GitHub system into your own server

- Repository: https://github.com/yuki-kimoto/gitprep
- Website: http://gitprep.yukikimoto.com/
- Stars: 934 · Forks: 120
- Language: Perl
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/yuki-kimoto-gitprep

## A GitHub shaped forge that lives on one Unix box

GitPrep is described as a portable Github system that can be installed and hosted on your own Unix or Linux server. The claim is that it has the same interface as GitHub, and the feature list backs that up with the pieces you would actually use: repository, pull request, issue and wiki support, plus cloning the GitHub way.

The deployment story is unusually flexible for a tool of this vintage. There is a built-in web server, there is CGI support for shared hosting where you log in over SSH and run the script from your own home directory, and there is reverse proxy support for people who want it behind nginx or Apache. Smart HTTP support means you pull and push repositories over HTTP with the same remote URLs you would use against GitHub.

The runtime requirement is Perl 5.10.1 or newer, and the README states that all repositories are stored only on your server. It also points at a reason organisations like this: because the git repository directory is directly accessible on the server, fixing a mistake like a force push to master is a filesystem operation rather than a support ticket.

A live demo is linked from the project site, hosted as a CGI script on a shared server, which is a good way to see the interface before installing anything.

## Two commands to a running server on port 10020

The installation path is short by design. There is a simplified route that pulls a shallow copy and runs a setup script that installs the necessary modules, creates the config file and the data folder.

```bash
# Pulls a shallow copy from this repository
git clone --depth=1 https://github.com/yuki-kimoto/gitprep
cd gitprep

# This will install the necessary modules, create the config file and data folder
./setup

# To update in future, run
./update
```

After that, the server is started with the bundled script, it runs in the background, and the port is 10020 by default.

```bash
    ./gitprep
```

You then open http://localhost:10020 in a browser. Running the same command again restarts the server. To change the port, or to work around a firewall, you edit gitprep.conf, and the README notes that a large number of other configuration settings live in the example file gitprep.conf.example.

Stopping the server uses the same script with an option.

```bash
    ./gitprep --stop
```

Two preparatory steps are recommended before that. Creating a dedicated gitprep user with useradd is described as not strictly necessary but recommended, and checking that git is present with git --version and that perl -v reports 5.10.1 or newer saves you from a confusing failure later.

## The detailed setup path and its database step

The longer route breaks the setup into pieces, which is what you want when something fails. The module step installs dependencies, and the README explains how to recover from it if the extlib directory is left in a broken state.

```bash
    ./setup_module
```

```bash
    rm -rf extlib
    ./setup_module
```

After the modules are in place you check that the setup succeeded by running the test suite.

```bash
    prove t
```

A syntax OK result means the module setup worked. The database is then created by a separate script.

```bash
    ./setup_database
```

There is a documented upgrade path for anyone who installed version 1 and is moving to version 2. You back up the gitprep directory, rename the existing database file to a version 1 backup, run the database setup again, and then use the old/copy_database_v1_to_v2 command to migrate the data across.

```bash
    mv data/gitprep.db data/gitprep_v1bak.db
    ./setup_database
    old/copy_database_v1_to_v2 data/gitprep_v1bak.db data/gitprep.db
```

The layout of the repository reflects this structure: setup, setup_module, setup_database, setup_config and setup_script sit at the top level next to lib/, templates/, t/ for tests, script/, deploy/ and the gitprep.cgi entry point.

## Running as CGI and reading the logs when it breaks

The CGI route exists for shared hosting, where you connect over SSH and log in with your own user rather than running a dedicated service account. The installation process is the same as above except for creating the user, and once the install finishes the script is reached through a path on your host.

```bash
    http://yourhost/somepath/gitprep/gitprep.cgi
```

The same application binary serves both modes, so the difference is how the request reaches it: through the embedded web server on port 10020, or through the web server invoking the CGI script.

When things go wrong in CGI mode, the documentation points you at a log file rather than at the console.

the file is gitprep/log/production.log.

That path is worth noting because the embedded server runs in the background, so the terminal is not where the diagnostics appear. The log/ directory is present in the repository root for exactly this reason.

Public key authentication support is listed among the features, so SSH key access to the git repositories over the HTTP interface is part of the design rather than an add-on.

## Configuration lives in gitprep.conf and one path bites people

Configuration is a single INI style file, gitprep.conf, with the example file gitprep.conf.example as the reference. Most of it is documented as living there rather than in the README, so expect to read it.

One setting is called out because it is the most common early failure: if you install git into your own local directory rather than a system location, the git command path must be set explicitly in gitprep.conf.

```bash
    [basic]
    ;;; Git command path
    git_bin=/home/yourname/local/bin/git
```

The same path appears in the FAQ under the heading about not finding the git command, which confirms how often it comes up.

There is also a global git setting the setup advises, because it affects how paths with non ASCII characters are displayed in the interface.

```bash
    git config --global core.quotepath false
```

The project supports a per installation override file named gitprep.my.conf, a copy of gitprep.conf, which matters for upgrades. The documented upgrade method is to overwrite all files except gitprep.conf, and if you prefer to upgrade with git pull you keep your settings in gitprep.my.conf and pull. The upgrade advice in the FAQ is blunt: if you hit a drinking elephant error after upgrading, you are probably missing a new CPAN dependency, and the fix is to run setup again.

## The limits that will decide it for you

Three constraints are documented, and they are the ones that decide whether this tool fits.

The first is the push size limit. GitPrep restricts the maximum post message size to 10MB, which the README attributes to the default of the underlying framework. A large push produces a recognisable failure.

```bash
    error: RPC failed; result=22, HTTP code = 413
    fatal: The remote end hung up unexpectedly
```

The workaround is documented as well, by raising the maximum message size through an environment variable.

```bash
    # 1GB
    export MOJO_MAX_MESSAGE_SIZE=1024000000
```

Git itself is the other half of that story, because git restricts the post max size over HTTP via the http.postBuffer value, and an older git produces a different failure with RPC failed result=5. The README notes that it checked git version 1.8.5.5 for that case.

The second limit is the blame page, which uses git blame with the line porcelain option. That option does not exist in old git, the project admits it does not know when it was added, and it states that at least git 1.8.2.1 works.

The third is the dependency stack. After CentOS 6, some Perl core modules are not installed by default, and the documented fix is to install them.

```bash
    yum -y install perl-core
```

Taken together, these point at a tool that is comfortable for text repositories and small binary assets, and uncomfortable for anything else.

## Licence, project state and what the repository contains

The licence field on the repository records a custom type that GitHub cannot classify, and the tree carries the Artistic and Copying files that are conventionally used with the Perl Artistic License. Since the classification is not something the tooling can label for you, read the LICENSE file yourself before you redistribute or fork it. The README states that the project is open sourced and free.

On maintenance, the repository is not archived and the last push was on 2026-07-06. It publishes no GitHub releases, so there is no version tag to pin and no release note to read. The CHANGES file at the repository root is the changelog, and the file is named without an extension, which is consistent with a long running Perl project rather than a modern package.

Other details worth knowing. The project is written in Perl with a cpanfile and a bundled cpanm for dependency installation, the templates/ directory holds the view templates, and public/ and svg/ hold static assets. The gitprep-site/ directory is for the site content. There is a .htaccess file, which matters if you deploy behind Apache, and deploy/ for deployment files.

The project also maintains a homepage at gitprep.yukikimoto.com, and the repository contains the app in a single directory rather than as a collection of packages, so deployment is a copy of files rather than an install from a registry.

## Conclusion

Adopt GitPrep if you need a small internal forge that looks like GitHub to your team, you already run a Unix server, and you are willing to own the Perl 5.10.1 dependency and the 10MB push ceiling. Do not adopt it as a replacement for a hosted forge that must handle large pushes, binary assets or many concurrent users, since the documented limits and the age of the dependency stack are real. Verify first that your git binary supports the line porcelain option the blame page needs, that Perl 5.10.1 or newer is present, that you read gitprep.conf.example before changing anything, and that you keep a copy of gitprep.conf when you upgrade, because every other file is meant to be overwritten.

## FAQ

### How do I install and start GitPrep?

Clone the repository with git clone --depth=1 https://github.com/yuki-kimoto/gitprep, enter the directory, run ./setup to install modules and create the config file and data folder, then start the server with ./gitprep and open http://localhost:10020. Stop it with ./gitprep --stop.

### How large a repository can I push to GitPrep over HTTP?

GitPrep restricts the maximum post message size to 10MB by default, which produces an HTTP code 413 failure. You can raise it with the MOJO_MAX_MESSAGE_SIZE environment variable, for example export MOJO_MAX_MESSAGE_SIZE=1024000000, and you also need a large enough http.postBuffer in your git config.

### Why does GitPrep not find my git command?

If git is installed in your own local directory rather than a system path, you must set the git command path in gitprep.conf under the basic section, using the git_bin key with the full path to your git executable.

### How do I upgrade GitPrep without losing my configuration?

The documented method is to overwrite all files except gitprep.conf. If you want to upgrade with git pull instead, you create a gitprep.my.conf copied from gitprep.conf and then pull, and if a missing CPAN dependency shows up as a drinking elephant error, you run the setup script again.

## Sources

- [Issues](https://github.com/yuki-kimoto/gitprep/issues)
- [Project website](http://gitprep.yukikimoto.com/)
- [README](https://github.com/yuki-kimoto/gitprep/blob/master/README.md)
- [yuki-kimoto/gitprep on GitHub](https://github.com/yuki-kimoto/gitprep)

---

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