---
title: "Deploy GitLab CE: Git hosting and CI/CD, GitHub alternative"
description: "Private Git repos, merge requests, CI/CD pipelines, issue boards and wiki"
category: "Other"
url: https://railway.com/deploy/gitlab-ce-fixed
---

# Deploy GitLab CE: Git hosting and CI/CD, GitHub alternative

Private Git repos, merge requests, CI/CD pipelines, issue boards and wiki

**[Deploy GitLab CE: Git hosting and CI/CD, GitHub alternative on Railway](https://railway.com/template/gitlab-ce-fixed)**

Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/gitlab-ce-fixed/manifest.json

- **Creator:** ProCode
- **Category:** Other
- **Total deploys:** 8

## Template content

### GitLab https://about.gitlab.com/images/ico/favicon-192x192.png

- **Image:** gitlab/gitlab-ce:19.4.2-ce.0
- **Start command:** `/bin/bash -c 'set -e; mkdir -p /var/opt/gitlab/etc-gitlab; if [ ! -L /etc/gitlab ]; then cp -an /etc/gitlab/. /var/opt/gitlab/etc-gitlab/ 2>/dev/null || true; rm -rf /etc/gitlab; ln -s /var/opt/gitlab/etc-gitlab /etc/gitlab; fi; set +e; /assets/init-container & child=$!; trap "gitlab-ctl stop sidekiq; gitlab-ctl stop puma; gitlab-ctl stop; rc=\$?; kill -TERM $child 2>/dev/null; wait $child; exit \$rc" TERM; wait $child'`
- **Health check:** /users/sign_in
- **Public domain:** Yes

## Documentation

# Deploy and Host GitLab on Railway

GitLab Community Edition is the free, MIT-licensed edition of GitLab: Git repositories, merge requests with code review, issues and boards, wikis and CI/CD pipelines in one application. This template runs the official GitLab image, pinned to an exact release, with HTTPS on your Railway domain and Git over SSH through a TCP proxy. You get a private GitHub alternative on your own infrastructure without setting up a server, a reverse proxy or certificates.

## About Hosting GitLab

GitLab ships as one container that runs everything it needs: PostgreSQL, Redis, Gitaly for repository storage, Sidekiq for background jobs, Puma for the web app and nginx in front. This template configures it for a single Railway service using [GitLab's own low-memory settings](https://docs.gitlab.com/omnibus/settings/memory_constrained_envs/), and keeps repositories, the database, uploads, GitLab's configuration and secrets, and the SSH host keys on one volume. CI/CD variables, two-factor secrets and SSH fingerprints survive every redeploy. The root password is generated for you. First boot takes about six minutes while GitLab sets up its database; redeploys take about three.

## Common Use Cases

- **Private Git hosting for a team**: repositories, branches and history on infrastructure you control, cloned over HTTPS or SSH.
- **Code review with merge requests**: open a merge request from a branch, review the diff, approve and merge in the browser.
- **Issue tracking and planning**: issues, issue boards and a wiki next to the code they describe.
- **A central GitLab for your CI runners**: pipelines are defined in `.gitlab-ci.yml` and run on GitLab Runner machines you register against this instance.

## How to Use GitLab After Deployment

1. Wait for the GitLab service to show **Active**. The first boot takes about six minutes.
2. Open the service's public URL (GitLab service, **Settings**, **Networking**).
3. Sign in as `root`. The password is `GITLAB_ROOT_PASSWORD` in the GitLab service's **Variables** tab.
4. GitLab opens with two setup screens, **Create your first project** and **Set up your profile**. Fill them in or press **Skip** on each.
5. Add your SSH key: avatar menu, **Edit profile**, **SSH Keys**. SSH clone URLs use the TCP proxy host and port, for example `ssh://git@example.proxy.rlwy.net:12345/group/project.git`, and the project page shows the exact one.
6. Decide who may register. New accounts need an administrator's approval by default; to turn sign-up off, go to **Admin**, **Settings**, **General**, **Sign-up restrictions**.
7. To run pipelines, register a runner on a machine you run, such as a VM or any server with Docker: **Admin**, **CI/CD**, **Runners**, **Create instance runner**, then follow the steps GitLab shows ([GitLab Runner docs](https://docs.gitlab.com/runner/)).

## Dependencies for GitLab Hosting

- GitLab (`gitlab/gitlab-ce`, pinned to an exact release): the whole application, with a volume at `/var/opt/gitlab`.

### Deployment Dependencies

- [GitLab](https://about.gitlab.com)
- [GitLab Docker installation docs](https://docs.gitlab.com/install/docker/)
- [GitLab source (MIT)](https://gitlab.com/gitlab-org/gitlab)

### Implementation Details

**Memory:** GitLab idles at about 3.2 to 3.5 GB on this template. The Hobby or Pro plan is required; Free and Trial services cannot hold it.

**Configuration:** every GitLab setting lives in `GITLAB_OMNIBUS_CONFIG` as `gitlab.rb` lines separated by semicolons. To change one, add a line at the end and redeploy.

**Switched off to save memory:** Prometheus monitoring and the Kubernetes agent server. The container registry and GitLab Pages are off too, since each needs its own hostname.

**Email:** GitLab sends no email until you add SMTP settings. Append them to `GITLAB_OMNIBUS_CONFIG` (`gitlab_rails['smtp_enable'] = true; gitlab_rails['smtp_address'] = 'smtp.example.com'; ...`, per [GitLab's SMTP docs](https://docs.gitlab.com/omnibus/settings/smtp/)). Railway allows outbound SMTP on the Pro plan only.

**How to Upgrade:** change the image tag on the GitLab service to a newer `gitlab/gitlab-ce` release and redeploy. Follow [GitLab's upgrade path](https://docs.gitlab.com/update/upgrade_paths/) and stop at each required version on the way. You can also turn on automatic image updates (GitLab service, **Settings**, **Source**, **Configure Auto Updates**) with **Patches only**, which keeps you on the same minor version. The pre-update volume backup is Pro plan only, so back up first on Hobby.

## Is GitLab Free?

GitLab Community Edition is MIT-licensed with no user limit. The paid Premium and Ultimate tiers add features on top; repositories, merge requests, issues, wikis and CI/CD are all in the free edition. On Railway you pay only for the resources the service uses.

## How This Template Compares to Other GitLab Templates

This template pins an exact GitLab release. Some GitLab templates on Railway run the `latest` tag instead, so every deploy pulls whatever GitLab released most recently. That causes three problems:

- **A redeploy can break a working instance.** A new release can fail on your setup, and GitLab refuses to start when an update skips one of its required upgrade versions, which `latest` does once a few releases have gone by since your last deploy.
- **A new environment can fail while your current one works.** A staging or test environment created today pulls today's `latest`, which is not the release your main environment is running.
- **Two environments that look identical can run different versions.** Both show `latest`, but each runs the release that was current when it last deployed, so they drift apart with nothing on screen to show it.

We keep this template current: when GitLab ships a new release, we test it on a fresh deployment and then move this template's pinned version forward, so every new deployment gets the newest release we have seen work. Your existing deployment stays on its version until you choose to update it.

With a pinned release, updating is a choice you make and can test first:

1. Duplicate your environment: open the environment dropdown in the top bar, choose **+ New Environment**, then **Duplicate Environment**, and approve the staged changes.
2. In the copy, open the GitLab service, go to **Settings**, **Source**, change the image tag to the release you want, and deploy the change.
3. Test the copy. If it works, back up your main environment and make the same tag change there. Follow [GitLab's upgrade path](https://docs.gitlab.com/update/upgrade_paths/) when moving across several releases.

## FAQ

**Why does my pipeline stay pending?**
GitLab runs pipeline jobs on GitLab Runner, and this template ships none. Register a runner on a machine you run (step 7 above) and pending jobs start.

**Does Git over SSH work?**
Yes. Railway's TCP proxy forwards to GitLab's SSH server, and clone URLs already carry the proxy host and port.

**Can I use my own domain?**
Add the custom domain under **Settings**, **Networking**, then set `GITLAB_HOST` to it and redeploy so GitLab's links and HTTPS clone URLs use it.

**How do I back up GitLab?**
Run `gitlab-backup create` in the GitLab service's shell, then keep `/etc/gitlab/gitlab-secrets.json` with the backup ([GitLab's backup docs](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/)). [GitLab's restore docs](https://docs.gitlab.com/administration/backup_restore/restore_gitlab/) cover the way back.

## Why Deploy GitLab on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying GitLab on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

## Similar templates

- [Rocky Linux](https://railway.com/deploy/rocky-linux) — Hosted Rocky Linux 9 workspace with SSH and persistent storage. 🚀
- [Foundry Virtual Tabletop](https://railway.com/deploy/X5tR6G) — A Self-Hosted & Modern Roleplaying Platform
- [Letta Code Remote](https://railway.com/deploy/letta-code-remote) — Run a Letta Code agent 24/7. No inbound ports, just deploy.

Open this page in a browser: https://railway.com/deploy/gitlab-ce-fixed