GitLab on a DiskStation

Sometimes, regardless of the possibilities offered by “the cloud”, you want to host important services yourself. For me as a software and DevOp engineer, this applies to my source code. For this reason, I host my GitLab instance myself. Since the GitLab package for DSM provided by Synology is outdated, I will explain here how to install the latest version of GitLab on a DiskStation using Docker.

Preparations

Before we can install GitLab on a DiskStation, we need to make some preparations:

Setup GitLab on a DiskStation

Now we are going to install GitLab. To do so, we need to download the latest docker image of GitLab first. Open the Docker App in DSM, select Registry in the left menu and download the latest gitlab/gitlab-ce image.

GitLab on a DiskStation - DSM Docker Registry Image List

You can watch the download progress in the menu on the left in Image. As soon as the download is complete, a new container can be created with Launch in the upper left corner.

GitLab on a DiskStation - DSM Docker Container General Settings

Before we click on Next, we have to do some configuration in the Advanced Settings dialog.

Volumes

We need to persist three directories of GitLab:

  • /etc/gitlab – configuration directory
  • /var/opt/gitlab – user-generated content (repositories, database, …)
  • /var/log/gitlab – logfiles

We do this by volume mounting into the previously created shared directory.

GitLab on a DiskStation - DSM Docker Container Volume Settings

Port Settings

To allow access to the GitLab instance from outside, we need to define port bindings. These port bindings will forward DiskStation host ports to the GitLab Docker container.

GitLab on a DiskStation - DSM Docker Container Port Settings

After applying all changes and starting the container, it will take a couple of minutes for GitLab to bootstrap the instance. After a while, you should be able to access your new GitLab instance at http://<NAS IP>:8080.

GitLab on a DiskStation - GitLab Set Password Page

On this screen, you can set the password for the root user of GitLab.

Final Configuration

Before your GitLab instance is ready for usage, we have to finalize the configuration. Use the DSM Docker application for shutting down the container.

GitLab on a DiskStation - DSM Docker Container Management

When the container is off, connect to your DiskStation via SSH. Open the GitLab configuration file /volume1/gitlab/config/gitlab.rb and adjust (at least) the following configuration:

  • external_url – Set to the URL you want to use for accessing GitLab.
  • gitlab_rails[‘gitlab_shell_ssh_port’] = 7999 – Use port 7999 for Git via SSH, since port 22 is already taken by your DiskStation.

Further Considerations

External Access

You have to decide how to configure external access to your GitLab instance. The simplest option might be to configure a port forwarding from your router to the GitLab ports on your DiskStation. Another possibility is to use DSM’s reverse proxy.

HTTPS Encryption

Both, DSM and GitLab have built-in support for requesting LetsEncrypt certificates for HTTPS. If you’re not using DSM’s reverse proxy, you should configure LetsEncrypt in your gitlab.rb configuration.

If you’re using the DSM reverse proxy, you can still use GitLab’s capabilities for getting LetsEncrypt certificates or configure HTTPS offloading (the reverse proxy terminates the HTTPS connection and forwards requests internally using HTTP) and use DSM’s capabilities for getting LetsEncrypt certificates. When configuring the hosts, please be sure to enable Websocket Support.

The End

After you finished configuration, use the DSM Docker GUI to start your GitLab container again.

Congratulation! Your GitLab on a DiskStation is now up and running!

For questions, don’t hesitate to leave a comment below. For personal support, you can also contact me directly.

