El objetivo es instalar un servidor GitLab Self-Managed sobre una máquina con Ubuntu Server.
Este servidor permitirá:
Guardar proyectos de programación.
Centralizar scripts personales.
Mantener archivos de configuración.
Trabajar desde diferentes ordenadores.
Controlar las versiones de los archivos.
Recuperar versiones anteriores.
Desplegar proyectos en otros servidores.
Automatizar despliegues mediante GitLab CI/CD.
Mantener copias de seguridad de todos los repositorios.
Aunque muchas veces se utiliza la expresión “instalar un GitHub”, realmente instalaremos GitLab, que ofrece un servicio similar a GitHub, pero alojado en nuestro propio servidor.
La arquitectura inicial será:
Ordenador personal
│
│ Git mediante SSH o HTTPS
▼
https://gitlab.tudominio.es
│
▼
Router de Internet
│
│ Puertos 80, 443 y 2222
▼
Ubuntu Server
│
▼
Docker Compose
│
▼
GitLab Community Edition
Fase 0. Planificación y requisitos
0.1. Requisitos recomendados
Para una instalación personal se recomienda:
Ubuntu Server 22.04 LTS o 24.04 LTS.
Procesador de 64 bits.
4 núcleos de CPU recomendados.
8 GB de RAM recomendados.
50 GB de almacenamiento como mínimo.
Dirección IP local fija.
Dominio propio.
Acceso a la configuración del router.
Conexión a Internet sin CG-NAT, o con posibilidad de abrir puertos.
Usuario de Ubuntu con permisos sudo.
GitLab consume bastantes más recursos que un servidor Git básico. Con 4 GB de RAM puede funcionar para pruebas, pero para un uso continuado es preferible disponer de 8 GB o más.
0.2. Datos utilizados en los ejemplos
Durante la documentación utilizaremos estos datos:
Dominio: gitlab.tudominio.es
IP local del servidor: 192.168.1.50
Puerto web HTTP: 80
Puerto web HTTPS: 443
Puerto SSH de GitLab: 2222
Directorio de instalación: /srv/gitlab
El puerto SSH externo será el 2222 porque el puerto 22 normalmente ya está siendo utilizado por el servicio SSH de Ubuntu Server.
0.3. Comprobar la versión de Ubuntu
lsb_release -a
También podemos utilizar:
cat /etc/os-release
0.4. Comprobar procesador, memoria y almacenamiento
Procesador:
lscpu
Memoria:
free -h
Espacio en disco:
df -h
0.5. Actualizar Ubuntu Server
sudo apt update
sudo apt upgrade -y
Reiniciamos si se ha actualizado el kernel:
sudo reboot
Fase 1. Configuración de red y dominio
1.1. Asignar una IP fija al servidor
El servidor debe mantener siempre la misma dirección IP dentro de la red local.
Tenemos dos posibilidades:
Crear una reserva DHCP en el router.
Configurar una IP estática en Ubuntu Server.
La opción más sencilla suele ser crear una reserva DHCP en el router asociando la dirección MAC del servidor con una IP, por ejemplo:
192.168.1.50
Para consultar la dirección IP actual:
ip address
Versión abreviada:
ip -br address
Para conocer la puerta de enlace:
ip route
1.2. Comprobar la IP pública
Desde el servidor podemos ejecutar:
curl https://ifconfig.me
También podemos consultar la IP pública desde el panel del router.
1.3. Crear el registro DNS
En el proveedor del dominio debemos crear un registro de tipo A.
Ejemplo:
Tipo: A
Nombre: gitlab
Destino: IP_PUBLICA
TTL: Automático
El resultado será:
gitlab.tudominio.es → IP pública del router
Si la conexión utiliza una IP pública dinámica, será necesario configurar un servicio de DNS dinámico o actualizar automáticamente el registro DNS.
El dominio debe resolver públicamente hacia el servidor para que GitLab pueda solicitar automáticamente el certificado HTTPS de Let’s Encrypt.
1.4. Comprobar la resolución DNS
Desde otro ordenador:
nslookup gitlab.tudominio.es
En Linux o macOS también podemos utilizar:
dig gitlab.tudominio.es
El resultado debe mostrar nuestra IP pública.
1.5. Configurar la redirección de puertos
En el router debemos crear estas reglas NAT o Port Forwarding:
Puerto externo
IP interna
Puerto interno
Protocolo
80
192.168.1.50
80
TCP
443
192.168.1.50
443
TCP
2222
192.168.1.50
2222
TCP
Los puertos 80 y 443 deben ser accesibles desde Internet para la validación y renovación automática del certificado de Let’s Encrypt.
1.6. Comprobar si existe CG-NAT
Compara:
La IP pública mostrada por el router.
La IP obtenida con curl https://ifconfig.me.
Si son diferentes, es posible que la conexión esté detrás de CG-NAT.
En ese caso, las redirecciones de puertos no funcionarán directamente. Las alternativas serían:
Solicitar una IP pública al proveedor.
Utilizar una VPN como WireGuard o Tailscale.
Utilizar un túnel inverso.
Alojar GitLab en un VPS.
Fase 2. Instalación de Docker y Docker Compose
2.1. Eliminar paquetes incompatibles
Antes de instalar Docker desde su repositorio oficial eliminamos posibles versiones anteriores:
No ocurre nada si algunos de estos paquetes no estaban instalados.
Docker recomienda utilizar su repositorio oficial de APT e instalar el complemento moderno docker compose, en lugar del antiguo ejecutable independiente docker-compose.
La imagen oficial de GitLab utiliza precisamente /etc/gitlab, /var/log/gitlab y /var/opt/gitlab para conservar la configuración, los registros y los datos.
Fase 4. Instalación de GitLab con Docker Compose
4.1. Elegir una versión
GitLab ofrece:
GitLab Community Edition: gitlab/gitlab-ce
GitLab Enterprise Edition: gitlab/gitlab-ee
Para este proyecto personal utilizaremos Community Edition.
Para una primera prueba se puede utilizar:
gitlab/gitlab-ce:latest
Sin embargo, cuando el servidor esté funcionando conviene fijar una versión concreta:
gitlab/gitlab-ce:19.x.x-ce.0
GitLab recomienda fijar una versión específica en entornos estables y utilizar latest principalmente para pruebas.
Puerto 80 del servidor → puerto 80 de GitLab
Puerto 443 del servidor → puerto 443 de GitLab
Puerto 2222 del servidor → puerto 22 del contenedor
El valor:
gitlab_rails['gitlab_shell_ssh_port'] = 2222
indica a GitLab que debe mostrar el puerto 2222 en las direcciones de clonación SSH. La documentación oficial contempla configurar un puerto SSH externo diferente cuando el puerto 22 del servidor está ocupado.
4.4. Validar el archivo
cd /srv/gitlab
docker compose config
Si no aparecen errores, la sintaxis es correcta.
4.5. Descargar la imagen
docker compose pull
4.6. Iniciar GitLab
docker compose up -d
4.7. Consultar el estado
docker compose ps
4.8. Consultar los registros
docker compose logs -f gitlab
Para dejar de visualizar los registros:
Ctrl + C
La primera inicialización es más lenta que los siguientes arranques porque GitLab debe configurar PostgreSQL, Redis, NGINX, Gitaly y el resto de sus componentes internos.
El archivo con la contraseña inicial se elimina automáticamente después del primer reinicio transcurridas aproximadamente 24 horas, por lo que conviene obtenerla y cambiarla cuanto antes.
5.2. Entrar en GitLab
Revisa la configuración persistente
Como /srv/gitlab/config es persistente, puede conservarse la dirección anterior.
Guardamos los códigos de recuperación en un lugar seguro.
Fase 6. Configuración de Git y claves SSH
GitLab permite trabajar mediante HTTPS o SSH. Para trabajar habitualmente desde varios equipos utilizaremos SSH, que GitLab recomienda como método de autenticación para clonar repositorios.
Title: Servidor web
Key: contenido de id_ed25519.pub
Para un despliegue que solamente descarga archivos, no activamos permisos de escritura.
Las Deploy Keys están pensadas precisamente para permitir que servidores externos accedan a repositorios sin asociar el acceso a la clave personal de un usuario.
11.4. Configurar SSH en el servidor destino
nano ~/.ssh/config
Contenido:
Host gitlab-personal
HostName gitlab.tudominio.es
User git
Port 2222
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Las claves privadas utilizadas por CI/CD no deben ser las claves personales del usuario. GitLab recomienda utilizar claves específicas para la automatización y almacenarlas de forma protegida.
La instalación y configuración completa de Runner debe realizarse como una fase independiente después de dominar:
Repositorios.
Clonado.
Commits.
Push y pull.
Claves SSH.
Deploy Keys.
Despliegue manual.
Fase 14. Copias de seguridad
Un repositorio Git distribuido ya proporciona copias parciales en los equipos donde se ha clonado, pero eso no sustituye una copia completa de GitLab.
La copia de GitLab debe incluir:
Base de datos.
Repositorios.
Archivos subidos.
Configuración.
Secretos.
Certificados.
Archivo compose.yaml.
Archivo .env.
GitLab advierte de que debe conservarse también gitlab-secrets.json, porque contiene secretos necesarios para descifrar determinados datos durante una recuperación.
GitLab recomienda crear una copia antes de actualizar. Para saltos grandes también puede exigir versiones intermedias obligatorias, por lo que no debe pasarse directamente de una versión muy antigua a la última sin revisar la ruta de actualización.
