GitLab

Before you start

• A self-managed GitLab (Omnibus)

1Configure SMTP

# /etc/gitlab/gitlab.rb
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.mailclutch.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "mc_0000000000000000"
gitlab_rails['smtp_password'] = "pw_0000000000000000"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['gitlab_email_from'] = 'staging@example.com'

sudo gitlab-ctl reconfigure

2Send a test message

# sudo gitlab-rails console
Notify.test_email('anyone@example.com', 'Sandbox check', 'Hello from GitLab.').deliver_now

Watch it land

Open the sandbox and the message is there — rendered HTML, plain text, raw source, attachments, and the SPF, DKIM and DMARC verdicts. It updates live, so you can leave it open next to your terminal.

Nothing is ever delivered onward, whatever address you send to; claim the inbox with an account and it stays.

What usually goes wrong

• Nothing leaves the instance

  With this in place, every invitation, pipeline failure and merge request notification lands in the sandbox — useful on a staging instance restored from a production backup.

• Delivery is asynchronous

  GitLab sends through Sidekiq. If a message does not appear, check that Sidekiq is running before suspecting the credentials.

Other stacks

The same four values in another dialect. Every guide below is filled in with the sandbox pair at the top of this page.