Instalación de Gitea en un VPS: Servidor Git ligero autoalojado con Docker y SSL
TL;DR
En esta guía, configuraremos Gitea — un servidor Git autoalojado ligero y potente — en su VPS, utilizando Docker y la obtención automática de certificados SSL a través de Caddy. Obtendrá una plataforma completamente funcional para la gestión de repositorios, accesible a través de un nombre de dominio con HTTPS, lista para el desarrollo en equipo o proyectos personales.
- Configuraremos un VPS moderno basado en Ubuntu 24.04 LTS con protección básica.
- Instalaremos Docker y Docker Compose para una gestión cómoda de las aplicaciones.
- Desplegaremos Gitea en un contenedor Docker, utilizando volúmenes persistentes para los datos.
- Configuraremos Caddy como proxy inverso para Gitea, asegurando automáticamente HTTPS con Let's Encrypt.
- Prepararemos un sistema de copia de seguridad para proteger sus datos.
- Obtendremos control sobre nuestra propia infraestructura Git, completamente independiente de servicios de terceros.
Qué configuramos y por qué
En el mundo moderno del desarrollo, Git se ha convertido en el estándar de facto para el control de versiones de código. Sin embargo, depender de servicios de terceros como GitHub, GitLab.com o Bitbucket no siempre es óptimo. Muchas equipos y desarrolladores individuales necesitan su propio servidor Git, completamente controlado. Gitea resuelve precisamente esta tarea.
Gitea es un servicio Git ligero, de código abierto y autoalojado (self-hosted), escrito en Go. Ofrece una funcionalidad completa, similar a GitHub o GitLab, pero consume significativamente menos recursos, lo que lo convierte en una opción ideal para desplegar en un VPS o incluso en un mini-ordenador como Raspberry Pi. Obtendrá una interfaz web intuitiva para gestionar repositorios, usuarios, equipos, solicitudes de fusión (pull requests), seguimiento de tareas (issues) y mucho más.
Qué obtendrá el lector al final
Después de seguir esta guía, tendrá un servidor Git Gitea completamente configurado y en funcionamiento, accesible a través de su nombre de dominio con una conexión HTTPS segura. Podrá crear repositorios públicos y privados, invitar a colegas a colaborar, gestionar el acceso y utilizar todas las operaciones Git habituales a través de la interfaz web o la línea de comandos. Su infraestructura estará completamente bajo su control, garantizando confidencialidad e independencia.
Qué alternativas existen y por qué autoalojado en un VPS
Existen varios enfoques principales para el alojamiento de repositorios Git:
- Servicios gestionados en la nube (GitHub, GitLab.com, Bitbucket): Esta es la opción más sencilla en términos de mantenimiento. Simplemente se registra y empieza a trabajar. Sin embargo, depende de la política y la infraestructura del proveedor, puede encontrarse con limitaciones en los planes gratuitos, así como con cuestiones de privacidad de los datos almacenados en servidores de terceros.
- GitLab Community Edition (CE) autoalojado: GitLab CE es una solución potente que ofrece no solo alojamiento Git, sino también un ciclo DevOps completo: CI/CD, registro de contenedores, monitorización y mucho más. Sin embargo, GitLab CE requiere significativamente más recursos (mínimo 4 GB de RAM para un funcionamiento cómodo), lo que lo hace menos adecuado para VPS pequeños y equipos.
- Gitea autoalojado: Gitea ocupa un nicho entre los servicios en la nube sencillos y el GitLab que consume muchos recursos. Ofrece una rica funcionalidad de alojamiento Git con un consumo mínimo de recursos. Es la opción ideal si necesita un servidor Git completo sin funciones adicionales y sin grandes costes de infraestructura. El despliegue en un VPS le da control total sobre los datos, la posibilidad de personalización e integración con su propio ecosistema. Además, Docker simplifica significativamente el despliegue y la gestión de Gitea, aislándolo del sistema principal y haciéndolo portable.
Elegir Gitea en un VPS permite combinar las ventajas del autoalojamiento (control, privacidad) con el uso eficiente de los recursos y la simplicidad de despliegue gracias a Docker.
Qué configuración de VPS se necesita para esta tarea
Para instalar Gitea en un VPS con Docker y Caddy, generalmente no se requieren recursos extremadamente potentes. Gitea está optimizado para funcionar en hardware modesto, pero la presencia de Docker y Caddy añade una pequeña sobrecarga. Es importante considerar cuántos usuarios trabajarán activamente con Gitea y cuántos repositorios se planea alojar.
Requisitos mínimos
- CPU: 1 vCore (por ejemplo, Intel Xeon E3/E5 o AMD EPYC). Para equipos pequeños de hasta 5-10 personas, esto será suficiente.
- RAM: 2 GB. Esto será suficiente para el sistema operativo, el demonio Docker, los contenedores de Gitea y Caddy. Si se planea un uso muy activo u otros servicios en el mismo VPS, es mejor considerar 4 GB.
- Disco: 40-60 GB SSD. El SSD es crítico para el rendimiento de las operaciones Git. 40 GB serán suficientes para el SO, las imágenes Docker y varias decenas de repositorios. Si los repositorios son muy grandes o hay muchos, considere 80-100 GB.
- Red: 100 Mbit/s. Para la mayoría de los escenarios, esto es más que suficiente. Más importante es la estabilidad del canal y la baja latencia.
Plan de VPS específico para la tarea (válido para 2026)
Para un funcionamiento cómodo de Gitea con Docker y Caddy para un equipo de hasta 10-20 desarrolladores y decenas de repositorios, se recomienda la siguiente configuración de VPS:
- CPU: 2 vCore (por ejemplo, Intel Xeon E5-2690v4 o AMD EPYC 7002 series).
- RAM: 4 GB DDR4.
- Disco: 80 GB NVMe SSD. NVMe garantizará la máxima velocidad de las operaciones de disco, lo cual es importante para Git.
- Red: Puerto de 1 Gbit/s con tráfico ilimitado o gran volumen.
Esta configuración de VPS garantizará un excelente rendimiento y una reserva para el futuro. Por ejemplo, puede obtener un VPS con las características indicadas.
Cuándo se necesita un dedicado y no un VPS
Un servidor dedicado debe considerarse si:
- Equipo muy grande: Más de 50-100 usuarios activos.
- Repositorios extremadamente grandes: Repositorios con gigabytes de archivos binarios (LFS).
- Requisitos críticos de rendimiento: Alta carga en operaciones Git en modo 24/7.
- Requisitos estrictos de seguridad/aislamiento: Aislamiento completo de los "vecinos" del hipervisor.
- Se planean muchos otros servicios: Además de Gitea, en el servidor funcionarán agentes CI/CD, bases de datos, servidores web para otros proyectos, etc.
Para la mayoría de las tareas de Gitea, especialmente para startups, equipos pequeños y proyectos personales, un VPS será una solución óptima y económicamente ventajosa.
Ubicación: en qué influye
La elección de la ubicación del VPS es importante para:
- Latencia: Cuanto más cerca esté el servidor de su equipo y usuarios principales, menor será la latencia al realizar operaciones Git y trabajar con la interfaz web. Esto es especialmente crítico para los desarrolladores que se encuentran lejos del servidor.
- Cumplimiento legal: En algunos casos, especialmente para empresas, puede haber requisitos para el almacenamiento de datos en una jurisdicción específica.
- Disponibilidad: Elija una ubicación con una infraestructura de red fiable y buenos canales de comunicación.
Lo ideal es elegir un centro de datos ubicado geográficamente cerca de la mayoría de sus usuarios.
Preparación del servidor
Antes de proceder con la instalación de Gitea, es necesario realizar una configuración básica de su VPS. Utilizaremos Ubuntu Server 24.04 LTS, ya que es una versión actual y estable del sistema operativo para el año 2026.
Configuración mínima después del aprovisionamiento
Después de obtener acceso a su VPS (normalmente a través de SSH como usuario root), lo primero es actualizar el sistema y crear un nuevo usuario con permisos sudo.
# Actualización de la lista de paquetes y su actualización a las últimas versiones
sudo apt update && sudo apt upgrade -y
# Creación de un nuevo usuario (reemplace 'ваш_пользователь' por el nombre deseado)
sudo adduser ваш_пользователь
# Adición del usuario al grupo sudo para obtener permisos administrativos
sudo usermod -aG sudo ваш_пользователь
Salga de la sesión root y entre con el nuevo usuario:
exit
# Luego, inicie sesión de nuevo con su_usuario
ssh ваш_пользователь@ваш_ip_сервера
Configuración de claves SSH (recomendado)
Para mejorar la seguridad, se recomienda utilizar claves SSH en lugar de contraseñas. Genere una clave en su máquina local (si aún no tiene una):
# En su máquina local
ssh-keygen -t ed25519 -C "ваш[email protected]"
Copie la clave pública al servidor:
# En su máquina local
ssh-copy-id ваш_пользователь@ваш_ip_сервера
Después de esto, desactive el inicio de sesión con contraseña para SSH (archivo /etc/ssh/sshd_config):
# En el servidor
sudo nano /etc/ssh/sshd_config
Encuentre y modifique las siguientes líneas:
# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no
Reinicie el servidor SSH:
sudo systemctl restart sshd
Instalación de Fail2Ban
Fail2Ban protege su servidor de ataques de fuerza bruta, bloqueando las direcciones IP desde las que se producen numerosos intentos fallidos de inicio de sesión.
# Instalación de Fail2Ban
sudo apt install fail2ban -y
# Copia de la configuración estándar para su ajuste
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Apertura del archivo para edición (opcional, para una configuración más fina)
sudo nano /etc/fail2ban/jail.local
Normalmente, la configuración predeterminada es suficiente, pero puede cambiar bantime, findtime y maxretry. Asegúrese de que la sección [sshd] esté habilitada.
# Ejemplo del contenido de jail.local (asegúrese de que enabled = true)
[DEFAULT]
bantime = 1d
findtime = 10m
maxretry = 5
[sshd]
enabled = true
mode = aggressive
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
# Reinicio de Fail2Ban para aplicar los cambios
sudo systemctl restart fail2ban
sudo systemctl enable fail2ban
Configuración del Firewall (UFW)
Uncomplicated Firewall (UFW) es una interfaz fácil de usar para iptables. Lo configuraremos para permitir solo los puertos necesarios.
# Instalación de UFW
sudo apt install ufw -y
# Permitir SSH (puerto 22 por defecto)
sudo ufw allow ssh
# Permitir HTTP (puerto 80) y HTTPS (puerto 443) para el servidor web (Caddy)
sudo ufw allow http
sudo ufw allow https
# Habilitar UFW
sudo ufw enable
Confirme la habilitación pulsando y. Puede verificar el estado del firewall con el comando sudo ufw status verbose.
Ahora su servidor está listo para la instalación de Docker y Gitea.
Instalación de software — paso a paso
Utilizaremos Docker y Docker Compose para desplegar Gitea. Esto garantiza el aislamiento de la aplicación, simplifica la gestión de dependencias y facilita las actualizaciones.
1. Instalación de Docker Engine
Para instalar Docker Engine en Ubuntu 24.04 LTS (Noble Numbat), siga las recomendaciones oficiales, válidas para el año 2026.
# Удаление старых версий Docker, если они есть
for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; do sudo apt remove $pkg; done
# Обновление списка пакетов
sudo apt update
# Установка необходимых пакетов для работы с репозиториями
sudo apt install ca-certificates curl gnupg -y
# Добавление официального GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
# Добавление репозитория Docker в APT-источники
echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Обновление списка пакетов после добавления репозитория Docker
sudo apt update
# Установка Docker Engine, Docker CLI, containerd и Docker Compose плагина
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
Verificación de la instalación de Docker:
# Проверка версии Docker
docker --version
# Проверка статуса Docker-сервиса
sudo systemctl status docker
# Запуск тестового контейнера 'hello-world'
sudo docker run hello-world
Añada su usuario al grupo docker para no tener que usar sudo en cada comando de Docker:
# Добавление пользователя в группу docker
sudo usermod -aG docker ваш_пользователь
# Примените изменения группы (выйдите и войдите заново или перезагрузите систему)
newgrp docker
2. Creación de la estructura de directorios para Gitea
Crearemos directorios para almacenar los datos de Gitea y la configuración de Docker Compose. Esto garantizará la persistencia de los datos y una estructura limpia.
# Создание корневой директории для проекта Gitea
mkdir -p ~/gitea
# Переход в созданную директорию
cd ~/gitea
# Создание директории для хранения постоянных данных Gitea
mkdir -p ./data
3. Creación del archivo docker-compose.yml para Gitea y Caddy
Este archivo definirá los servicios de Gitea y Caddy, sus dependencias, volúmenes y configuraciones de red. Utilizaremos SQLite como base de datos por simplicidad, lo cual es ideal para instalaciones pequeñas. Para proyectos más grandes, considere PostgreSQL o MySQL.
Cree el archivo docker-compose.yml en el directorio ~/gitea:
# Создание файла docker-compose.yml
nano docker-compose.yml
Pegue el siguiente contenido, reemplazando your.domain.com con su dominio real:
# docker-compose.yml
version: "3.8"
services:
gitea:
image: gitea/gitea:1.22.0 # Актуальная версия на 2026 год, проверьте https://dl.gitea.io/gitea/
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__DATABASE__DB_TYPE=sqlite3 # Используем SQLite для простоты
- GITEA__DATABASE__PATH=/data/gitea.db # Путь к файлу базы данных SQLite
- GITEA__SERVER__DOMAIN=your.domain.com # Ваш домен
- GITEA__SERVER__SSH_DOMAIN=your.domain.com # Домен для SSH-доступа
- GITEA__SERVER__HTTP_PORT=3000 # Внутренний порт Gitea
- GITEA__SERVER__APP_DATA_PATH=/data # Путь для данных Gitea внутри контейнера
- GITEA__SERVER__ROOT_URL=https://your.domain.com/ # Базовый URL для Gitea
- GITEA__SECURITY__INSTALL_LOCK=true # Блокировка страницы установки после первой настройки
- GITEA__SERVICE__DISABLE_REGISTRATION=false # Разрешить регистрацию новых пользователей (true для приватного сервера)
- GITEA__SERVICE__REQUIRE_SIGNIN_VIEW=false # Требовать вход для просмотра репозиториев (true для приватного сервера)
- GITEA__SESSION__PROVIDER=db # Используем базу данных для сессий
- GITEA__CACHE__ADAPTER=redis # Рекомендуется для производительности
- GITEA__CACHE__HOST=redis:6379 # Хост Redis
- GITEA__QUEUE__TYPE=redis # Очередь задач через Redis
- GITEA__QUEUE__CONN_STR=redis://redis:6379/0 # Строка подключения к Redis
restart: always
volumes:
- ./data:/data # Маппинг локальной директории данных к контейнеру
- /etc/timezone:/etc/timezone:ro # Синхронизация часового пояса
- /etc/localtime:/etc/localtime:ro # Синхронизация локального времени
ports:
- "3000:3000" # Внутренний HTTP-порт Gitea (для Caddy)
- "2222:22" # SSH-порт Gitea (маппим на 2222, чтобы не конфликтовать с хостом)
networks:
- gitea-network
caddy:
image: caddy:2.7.5 # Актуальная версия Caddy на 2026 год
container_name: caddy
restart: always
ports:
- "80:80" # HTTP для Let's Encrypt challenge и перенаправления
- "443:443" # HTTPS
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile # Файл конфигурации Caddy
- ./caddy_data:/data # Хранилище Caddy для сертификатов и состояния
environment:
- GITEA_DOMAIN=your.domain.com # Передача домена в Caddyfile через переменную
networks:
- gitea-network
depends_on:
- gitea # Caddy зависит от Gitea
redis:
image: redis:7.2-alpine # Легковесная версия Redis
container_name: redis
restart: always
volumes:
- ./redis_data:/data # Хранилище данных Redis
networks:
- gitea-network
command: redis-server --appendonly yes # Включение персистентности данных
networks:
gitea-network:
driver: bridge
Importante: Reemplace your.domain.com con su dominio real. Asegúrese de que para su dominio (por ejemplo, gitea.example.com) se haya creado un registro A que apunte a la dirección IP de su VPS.
Nota sobre las versiones: Las versiones gitea/gitea:1.22.0, caddy:2.7.5 y redis:7.2-alpine se indican como actuales para el año 2026. Siempre verifique los repositorios oficiales de Docker Hub para obtener las versiones más recientes y estables.
4. Creación del archivo Caddyfile para Caddy
Caddy gestiona automáticamente los certificados SSL a través de Let's Encrypt. Cree el archivo Caddyfile en el mismo directorio ~/gitea:
# Создание файла Caddyfile
nano Caddyfile
Pegue el siguiente contenido:
# Caddyfile
{env.GITEA_DOMAIN} {
# Автоматическое HTTPS
tls {
# Используем Let's Encrypt
acme_challenge http
}
# Обратный прокси для Gitea
reverse_proxy gitea:3000 {
# Проксируем заголовки, необходимые Gitea
header_up Host {host}
header_up X-Real-IP {remote_ip}
header_up X-Forwarded-Proto {scheme}
header_up X-Forwarded-For {remote_ip}
}
# Настройки для больших файлов (Git LFS)
# Gitea сам обрабатывает LFS, но Caddy должен пропускать большие запросы
# Если у вас будут очень большие LFS файлы, может потребоваться увеличение body_size
# (по умолчанию Caddy обрабатывает до 10MB)
# Для Gitea это обычно не требуется, так как он сам принимает данные
}
La variable {env.GITEA_DOMAIN} se reemplazará automáticamente con el valor de docker-compose.yml.
5. Inicio de Gitea y Caddy con Docker Compose
Una vez creados ambos archivos, está listo para iniciar Gitea.
# Переход в директорию с файлами
cd ~/gitea
# Запуск всех сервисов в фоновом режиме
docker compose up -d
Este comando descargará las imágenes Docker necesarias (Gitea, Caddy, Redis), creará los contenedores y los iniciará. El primer inicio puede tardar un tiempo mientras se descargan las imágenes.
Puede verificar el estado de los contenedores en ejecución con el comando:
# Проверка статуса контейнеров
docker compose ps
Debería ver que todos los contenedores (gitea, caddy, redis) están en estado running.
En este punto, la instalación de los componentes principales ha finalizado. Ahora pasemos a la configuración final.