8 thoughts to “GitLab on a DiskStation”

  1. Cool, just planning the same thing, however want to know a bit more on how to integrate a docker registry (this is now supported in the latest gitlab-ce just by enabling a package, I read…) . Any experiences on that? and the runners?
    Thx

    1. Using GitLab’s Docker Registry is quite simple and straight forward. Just enable it in your GitLab settings. The only thing you have to care about is the additional hostname (one for GitLab, one for the registry) in your Reverse Proxy if you’re using one.

      For the runners, there are two ways to go: If you have enough RAM, you could install a Virtual Machine on your DiskStation where the runner resides (and there again with Docker or maybe even better with Kubernetes). Alternatively, buy a Virtual Machine from a Cloud Provider (e.g. Google Cloud, AWS, Hetzner Cloud or Netcup (Affliate Link), …). I would strongly suggest not to use the Docker Daemon of your NAS. I’m even not sure if it’s possible at all.

      Best regards
      Matthias

  2. I found this tutorial useful, thank you.

    I am just dabbling for the first time with self-hosted GitLab having used GitHub for a while now. I want to learn about CI/CD and rather than get dragged into paying for minutes etc figured I’d learn how to self-host.

    My NAS is a 2013 DS1513+ which means it has only 2GB ram. Unsurprisingly it is painfully slow as a GitLab server so I am considering upgrading to a more recent model such as the 1018+ or the 1618+.

    I like the idea of my NAS being my GitLab server too, it seems an efficient use of space and tech. It also means I can easily integrate backing up of GitLab into my existing backups to Synology C2.

    However, before I upgrade, I am trying to establish what sort of performance I would get with GitLab. I assume that the main reason for it being slow on my 1513+ is that 2GB is way below the recommended 8GB, so if I get, say, a 1618+ and fitted it out conservatively with 16GB can I expect fast browsing fo the GitLab site and efficient pushing and pulling or would I find I become limited by the CPU? Can I get it close to a dedicated Ubuntu server in terms of performance or am I always going to find it sluggish due to running in a container on a Synology NAS?

    1. Hey,

      glad that it helped.

      First: You know that you can upgrade the RAM of your DS 1513+? I think 4GB are possible.

      On my DS1817+ with 16GB RAM and previously on a DS718+ with 10GB RAM GitLab was really fast. The main limiting point I see can be the internet connection. I have a 50/10 connection here, so from transfer from the NAS to external users/clients has only 10MBit – sometimes this feels quite slow. I also helped setting up a DiskStation with 8GB RAM and GitLab, which is hosted in a real data center – amazingly fast.

      I can’t promise you anything, since it also strongly depends on how many users you have (in sense of parallel accesses) and which “Dedicated Ubuntu Server” you are comparing to. But I can tell you that I’m quite satisfied with my solution.

      1. Thank you!

        Yes I saw I can upgrade my NAS to 4GB and that was an option I was thinking about but from what it says on the GitLab site 4GB is still below the recommended, so I have kind of discounted it and it’s time to upgrade anyway.

        So what I meant was that browsing even across the LAN on the GitLab site with the DS1513+ is slow, sometimes even timing-out- slow ie nothing to do with my Internet connection, so I just want to be sure there isn’t some sort of inherent slowness about installing GitLab in a docker on a Synology NAS in this way, provided I have enough memory, but your answer has reassured me.

        I of course take your point about parallel accesses etc, for now it would be pretty much just me.

  3. Thanks for the detailed instructions!

    Yesterday I installed GitLab this way on a DS415+ (upgraded from 4 GB to 8GB). Only setting the external_url caused me some issues. After changing gitlab.rb the container started okay, but the URL did not respond. After removing the setting in gitlab.rb I tried the same setting via the GitLab Admin area (logged in as root). Updating “Settings” – “General” – “Visibility and access controls” – “Custom Git clone URL for HTTP(S)” everything worked okay. Just to make sure I tried modifying gitlab.rb a second time, but the effect was the same: no response from the URL I’m using to access GitLab until I removed the setting again.

    Today I’ll try to get the HTTPS interface working (port 8443). I checked the container settings, but I still am not able to get a response from the HTTPS interface. I’ll try to configure GitLab with symlinks to my DSM LetsEncrypt certificate. If I succeed I’ll let you know how I did it.

    Kind regard, Peter.

  4. My fault: I used the external port number (8080) in the external_url in gitlab.rb. But inside the container GitLab is using port 80, so I should not specify the port number. The 8080 to 80 forwarding is done by docker, so invisible to GitLab.

    Once this was solved, configuring SSL was not difficult. I just followed the GitLab Omnibus documentation and first copied the certificate chain and private key I’ve installed in DSM (using symlinks did not work):

    # mkdir /volume1/gitlab/config/ssl
    # cd /volume1/gitlab/config/ssl
    # cp /usr/syno/etc/certificate/system/default/fullchain.pem example.com.crt
    # cp /usr/syno/etc/certificate/system/default/privkey.pem example.com.key

    The following configuration parameters were needed in gitlab.rb:

    external_url “https://example.com”
    nginx[‘ssl_certificate’] = “/etc/gitlab/ssl/example.com.crt”
    nginx[‘ssl_certificate_key’] = “/etc/gitlab/ssl/example.com.key”

    Just to make sure, I used SSH access to DSM to get inside the running container:

    # docker ps
    CONTAINER ID IMAGE …
    57309b1735a7 gitlab/gitlab-ce:latest …
    # docker exec -it 57309b1735a7 /bin/bash
    root@gitlab-gitlab-ce1:/# gitlab-ctl reconfigure

    After enabling HTTPS the HTTP port is no longer active, so in docker I removed the 8080 to 80 forwarding from the container settings.

    Kind regards, Peter.

Leave a Reply

Your email address will not be published. Required fields are marked *