Connect to the service

How it works

clm.mt is being prepared as a SaaS service: a central control plane for your team, with installed agents that can reach your infrastructure. You use the browser dashboard to configure policy, integrations and assignments. An agent on your network connects outbound over HTTPS, fetches its assigned work and reports results.

With an agent-managed certificate, its private key stays in agent state and the configured deployment destinations. The service receives the public certificate, status and lifecycle events. Eligible API-based work can also use a hosted runner; that mode stores sealed private-key state on the service. Read the key-custody boundaries.

You install the agent, not a copy of the central platform. Running the control plane, HTTPS, backups and server updates is the service operator’s responsibility. A customer self-hosted offering is a later roadmap item.

Before you start

Shared SaaS onboarding is not generally available yet. Use an operator-arranged pilot account and the service URL supplied for that pilot; there is no public signup promised by these guides.

• An account in the intended organisation (an administrator can invite you by email) and an administrator who can create an enrollment token.
• A Linux host with systemd or a Windows Server host, with outbound HTTPS to the service.
• An eligible CA account, least-privilege DNS credentials and a disposable staging domain.
• A supported target, a service identity with appropriate permissions and a named recovery owner.

Your first deployment

1. Install and enroll an agent, then confirm its online status and capabilities.
2. Connect CA and DNS and check entitlement before production issuance.
3. Run preflight and resolve failures; treat unknown checks as work still to prove.
4. Issue, deploy and verify a staging certificate, then exercise recovery.