[Docker] GitLab on Synology NAS

I recently set up GitLab CE on my Synology NAS using Docker, with reverse proxy enabled so that I can access it via https://git.domain.com.

Here’s the docker-compose.yaml I used:

services:
  # ── GitLab CE (Community Edition) ──────────────────────
  gitlab:
    image: gitlab/gitlab-ce:18.0.5-ce.0
    container_name: gitlab
    restart: always
    hostname: 'git.wody.kr'                  # Public domain or internal host
    ports:
      - '7080:80'                            # HTTP access
      - '7443:443'                           # HTTPS access
      - '7022:22'                            # SSH (Git over SSH)
    volumes:
      - '/volume1/docker/gitlab/config:/etc/gitlab'        # GitLab config
      - '/volume1/docker/gitlab/logs:/var/log/gitlab'      # GitLab logs
      - '/volume1/docker/gitlab/data:/var/opt/gitlab'      # GitLab application data
    shm_size: '256m'                          # Shared memory size (recommended minimum)

Why I Pinned the Version

A few years ago, I lost all my GitLab data when an upgrade corrupted the database during migration. To avoid repeating that mistake, this time I specified a fixed version tag (18.0.5-ce.0).
⚠️ Lesson learned: never casually upgrade GitLab—version upgrades require extra care.

Reverse Proxy Setup

After starting the container, I set up a reverse proxy on my NAS pointing to port 7080. With this, GitLab is accessible at:

https://git.domain.com

The URL Problem

One issue I ran into: after logging in and navigating my projects, GitLab displayed project links as:

http://git.domain.com

Instead of https://. This looks messy and breaks the flow. I searched through the docs but didn’t find a perfect solution. Eventually, I found a configuration option that allows me to force GitLab to use HTTPS URLs. It works, but honestly, it feels like a bit of a hack, and I’m still not fully satisfied with it.

Repository Access

To clone or push to my repositories, I now use:

https://git.domain.com/username/project.git

This works fine for day-to-day use, even if the UI URL issue isn’t 100% clean.