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:
- Signal18 commercial infrastructure — a set of hosted services that enrich the open source replication-manager experience with additional features and support
- 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:
See Subscription Plans for the full plan comparison.
Pick your situation:
Your replication-manager has internet access → register from its GUI: Global Settings → Register, fill email / password / domain / sub-domain / zone, click the link in the confirmation email, done (details in 2.5.7).
Your production is air-gapped (PCI DSS) — or you want to declare instances before installing anything → use the web page, from any connected machine:
https://api.crm.ovh-fr-2.signal18.cloud18.io/register-instance.prod1), Zone = your choice (e.g. fr-1), and your
subscription plan. Click Register instance.-pull project): Signal18
has dropped the plugin binaries there — including your signed licence
plugin (and, for older releases, the license.json licence file).Made a typo? Unregister the instance in the list and register it again.
You script your onboarding → call the API directly (2.5.3).
Every registered instance is identified by three slugs that together form a unique identifier to your replication-manager running instance:
| Field | Role | Example |
|---|---|---|
domain |
Organisation or company namespace — maps to a GitLab group | mycompany |
subdomain |
Datacenter or environment label | ovh |
zone |
Cluster zone identifier | fr-1 |
The three fields are combined as domain.subdomain.zone (the URI) when calling the API.
Inside GitLab the following objects are created:
| Object | Path |
|---|---|
| GitLab group | gitlab.signal18.io/mycompany/ |
| Main config repository | gitlab.signal18.io/mycompany/mycompany-ovh-fr-1.git |
| Peer distribution repository | gitlab.signal18.io/mycompany/mycompany-ovh-fr-1-pull.git |
subdomain.zone must be unique within the same domain. domain.subdomain.zone is globally unique across all registered instances.
Registration is a two-step process. The admin user calls both endpoints in sequence.
# 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": "admin@mycompany.com",
"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:
| Field | Required | Description |
|---|---|---|
email |
Yes | Email address — used as the GitLab username |
password |
Yes | Password for the new GitLab account (min 8 chars) |
uri |
Yes | domain.subdomain.zone — all lowercase, alphanumeric and hyphens |
Step 1 responses:
| HTTP | Meaning |
|---|---|
202 Accepted |
GitLab account created — confirmation email sent by GitLab |
400 Bad Request |
Invalid input (missing field, bad URI format, weak password) |
401 Unauthorized |
No valid JWT provided |
403 Forbidden |
Authenticated user is not admin |
409 Conflict |
Email already confirmed or zone already registered |
502 Bad Gateway |
CRM API unreachable |
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": "admin@mycompany.com",
"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:
| HTTP | Meaning |
|---|---|
201 Created |
Registration complete — Cloud18 connect flow ran successfully |
201 Created + connect_error field |
Projects created but connect failed — see 2.5.4 |
400 Bad Request |
Email not yet confirmed — click the GitLab confirmation link first |
401 Unauthorized |
No valid JWT provided |
403 Forbidden |
Authenticated user is not admin |
404 Not Found |
GitLab account not found — complete step 1 first |
409 Conflict |
Zone already registered |
502 Bad Gateway |
CRM API unreachable |
When the CRM API returns 201 on the confirm step, replication-manager automatically runs the connect flow without requiring a restart:
cloud18-domain, cloud18-sub-domain, cloud18-sub-domain-zone from the URIcloud18-gitlab-user, cloud18-gitlab-password)gitlab.signal18.io with basic auth and obtains an OAuth tokendomain-subdomain-zone in GitLabgit-url and git-url-pull in the running configurationmonitoring-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.
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.
replication-manager-cli register \
--host repman-host \
--port 10005 \
--user admin \
--email admin@mycompany.com \
--uri mycompany.ovh.fr-1GitLab password for admin@mycompany.com: ••••••••
GitLab account requested for admin@mycompany.com.
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.
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 admin@mycompany.com \
--uri mycompany.ovh.fr-1 \
--confirmThis calls POST /api/register/confirm once and exits immediately with the result.
| Flag | Required | Description |
|---|---|---|
--email |
Yes | Email address for the GitLab account |
--uri |
Yes | Registration URI in domain.subdomain.zone format |
--confirm |
No | Skip polling — call confirm endpoint directly (use after clicking the email link) |
--host |
Yes | replication-manager server hostname or IP |
--port |
No | API port (default 10005) |
--user |
No | API user (default admin) |
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.
| Plan | Value | Description |
|---|---|---|
| Free | free |
Default — community plugins (security, workload advisor), config backup & restore, cluster role sharing, marketplace access, direct chat |
| Support | support |
All Free features plus arbitration for monitoring HA, automatic enterprise advisory updates, alert forwarding, bug fixes, developer sponsorship, feature requests |
| Support + Services | support-services |
All Support features plus 12 days per year of DBA professional services and remote engagement |
| Partner | partner |
All Support features plus marketplace provider — publish clusters for sale |
| Feature | Free | Support | Support + Services | Partner |
|---|---|---|---|---|
| Community security alert plugins and score | x | x | x | x |
| Community workload alert plugins and tags | x | x | x | x |
| Community resource documentation and blogs | x | x | x | x |
| Configuration backup and restore via GitLab | x | x | x | x |
| Cluster role sharing with external SSO users | x | x | x | x |
| Marketplace namespace (consumer) | x | x | x | x |
| Marketplace free credit | x | x | x | x |
| Direct chat with Signal18 team and partners | x | x | x | x |
| Enterprise advisory plugins (embedded defaults) | x | x | x | x |
| Automatic enterprise advisory plugin updates (daily) | x | x | x | |
| Arbitration for monitoring HA (split-brain resolution) | x | x | x | |
| Alert forwarding to Signal18 operations team | x | x | x | |
| Bug fixes and feature requests | x | x | x | |
| Developer sponsorship | x | x | x | |
| 12 days/year DBA professional services | x | x | ||
| Professional service remote engagement | x | x | ||
| Marketplace provider (publish clusters for sale) | x | |||
| Per-database and per-application unit pricing | x | |||
| Infrastructure description via Google Spreadsheet | x | |||
| CRM invoicing for marketplace customers | x | |||
| Partner-level collaboration and SLA coordination | x |
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"}'Open Global Settings → Register in the replication-manager dashboard. Click Register to open the two-step wizard:
The Register button is disabled while Cloud18 is already connected. Disconnect first to re-register.
The registration flow is also available as a standalone self-service web page — useful when no replication-manager is reachable from a connected network (see the air-gapped section below), or to manage instances before any installation:
https://api.crm.ovh-fr-2.signal18.cloud18.io/register-instance
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 = "admin@mycompany.com"
cloud18-gitlab-password = "gitlab_password"
monitoring-restore-config-on-start = trueOr 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 admin@mycompany.com \
--cloud18-gitlab-password gitlab_passwordWhen monitoring-restore-config-on-start is set, replication-manager:
gitlab.signal18.io and obtains a personal access tokengitlab.signal18.io/mycompany/mycompany-ovh-fr-1.git into the working directory — replacing any existing local configmycompany-ovh-fr-1-pull.git into <working-dir>/.pullcloud18.toml and reconstructs all cluster definitions| Parameter | Default | Scope | Description |
|---|---|---|---|
cloud18 |
false |
server | Enable GitLab config sync and SSO integration |
cloud18-domain |
"" |
server | Organisation namespace (maps to GitLab group) |
cloud18-sub-domain |
"" |
server | Datacenter or environment label |
cloud18-sub-domain-zone |
"" |
server | Geo-zone identifier |
cloud18-gitlab-user |
"" |
server | GitLab username or email used to authenticate |
cloud18-gitlab-password |
"" |
server | GitLab password (stored AES-encrypted) |
cloud18-crm-api-url |
https://api.crm.ovh-fr-2.signal18.cloud18.io |
server | CRM API base URL called by POST /api/register |
monitoring-restore-config-on-start |
false |
server | Clone config from GitLab on startup and wipe local working directory |
cloud18-self-service-clusters |
false |
server | Let Cloud18 users create clusters on this infrastructure without the subscription chain (see below) |
cloud18-self-service-max-clusters-per-user |
3 |
server | Clusters one Cloud18 identity may sponsor here through self-service |
cloud18-self-service-cache-seconds |
10 |
server | Seconds the self-service status (pool, templates, enabled-script verdict) is served from a snapshot: one computation per interval whatever the request rate on GET /api/cloud18/self-service, 0 computes at every request |
cloud18-self-service-clusters-enabled-script |
"" |
server | Your own gate on every self-service creation: a non-zero exit refuses it, its first output line is the reason (see below) |
cloud18-self-service-clusters-can-borrow |
false |
server | Let a self-service cluster be created on borrowed capacity when the plan pot cannot guarantee its units |
cloud18-self-service-clusters-can-consume-for-sale |
true |
server | Let a self-service cluster take the plans your clusters for sale hold above their floors (see below); off, only the free pool counts, at creation and in the Cloud18 quote |
A marketplace provider (OpenSVC or Kubernetes orchestrator) can let Cloud18 users create a
cluster on its infrastructure directly, from their own replication-manager or from an
AI assistant (MCP), without the subscription and email-acceptance chain. Enable
it in Settings → Cloud → Self-Service Clusters or with cloud18-self-service-clusters = true.
prov-db-dbu,
prov-service-plan-apu, prov-service-plan-bku); no service plan is chosen.cloud18-self-service-max-clusters-per-user clusters
(3 by default), so nobody can flood your listing; dropping a cluster frees a slot.prov-db-dbu) and prov-service-plan-apu, and is refused when the
infrastructure pool (capacity × resource-manager-infra-quota-pct minus the plans already
sold) cannot hold it. Declare the capacity with resource-manager-infra-cpu-cores and
resource-manager-infra-memory-mb when your agents do not report it; an unknown capacity
does not gate.cloud18-shared) keeps only its floor in the pool, the plan it would hold with
every plan lowered as far as the plan rules allow: 1 DBU per database node, 1 APU per proxy
and per running app instance (a failover app 1, a load-balanced app 1 per node it runs on,
a stateful app none), a plan you locked (immutable) whole, and its BKU plan whole. Its plan
above the floor does not block a self-service creation, so the offer stays on sale with a
lower plan without losing a proxy or an app. The status shows that part apart
(forSaleDbu, forSaleApu) and a refusal gives the free and releasable figures. The
Cloud18 quote counts the same room, so a partner is never shown full when a creation would
pass. Set cloud18-self-service-clusters-can-consume-for-sale = false to keep your clusters
for sale out of it: only the free pool counts then. Over-commit is not involved: it is
measured on the resources the services use, not on plans.cloud18-self-service-clusters-can-borrow, a pool that cannot
guarantee the units asks the over-commit pot instead (capacity minus every plan minus what
is already borrowed). The cluster is then created without guarantee, the self-service
status says borrowed with the figures, and the ledger shows the plan pot further overdrawn.cloud18-self-service-clusters-enabled-script runs before every
creation, after the switch and the orchestrator check and before the per-user limit and the
pool. It receives the identity and the orchestrator as arguments and the pool figures in
the environment (REPMAN_IDENTITY, REPMAN_ORCHESTRATOR, REPMAN_SPONSORED_CLUSTERS,
REPMAN_NEEDED_DBU, REPMAN_NEEDED_APU, REPMAN_FREE_DBU, REPMAN_FREE_APU,
REPMAN_FOR_SALE_DBU, REPMAN_FOR_SALE_APU, REPMAN_BORROW_DBU, REPMAN_BORROW_APU). A non-zero exit refuses the creation and the
first line it prints is the reason shown to the user; a script that does not answer within
30 s refuses too. It can only refuse more than the switch, never open what the switch closes.prov-db-apply-dynamic-config and prov-db-dynamic-resource on, so its configuration is
applied live and its resources follow the load from day one (see
Dynamic resources). On OpenSVC the docker run-args cap
is dropped so the PG slice governs; on Kubernetes the requests/limits pair is declared so
the in-place Pod resize applies.mail-to when SMTP is configured, an entry
cloud18_self_service_cluster in the security log, and a warning in the cluster log.GET /api/cloud18/self-service tells a caller whether they may create a cluster here and
how many they already sponsor.GET /api/clusters/{clusterName}/price, for the whole infrastructure with
GET /api/global/price (running month) or /api/global/price/YYYY-MM (a closed month),
on the Resource Manager page, or from the assistant with get-cloud18-cluster-price. The
statement of each month is kept as a file in the working directory, billing/billing-YYYY-MM.json,
closed as final at the month change: that file is what invoicing is built from. Each row
carries the partner and the sponsor identities, so a cluster dropped mid-month keeps its days.| replication-manager concept | GitLab object |
|---|---|
Organisation (domain) |
GitLab group gitlab.signal18.io/<domain>/ |
Instance slot (subdomain-zone) |
GitLab project <domain>-<subdomain>-<zone> under the group |
| Peer distribution | GitLab project <domain>-<subdomain>-<zone>-pull under the group |
| Config history | Commits in the main project repository |
| Team access | GitLab group and project membership with role assignments |
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.
Air-gapped means the replication-manager instance runs with no outbound network, on purpose. It is a legitimate and common security choice — typically a PCI DSS cardholder-data environment, where PCI DSS v4.0 Requirement 1 restricts all traffic into and out of the zone (req. 1.3.1/1.3.2), or any comparably isolated network. The balance for staying offline is that the instance reaches none of the Cloud18 infrastructure at runtime, so:
Air-gapped delivery gives both back as signed files you carry in by hand: you prepare everything from a connected work network, and Signal18 builds and signs the plugins and your licence against your support contract, for you to deposit into the isolated zone. Because the licence is bound to that contract, the set-up starts by linking you to Cloud18 and checking it:
You — on a connected work network Signal18 — Cloud18
───────────────────────────────── ───────────────────
1 Sign up on signal18.io ──────────────▶ Cloud18 account
2 Open the Cloud18 section,
declare your instance ────────────▶ identity domain.subdomain.zone
(domain / sub-domain / zone) │
▼
3 Back office prepares the technical
delivery: builds + signs the
plugins and your licence plugin
for your version
│
▼
4 Checks your support contract in the
ERP — the plan and its end date set
the licence
│
5 Collect the signed files ◀───────────────────── delivery ready
(plugins + licence)
│
▼
6 Deposit into the air-gapped zone, start, verifyThe licence itself is a signed plugin (plugin-licence): replication-manager
verifies it locally against the plugin-signing public key already embedded for
plugin verification, with no network. It:
domain.subdomain.zone) — it does not
apply to any other instance;free) feature set.Releases older than the licence plugin read the previous signed file (
license.json+license.sig, viacloud18-license-file); it is delivered alongside the plugin for them, so an older instance keeps working until you upgrade to the plugin.
license.json): v3.1.41 or newer — delivered
alongside the plugin so an instance still on an older release keeps working.-pull GitLab project the plugins/ binaries for your
version/platform — including the signed plugin-licence (and its .sig),
and, for older releases, the license.json + license.sig. Clone the -pull
project from your work network.cloud18-domain = "yourcompany"
cloud18-sub-domain = "prod1" # identical to the declaration
cloud18-sub-domain-zone = "fr-1"Place the plugins/ directory — with plugin-licence and its .sig — in
the instance plugin location. The licence loads and is verified like any other
plugin; there is no extra setting for it.
Older releases, before the plugin: also copy license.json and license.sig
into the same directory and set
cloud18-license-file = "/etc/replication-manager/license.json"
(replication-manager finds the detached .sig next to it).
No outbound network is ever required in production.