Registration & SSO

2.5.1 Overview

Registering your replication-manager instance with the Signal18 DBAaS platform links it to a GitLab identity at gitlab.signal18.io. Registration is required to use:

• Config backup and restore — all cluster configurations versioned in a private GitLab repository, recoverable on any new instance in one command
• Community plugins — the full library of workload, security, and score plugins, kept up to date automatically
• Cluster role sharing — grant scoped access to any cluster to other registered SSO users without sharing credentials or VPN
• Cloud18 marketplace — consume clusters provided by other participants or publish your own
• Direct chat — real-time messaging with the Signal18 team and partners

2.5.2 Concepts — Domain, Subdomain, Zone

Every registered instance is identified by three slugs that together form a unique cluster slot:

The three fields are combined as domain.subdomain.zone (the URI) when calling the API.

Inside GitLab the following objects are created:

subdomain.zone must be unique within the same domain. domain.subdomain.zone is globally unique across all registered instances.

2.5.3 Registering via the API

Registration is a two-step process. The admin user calls both endpoints in sequence.

Step 1 — Create the GitLab account

# Obtain an admin token first
TOKEN=$(curl -s -X POST https://repman-host:10005/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"repman"}' | jq -r .token)

# Step 1: create the GitLab account — GitLab sends a confirmation email
curl -X POST https://repman-host:10005/api/register \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email":    "[email protected]",
    "password": "gitlab_password",
    "uri":      "mycompany.ovh.fr-1"
  }'

This creates a GitLab account at gitlab.signal18.io and triggers GitLab's own email confirmation. No external mailer is needed — GitLab handles all email delivery through its built-in SMTP.

Step 1 request fields:

Step 1 responses:

Step 2 — Confirm email and complete registration

Click the confirmation link in the GitLab email, then call:

# Step 2: confirm email and create group + projects
curl -X POST https://repman-host:10005/api/register/confirm \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email":    "[email protected]",
    "password": "gitlab_password",
    "uri":      "mycompany.ovh.fr-1"
  }'

The CRM verifies that the GitLab account is confirmed (confirmed_at is set), then creates the domain group and both Git projects. On success, replication-manager automatically runs the connect flow — no restart required.

Step 2 responses:

2.5.4 What Happens on Success

When the CRM API returns 201 on the confirm step, replication-manager automatically runs the connect flow without requiring a restart:

1. Sets cloud18-domain, cloud18-sub-domain, cloud18-sub-domain-zone from the URI
2. Stores the GitLab credentials (cloud18-gitlab-user, cloud18-gitlab-password)
3. Authenticates to gitlab.signal18.io with basic auth and obtains an OAuth token
4. Creates a personal access token named domain-subdomain-zone in GitLab
5. Idempotently creates the main and pull Git projects under the domain group
6. Sets git-url and git-url-pull in the running configuration
7. Clones the config repository into the working directory (if monitoring-restore-config-on-start is set)

After this, replication-manager continuously pushes configuration changes to GitLab on every tick — no restart required.

If step 3–7 fail (e.g. GitLab is temporarily unreachable), the response still returns 201 but includes a connect_error field. In that case trigger connect manually by setting cloud18=true in global settings once GitLab is reachable.

2.5.5 Registering via the CLI

The replication-manager-cli register command drives the same two-step flow from the terminal. It prompts for the GitLab password interactively (hidden input) so the password never appears in shell history.

Default mode — register and wait

replication-manager-cli register \
  --host  repman-host \
  --port  10005 \
  --user  admin \
  --email [email protected] \
  --uri   mycompany.ovh.fr-1

GitLab password for [email protected]: ••••••••
GitLab account requested for [email protected].
A confirmation email will be sent by GitLab. Please click the link to confirm.
Waiting for confirmation (up to 5 minutes) …
Registration complete. Cloud18 is now active for mycompany.ovh.fr-1.

The CLI polls GET /api/register/status every 10 seconds for up to 5 minutes while you click the GitLab confirmation link. Once confirmed it exits with a success message.

Manual confirm mode

If the background poller already ran (or you want explicit control), pass --confirm after clicking the link:

replication-manager-cli register \
  --host  repman-host \
  --port  10005 \
  --user  admin \
  --email [email protected] \
  --uri   mycompany.ovh.fr-1 \
  --confirm

This calls POST /api/register/confirm once and exits immediately with the result.

Flags

2.5.6 Subscription Plans

Every registered instance starts on the Free plan. Plans are per URI — a user with several repman instances can put each on a different tier.

Plans can be changed at any time from Global Settings → Register → Marketplace in the GUI, or via the API:

TOKEN=$(curl -s -X POST https://repman-host:10005/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"repman"}' | jq -r .token)

# Get the current plan for your instance
curl -s "https://repman-host:10005/api/register/subscription?uri=mycompany.ovh.fr-1" \
  -H "Authorization: Bearer $TOKEN"

# Change to the Support plan
curl -s -X POST https://repman-host:10005/api/register/subscription \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uri":"mycompany.ovh.fr-1","plan":"support"}'

Alert forwarding — only non-free instances forward cluster ALERT/ALERTOK notifications to the Signal18 operations team. Free instances monitor locally only.

2.5.7 Registering via the GUI

Open Global Settings → Register in the replication-manager dashboard. Click Register to open the two-step wizard:

1. Step 1 — fill in email, GitLab password, domain, subdomain, and zone, then click Send Confirmation Email. GitLab sends a confirmation link to the provided address.
2. Step 2 — click the link in the GitLab email to confirm your account, then return to the dashboard and click Complete Registration. The server verifies the confirmation and creates the group and projects automatically.

The Register button is disabled while Cloud18 is already connected. Disconnect first to re-register.

2.5.8 Starting Fresh from GitLab (Restore)

To bootstrap a new replication-manager host from an existing GitLab config repository:

# config.toml
cloud18                          = true
cloud18-domain                   = "mycompany"
cloud18-sub-domain               = "ovh"
cloud18-sub-domain-zone          = "fr-1"
cloud18-gitlab-user              = "[email protected]"
cloud18-gitlab-password          = "gitlab_password"
monitoring-restore-config-on-start = true

Or as command-line flags:

replication-manager monitor \
  --cloud18 \
  --monitoring-restore-config-on-start \
  --cloud18-domain          mycompany \
  --cloud18-sub-domain      ovh \
  --cloud18-sub-domain-zone fr-1 \
  --cloud18-gitlab-user     [email protected] \
  --cloud18-gitlab-password gitlab_password

When monitoring-restore-config-on-start is set, replication-manager:

1. Authenticates to gitlab.signal18.io and obtains a personal access token
2. Clones gitlab.signal18.io/mycompany/mycompany-ovh-fr-1.git into the working directory — replacing any existing local config
3. Clones the pull mirror mycompany-ovh-fr-1-pull.git into <working-dir>/.pull
4. Clears the flag so the restore does not repeat on the next restart
5. Reads cloud18.toml and reconstructs all cluster definitions

2.5.9 Configuration Reference

2.5.10 GitLab Object Mapping

2.5.11 Secret Storage

All secrets (passwords, encryption keys) are AES-encrypted at the replication-manager host before being written to GitLab. The encryption key is generated locally and never leaves the host.

replication-manager host
    └─ AES encryption key  (local only — never synced)
           │
           ▼
     encrypted value  →  GitLab repository  (ciphertext only)

See Security — Configuration Guide for key generation and rotation.