Gitea Docker Compose: Secure, Production-Ready Setup

This project provides a comprehensive and secure setup for deploying a private Gitea server using Docker Compose. It includes an NGINX reverse proxy for handling web traffic and Certbot for automatic SSL certificate acquisition and renewal from Let's Encrypt.

The configuration is pre-hardened to prevent common security issues like unauthorized registration and repository creation, making it ideal for private or small-team use.

Features

• Gitea Service: A self-hosted Git service.
• NGINX Reverse Proxy: Manages web traffic and SSL termination.
• Automatic SSL: Certbot automatically obtains and renews SSL certificates.
• Hardened Security: Default configuration disables public registration, restricts new user permissions, and enforces strong passwords.
• Brute-Force Protection: Includes a script to easily set up Fail2ban for monitoring Gitea logs and banning malicious IPs.
• Easy Deployment: Get up and running with a few simple commands.

Prerequisites

• Docker and Docker Compose installed on your server.
• A registered domain name (e.g., git.example.com) with its DNS A record pointing to your server's public IP address.

Quick Start Guide

1. Configure Your Environment

The docker-compose.yml file requires two environment variables to be set for SSL certificate generation. You can create a .env file in this directory to store them.

Create a file named .env:

touch .env

Add the following variables to the .env file, replacing the placeholder values with your own:

# .env
# Your domain name for Gitea
DOMAIN=git.example.com

# Your email address for Let's Encrypt notifications
CERTBOT_EMAIL=your-email@example.com

2. Launch the Services

With your environment configured, start the Gitea and NGINX containers in detached mode:

docker-compose up -d

Docker Compose will pull the necessary images and start the services. Certbot will automatically request an SSL certificate for your domain. After a minute or two, you should be able to access your secure Gitea instance at https://<your-domain>.

3. Set Up Brute-Force Protection (Recommended)

To protect your server from brute-force login attacks, run the included Fail2ban setup script. This script must be run on the Docker host (not inside a container).

First, make the script executable:

chmod +x setup_fail2ban.sh

Then, run it with sudo:

sudo ./setup_fail2ban.sh

This will install Fail2ban (if not already present), configure it to monitor your Gitea logs, and automatically ban IPs that have too many failed login attempts.

Security Configuration

This setup includes several security enhancements by default, configured via environment variables in the docker-compose.yml file:

• Disabled Registration: Public user registration is turned off. New users can only be created by an administrator.
• Restricted by Default: New users are created with restricted permissions, preventing them from creating repositories or organizations.
• Private by Default: New repositories are forced to be private.
• Reverse Proxy Safety: Gitea is configured to correctly identify user IP addresses from behind the NGINX reverse proxy, which is essential for effective logging and for Fail2ban to work correctly.
• Stronger Passwords: A minimum password length and complexity requirements are enforced.

File Structure

• docker-compose.yml: The main file that defines the Gitea and NGINX services, volumes, and environment variables.
• setup_fail2ban.sh: A shell script to automate the installation and configuration of Fail2ban on the host machine.
• templates/gitea.conf.template: The NGINX configuration template used to proxy traffic to the Gitea container.
• gitea-logs/: (Created after startup) Directory on the host where Gitea's logs are stored, making them accessible to Fail2ban.
• gitea-data/: (Created after startup) Docker volume where all persistent Gitea data (repositories, database, etc.) is stored.
• nginx-secrets/: (Created after startup) Docker volume where SSL certificates and other NGINX secrets are stored.