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

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, 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

Wait for the GitLab service to show Active. The first boot takes about six minutes.
Open the service's public URL (GitLab service, Settings, Networking).
Sign in as root. The password is GITLAB_ROOT_PASSWORD in the GitLab service's Variables tab.
GitLab opens with two setup screens, Create your first project and Set up your profile. Fill them in or press Skip on each.
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.
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.
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).

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

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). 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 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:

Duplicate your environment: open the environment dropdown in the top bar, choose + New Environment, then Duplicate Environment, and approve the staged changes.
In the copy, open the GitLab service, go to Settings, Source, change the image tag to the release you want, and deploy the change.
Test the copy. If it works, back up your main environment and make the same tag change there. Follow GitLab's upgrade path 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). GitLab's restore docs 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.