Choosing free on-prem git server - Gitea is the winner!
Trying to choose good opensource git server
Wanting to move your projects away from open cloud git providers and thinking of self-hosting internal git server locally?
Choosing servers
Running your own git server shouldn’t be too difficult, right?
So now choosing free git server from a vary short list of options. Bonobo Gogs vs Gitea vs Gitlab.
Bonobo though is free but for windows, and doesn’t have a linux version.
Gitlab is feature-rich and resource-heavy, that’s a hands on experience. It’s a commertial product but has a free version too.
The Gogs is very light-weight, I’ve tried it and it worked well, but it’s missing a container registry
The comparison favors Gitea in my eyes.
Both Gitea and Postgresql dockerized
https://docs.gitea.com/next/installation/install-with-docker
cd ~
mkdir gitea
cd gitea
docker-compose.yml:
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea:latest
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__database__DB_TYPE=postgres
- GITEA__database__HOST=db:5432
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=gitea
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
depends_on:
- db
db:
image: postgres:14
restart: always
environment:
- POSTGRES_USER=gitea
- POSTGRES_PASSWORD=gitea
- POSTGRES_DB=gitea
networks:
- gitea
volumes:
- ./postgres:/var/lib/postgresql/data
then
docker-compose up -d
navigate to http://localhost:3000/
to shutdown
docker-compose down
volumes will stay
Resource usage
Showing containers take 260MB RAM and a bit of CPU.
Docker images size 583MB total. 422MB of which is postgres:14 image. postgres:14-alpine image is ocupying 239MB, might also work if resources are constrained.
PS. After migrating 10+ repos to gitea, some forking and clonning gitea container alone is using 420MB RAM now. Need to keep an eye on it.
Sync two repos
https://docs.gitea.com/next/usage/repo-mirror
Can do push and pull.
pull
- Select New Migration in the Create… menu on the top right.
- Select the remote repository service.
- Enter a repository URL.
- If the repository needs authentication fill in your authentication information.
- Check the box This repository will be a mirror.
- Select Migrate repository to save the configuration.
The repository now gets mirrored periodically from the remote repository. You can force a sync by selecting Synchronize Now in the repository settings.
Can only set up pull mirroring for repos that don’t exist yet on your instance. Once the repo is created, you can’t convert it into a pull mirror anymore.
Https config
There is more in ssl config: https://docs.gitea.com/next/administration/https-setup
but we are trying this for now (took from gitea site):
Using the built-in server
Before you enable HTTPS, make sure that you have valid SSL/TLS certificates. You could use self-generated certificates for evaluation and testing. Please run
gitea cert --host [HOST]
to generate a self signed certificate.
If you are using Apache or nginx on the server, it’s recommended to check the reverse proxy guide.
To use Gitea’s built-in HTTPS support, you must change your app.ini file:
[server]
PROTOCOL = https
ROOT_URL = https://git.example.com:3000/
HTTP_PORT = 3000
CERT_FILE = cert.pem
KEY_FILE = key.pem
Note that if your certificate is signed by a third party certificate authority (i.e. not self-signed), then cert.pem should contain the certificate chain. The server certificate must be the first entry in cert.pem, followed by the intermediaries in order (if any). The root certificate does not have to be included because the connecting client must already have it in order to establish the trust relationship. To learn more about the config values, please checkout the Config Cheat Sheet.
For the CERT_FILE or KEY_FILE field, the file path is relative to the GITEA_CUSTOM environment variable when it is a relative path. It can be an absolute path as well.
Setting up HTTP redirection The Gitea server is only able to listen to one port; to redirect HTTP requests to the HTTPS port, you will need to enable the HTTP redirection service:
[server]
REDIRECT_OTHER_PORT = true
; Port the redirection service should listen on
PORT_TO_REDIRECT = 3080
If you are using Docker, make sure that this port is configured in your docker-compose.yml file.
Using reverse proxy
In this post: Gitea-ssl I’m configuring Apache as TLS terminating reverse proxy.
Todo
ssh config: https://docs.gitea.com/next/installation/install-with-docker
backup-restore test.