Self-hosted multi-cloud management platform with an AI orchestrator. Your data, your cloud, your AI — in your hands. Distilled from 20+ years of datacenter and enterprise experience into one platform.
What CloudManager is
CloudManager is a self-hosted multi-cloud management platform — born out of 20+ years in datacenter and enterprise infrastructure. The goal is straightforward: your data, your cloud, your AI stay in your hands. No vendor lock-in, no external data exfiltration, no marketing claims.
The trigger was the observation that modern infrastructure is fragmented — servers at one cloud provider, containers at another, WireGuard VPNs, Vault for secrets, GitLab for CI/CD, Grafana for monitoring. Each piece has its own logins and APIs. CloudManager brings them under one roof.
Status (August 2026): version 5.309 · 1,300+ API route handlers · around 2,380 tests · 266 database migrations · 9 cloud providers · 47 integrations.
9 providers, one interface
Hetzner, Proxmox, IONOS, Netcup, bare-metal, Exoscale, DigitalOcean, Vultr, OVH — all through the same interface. Provision, migrate, patch servers regardless of vendor. The adapter pattern keeps every provider replaceable; categories like DNS, firewall, VPN, monitoring, CI/CD, Git, secrets, messaging, identity follow the same principle.
Zero-trust security — learned from enterprise
If you’ve run datacenter infrastructure, you know: security is not a feature, it’s architecture. CloudManager is built that way from the start:
- RBAC with three roles across 76+ endpoints
- OpenBao as secrets backend (KV, Transit, PKI, Audit)
- Device Posture with trust score (0–100)
- WebAuthn/FIDO2 passkeys instead of passwords
- 88 security findings addressed during pen-test
The agent — not a dashboard, but eyes and hands
Every managed host runs the CloudManager agent — a native systemd binary (no Docker), communicating with the platform over mTLS:
- 93 endpoints for container management, self-healing, VPN, storage
- Auto-update without downtime
- File integrity monitoring, SSH audit, cert monitor
- Phone-home — new servers register automatically
CloudManager isn’t a wrapper around cloud APIs — it has sensors and actuators directly on every machine.
Privileged access without a separate VPN client: the RA gateway spins up an ephemeral container over the WireGuard mesh, accessible in the browser. With device MFA (FIDO2 liveness checks), session recording, short-lived SSH certificates (30-minute TTL), and auto-cleanup. Six session types covered: SSH, VNC, RDP, browser, NX, RustDesk.
DevForge — the AI orchestrator
DevForge brings AI providers under a shared security umbrella. Describe a task, the orchestrator breaks it into sub-tasks, picks the matching provider, and runs everything through a seven-stage security pipeline:
Injection check → policy engine → budget guard → provider call → output filter → post-policy → NIS2 audit
The catch: Ollama runs on your own bare metal with GPU. No third party sees prompts or data. One click installs drivers and models; the host registers itself as an AI provider.
The AI can never modify its own security policies — PostgreSQL triggers prevent that at the database level. Policies are only activated by humans with WebAuthn and four-eyes principle.
From zero to server — one USB stick
New server, no OS? CloudManager generates an auto-install ISO with cloud-init and agent bootstrap. Insert USB, boot — the server installs itself and registers automatically. Then pick a deployment profile (Ollama AI, worker, K3s, monitoring), one click, done — from bare hardware to running service in minutes.
GDPR & NIS2 — built in
Privacy dashboard with access, export, deletion, retention. DPA template, TOMs, processing record per Art. 30 GDPR. NIS2-compliant audit log with HMAC signing and integrity verification. Compliance isn’t an afterthought — it’s part of the architecture.
Tech stack
Backend: TypeScript strict · Express.js · PostgreSQL 16 · pg-boss (crash-safe job queue on Postgres) · OpenBao · Headscale.
Frontend: React 18 · Vite · Tailwind · TanStack Query · mobile-first PWA.
Infra: Docker · Traefik · OpenTofu · cloud-init · GitLab CI/CD.
One monolith — intentionally, no microservice theatre, with clear responsibilities between backend, agent, and adapters.
Deep dive: Vulnerability management (Article 5)
Patches matter — MSPs know that “somehow”. But “somehow” is not an answer NIS2 accepts, and it’s not an answer that calms a customer when a vulnerability has been exploited. Manually checking, on 30, 50, or 100 customer hosts, which packages are vulnerable doesn’t scale. CloudManager solves it by making vulnerability scanning not a separate tool, but an integrated part of the agent — the same agent that already handles zero trust, posture, and job execution.
Pipeline: from CVE to patched host
Five stages run in coordination:
- Inventory — the agent always knows installed packages, kernel version, running services. The complete software state of the host.
- CVE matching — the package list is matched against NVD, OSV, and GHSA — the three most important CVE databases. Result: a list of open vulnerabilities with CVSS score and patch availability.
- Risk-score update — every CVE raises the host’s risk score depending on its CVSS. A critical CVE (CVSS 9+) adds +60 points — a single unpatched critical CVE can send a host straight into quarantine.
- Action — an alert is generated automatically, a ticket is opened, and a patch job is queued into pg-boss.
- Verification — after the patch the agent checks whether the CVE is actually closed. Only then does the risk score drop. Every step is captured in the NIS2-compliant, HMAC-signed audit trail.
What the agent checks locally
- Package managers:
dpkg, rpm, apk — platform-independent, complete. No package stays unknown.
- Kernel version: kernel CVEs are often the most critical. The agent reads the version straight from the system.
- Running services: a vulnerable service that shouldn’t be running at all is especially critical. The agent detects that too.
The result goes directly to the CloudManager backend: risk score updated, CVE report created, patch recommendation generated — without manual intervention.
CVSS → risk-score mapping
The industry-standard CVSS rates vulnerabilities from 0 to 10. CloudManager translates that directly into the risk score from the zero-trust stack:
- Low (0.1 – 3.9): +5 points. No immediate alert. Next patch window is enough. SLA: 30 days.
- Medium (4.0 – 6.9): +20 points. Alert at warning level. Patch job scheduled. SLA: 14 days.
- High (7.0 – 8.9): +40 points. Urgent alert. Patch job scheduled immediately. Host is moved to elevated status. SLA: 72 hours.
- Critical (9.0 – 10): +60 points. Critical alert. Immediate patch or quarantine. SLA: 24 hours.
Scores add up. Two High CVEs (+40 each) total +80 points — that’s enough for quarantine. Not coincidence, design: a host with several open vulnerabilities is a real risk even if every individual CVE is “only” High.
Patch modes: auto vs. approval
Not every customer wants fully automatic patching — production systems sometimes need controlled maintenance windows. CloudManager supports both:
- Auto: the agent patches itself (
apt upgrade, yum update, dnf update) and reports the result immediately. For uncritical systems, or when the customer configures it explicitly.
- Approval: the admin gets a notification with all the details — CVE, CVSS, affected packages, suggested patch. They pick the time window and approve. The job then runs at the scheduled time.
In both cases: post-patch verification by the agent, automatic audit entry, risk-score update.
MSP compliance dashboard
Possibly the strongest feature for MSPs: a compliance overview that shows every managed customer at a glance. Which tenant has open critical CVEs, how many hosts are compliant, which risk score sits where — colour-coded by severity (green, amber, red). For red tenants, patch jobs are scheduled automatically and a “Patch now” button is offered.
This is not a manual summary — the data comes directly from the agent on each host, aggregated in real time.
NIS2 requires affected companies and their service providers to do systematic vulnerability management. Concretely: CVEs must be detected, assessed, remediated, and documented — with evidence. CloudManager delivers exactly that: NVD/OSV/GHSA matching for detection, CVSS-based assessment, automated patch jobs for remediation, HMAC-signed audit trail for evidence. No separate vulnerability-scanner tool, no manual documentation — everything integrated into the platform MSPs already use for infrastructure management.
Deep dive: Observability (Article 6 · April 24, 2026)
Observability is not a dashboard — it’s the ability to understand the state of a system. Not just that something is red, but why, since when, on which host, for which customer, with what impact. For MSPs with 10, 30, 100 tenants this means metrics, logs and alerts must be multi-tenant by design. Customer A may never see logs from customer B. That is the difference between observability as a tool and observability as an architectural property of the platform.
Prometheus as integration
Prometheus is wired in as an adapter — replaceable with VictoriaMetrics, Mimir, or DataDog depending on customer preference. Standard, works well. Every 15 seconds three sources per host are scraped:
- Node-Exporter — the basics: CPU, RAM, swap, disk I/O, network
- cAdvisor — container metrics: who’s eating resources, what crashed, how long it has run
- CloudManager agent — its own metrics: heartbeat status, open CVEs, pg-boss queue length, agent latency. Exactly the metrics no standard exporter provides.
Prometheus TSDB with 90 days retention — long enough for trend analysis and incident forensics, short enough to keep storage in check.
Loki — logs as an active security sensor
Loki does not index log content, only labels. That makes it considerably cheaper to operate and ideal for multi-tenant setups: Promtail automatically attaches tenant_id, host_id, environment, and severity on push. What’s collected: Nginx and Traefik access logs, CloudManager API logs, agent events and posture reports, Keycloak auth events, systemd-journal. Every entry carries the tenant ID — that guarantees isolation.
Logs are not passive storage: an auth anomaly event (three failed logins within 60 seconds) directly triggers a Loki alert that lands in the CloudManager alertmanager.
Why the alertmanager is custom-built
The question I hear most often: Why not just use the Prometheus Alertmanager? Four concrete reasons:
- Multi-tenant routing as a first-class concept — Prometheus AM has no notion of tenants. Routing customer A vs. B would be config acrobatics that grows manually with every new customer. In the custom-built one,
tenant_id is first-class: alerts route to the responsible admin automatically, notification channels are configured per tenant.
- Risk-score integration — Prometheus knows nothing about trust scores. The custom one is wired directly into the risk-score system: every alert can adjust a host’s trust score immediately — and thereby trigger the zero-trust layer.
- NIS2-compliant audit trail — Prometheus AM does not write a NIS2-grade audit log. In the custom one every alert is a PostgreSQL record with a full lifecycle (created, fired, acknowledged, resolved), HMAC-signed, immutable.
- Job-queue trigger — a critical alert shouldn’t just notify but kick off a job (queue a patch job, open an incident, investigate a host). The custom one creates pg-boss jobs directly.
Two concrete alert flows
CPU load over 90 % for 5 minutes. Prometheus detects the threshold and fires an alert rule. The CloudManager alertmanager receives, deduplicates, routes to the responsible tenant admin, and immediately raises the host’s risk score by 15 points. Headscale re-evaluates the ACL tags. A pg-boss job investigate:host is queued. The admin gets a Slack message and a ticket. When the alert resolves, the risk score drops — the host returns to tag:trusted.
3 × auth failure within 60 seconds. Loki detects the pattern in Keycloak logs and fires a Loki alert. The alertmanager raises the risk score by 40 points — the host lands straight in tag:quarantine. Network isolated, certificate revoked, incident opened. Fully automatic, fully audited.
That is observability that acts — not observability as a display.
Grafana is where MSPs and customers see what’s happening — again as an integration, not a core. But the best choice for unified dashboards that combine Prometheus metrics and Loki logs in one view. Out of the box, CloudManager ships with:
- Host overview with CPU, RAM, disk, network — per tenant and aggregated
- Container health across all hosts
- Agent status and heartbeat
- CVE overview and patch status
- Alert history with severity distribution
No manual dashboard configuration each MSP has to build themselves — the dashboards come with the platform.
Why Prometheus and Loki stay integrations
Observability stacks are plentiful. Prometheus + Loki + Grafana is a proven combination — but as a separate stack each MSP runs and configures themselves, it’s a burden, not an asset. In CloudManager, Prometheus and Loki are replaceable, modular, customer-selectable. The alertmanager is built in, because it is the single point where metrics, logs, risk score, zero trust, and the job queue come together. Using a ready-made tool for it would mean giving up exactly the deep integration that distinguishes CloudManager from a monitoring dashboard.
Why this matters for the role
CloudManager is my practical learning path for the very topics I currently shape professionally: zero-trust architecture, multi-cloud, GitOps, container orchestration, vulnerability management, AI governance. The platform also runs this CV site itself.
