Registration & SSO

2.5.1 Overview

The goal of Cloud18 registration in replication-manager is to connect your open source instance to free additional community resources, additional commercial services like support — turning a standalone monitoring tool into a fully supported on-premise solution — and cloud infrastructures for deploying database applications as a service.

Definition — Cloud18: the commercial infrastructure and services that extend the open source replication-manager. It has two dimensions:

1. Signal18 commercial infrastructure — a set of hosted services that enrich the open source replication-manager experience with additional features and support
2. DBaaS marketplace — a marketplace delivered by Signal18 and partner infrastructures where complex database applications can be consumed as a service via replication-manager, deployed on Docker or Podman containers and in some cases on virtual machines

Registering your replication-manager instance with Cloud18 just links your instance under a free plan to a Signal18 identity found at gitlab.signal18.io, and brings:

• Config backup and restore — all replication-manager configurations versioned in a private GitLab repository, recoverable on any new instance in one command
• Community security alert plugins and score — security auditing, CIS Benchmark checks, and scoring plugins kept up to date automatically
• Community workload alert plugins and tags — workload anomaly detection, performance monitoring, and configuration tag plugins
• Community resource documentation and blogs — access to community knowledge base, documentation, and blog content
• Cluster role sharing — grant scoped access to any cluster to other registered SSO users without sharing credentials
• Direct chat — real-time messaging with the Signal18 team and partners via the replication-manager GUI or Mattermost clients
• Arbitration for monitoring HA — external arbitrator service for automatic split-brain resolution between active/standby replication-manager pairs
• Enterprise advisory plugin updates — automatic daily refreshes of security CVE, replication bug, workload regression, and compliance advisory databases without waiting for a new release
• Alert forwarding — cluster ALERT/ALERTOK notifications forwarded to the Signal18 operations team
• Bug fixes and feature requests — direct engineering support for issues and feature development
• Developer sponsorship — fund development of specific features or integrations
• Professional service remote engagement — remote DBA consulting, troubleshooting sessions, and on-site services
• Marketplace namespace — consume clusters provided by other participants or publish your own
• Marketplace credit — free credit to get started on the cloud
• Marketplace provider — expose your replication-manager infrastructure for sale

See Subscription Plans for the full plan comparison.

2.5.2 Concepts — Domain, Subdomain, Zone

Every registered instance is identified by three slugs that together form a unique identifier to your replication-manager running instance:

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.

What each plan unlocks

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"}'

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.