Use your own domain for the cloud Web Console

A NetLock RMM cloud instance is reachable at an address we generate for it, something like 8f3c…-…-….n2.cloud.netlockrmm.com. You can put a subdomain of your own in front of it — rmm.example.com, for instance — so your technicians open the Web Console at an address that belongs to you.

You set the domain in the Members Portal, create one DNS record, and the certificate is obtained and renewed for you. The original address keeps working the whole time; both addresses lead to the same Web Console.

This applies to cloud instances only. A self-hosted installation already runs on whatever address you gave it.

What this does and does not change

Before you start

1. Use a subdomain, not the domain itself. rmm.example.com works; example.com does not. The record type needed here is a CNAME, and DNS does not allow a CNAME on the domain itself. Some providers offer "ALIAS" or "CNAME flattening" at the apex — those resolve to address records and are not accepted.
2. Switch the proxy off for this record. If your DNS provider puts traffic through its own network (Cloudflare calls this the orange cloud), the record cannot be verified and no certificate can be issued. Use "DNS only" (grey cloud) for this record.
3. Check your CAA records. If your domain has CAA records, they have to allow letsencrypt.org to issue certificates. No CAA records at all is fine — that is the common case.
4. International domains go in as Punycode. Enter xn--bcher-kva.example.com, not bücher.example.com.
5. One domain per instance, and a domain can only be used on one instance.

Set the domain

1. Sign in to the Members Portal and open My Products.

2. On the card of your cloud instance, find Your own domain and press Set up your own domain.

3. Enter the domain, for example rmm.example.com. The dialog then shows the DNS record to create, with a copy button for the target.

4. Create that record at your DNS provider:

   Field	Value
   Type	CNAME
   Name	your domain, e.g. rmm.example.com (many providers want just the label, rmm)
   Target	the generated address of your instance, shown in the dialog
   TTL	leave the provider's default
   Proxy / CDN	off

5. Save. The portal checks the record immediately and then keeps checking on its own. You can press Check DNS now to ask again right away.

That is everything you have to do. The rest — verifying the record, routing the domain and obtaining the certificate — happens without you.

What the status means

A new DNS record is usually visible within minutes; some providers take a few hours. Verification is given three days, after which the entry is marked as failed and you can start over.

After the domain is live

Your users can now open the Web Console at either address. A few things are tied to the address they were set up with:

• Passkeys. A passkey belongs to the address it was registered at. If your users sign in with passkeys, have them register one again at the new address.
• Single sign-on. Add the redirect URI of the new address at your identity provider, in addition to the existing one. The Console shows both URIs under Settings → SSO. See Enable SSO with Azure AD / Google.
• Bookmarks, the mobile app and QR codes. These keep pointing at the address they were created with. Both addresses work, so nothing breaks — but a QR code scanned before the change still enrols against the generated address.
• Screen control. The new address registers itself the first time somebody signs in through it; no action needed.

Change or remove the domain

Both are done from the same block on the cloud card.

• Change: press Change domain and enter the new one. Create the CNAME record for the new domain as before. A domain can be changed once per hour and five times per week.
• Remove: press Remove. The routing is taken off within a few minutes and the domain is free to be used again, on this instance or another one. The Web Console stays reachable at its generated address.

Troubleshooting

• "No CNAME record was found for this domain." The record does not exist yet, has not propagated, or you created an A record instead of a CNAME. If the message mentions an address record, that is what happened — or you used the domain itself instead of a subdomain.
• "The CNAME record points somewhere else." The message names the target that was seen. Compare it with the target in the dialog; a missing label or a copied trailing dot is the usual cause.
• "The DNS record is not visible everywhere yet." Two independent resolvers are asked and they do not agree yet. Wait a few minutes and check again.
• "A CAA record of your domain does not allow Let's Encrypt." Add a CAA record for letsencrypt.org, or remove the restricting one.
• The browser shows a certificate warning. If the status is Issuing the certificate, wait — it is not there yet. If the status is Active and the warning persists, the browser is probably showing a cached page; reload without cache.
• The status stays Needs attention. The DNS record was changed or removed after the domain went live. Put it back and the next check restores the status.
• The block does not appear on the card at all. The feature needs a running cloud instance on a prepared server. If your instance is running and the block is missing, contact support.

Related

• Enable SSO with Azure AD / Google — the redirect URI of the second address has to be added at your identity provider.
• Install the Console as an app — the app is installed per address.