Sovereign managed Kubernetes platform
Moncho.
Operate clusters with evidence in hand.
Moncho is a sovereign managed-Kubernetes platform for banks, government, and regulated enterprises. It provisions clusters through an open-source control plane, then wraps them in a continuous compliance-evidence pack and a signed add-on supply chain — evidence your team can use during evaluation.
Operated by Vigilus Labs; in-country Bangladesh infrastructure is planned.
Capabilities
Operate clusters. Inspect their posture.
Review the capabilities and their availability. Built features are distinguished from live functionality.
Sovereign managed clusters
Kubernetes clusters are provisioned onto dedicated servers through an open-source control plane (k0rdent, k0smotron, Cluster API) and lifecycle-managed from one portal, so a tenant gets a running, governed cluster without operating the control plane themselves.
Federated cluster identity
One organization login, with mandatory multi-factor authentication for financial-sector tenants, reaches every cluster the organization owns, and org admins self-service team-to-role-to-cluster access grants that become per-cluster RBAC, so cluster credentials are never handed out by hand.
Native cluster console
A browser console inside the portal gives resource browsing, live log streaming, YAML apply, and an audited pod terminal by forwarding the tenant's own verified identity token to their cluster, so the tenant's own cluster does all the authorization and the console proxy carries no standing cluster credential.
Per-framework compliance pack
A live evidence assembler continuously maps the platform's real security posture against major control frameworks (including the CIS Kubernetes Benchmark, ISO 27001, and Bangladesh regulatory control sets), tagging each control honestly as verified-live or attested rather than asserting blanket compliance.
Tamper-evident evidence trail
Dated posture snapshots are sealed into a SHA-256 hash-chain and copied in real time into a write-once, object-locked store that stays unaltered even by an administrator, giving auditors a continuously-collectable, provably-unbackdated series.
Continuous CIS benchmarking
A nightly job runs the CIS Kubernetes Benchmark (via kube-bench) against the platform and feeds the pass/fail result into the compliance pack as a measured control instead of an asserted one.
Explore 9 more capabilities
OSCAL evidence export
The compliance pack exports as an OSCAL 1.1.3 Assessment Results document so an auditor's own tooling can ingest the platform's control posture directly.
Signed add-on catalog
Every Day-2 add-on image is mirrored into a private registry, gated by two independent vulnerability scanners (Trivy and Grype) plus known-exploited-CVE and secret checks, and cosign-signed with a self-held key, so tenants never pull an unvetted chart off the public internet.
In-cluster admission enforcement
A Kyverno verifyImages policy runs inside each tenant cluster and rejects any catalog image that is not signed by the platform's own key, so signature enforcement happens at the tenant's own API server at deploy time.
Governed platform-staff access
Emergency access to a wedged tenant cluster is time-boxed, single-cluster, justification-required, and recorded on a tamper-evident chain, and privileged terminal sessions are recorded output-only (never keystrokes or typed secrets) and reviewable solely through a separated auditor role.
Tenant self-service backup and tested restore
Each dedicated tenant runs backup and restore for their own cluster from the portal, backed by Velero writing to a sovereign object store, with a per-tenant, bucket-scoped credential provisioned automatically at cluster creation. A daily restore-to-throwaway drill records a pass or fail on the tamper-evident ledger, so 'the backups are restorable' is a rehearsed, dated control rather than an assertion.
Per-tenant scoped observability
Each tenant sees metrics, per-namespace and per-workload resource drill-down, logs, and service-level objectives with alerts for their own clusters, inside the portal. Every read is scoped to the tenant's own non-forgeable label, so one tenant can never query another's telemetry, and no shared dashboarding tool is exposed.
Client-app egress control
On a dedicated cluster, a tenant can enable default-deny egress from the portal and allow only the destinations they choose, by address and port and by domain name through a managed forward proxy whose access log becomes an egress audit trail. This is exfiltration hygiene a tenant governs over their own workloads, offered as exactly that and not as a platform isolation boundary.
Tenant showback with open-standard export
Postpaid per-node-hour usage is metered into a tamper-evident, hash-chained ledger and surfaced as tenant showback and per-namespace cost, with an export in the FOCUS open cost-reporting format so a finance team can ingest usage without a proprietary schema.
Bring-your-own tenant integrations
An organization admin can self-serve, per tenant, their own external identity provider for single sign-on, a chat webhook for alerts, an SMS gateway for one-time codes, and a SIEM feed that forwards the tenant's own audit events over HTTP, syslog, or a webhook.
Inside Moncho
A closer look at the controls.
Inspect the real interface. Open the image to explore the details at full size.
Under the surface
The details that shape your deployment.
Three isolation tiers
- Dev/Test
- A private Kubernetes API for sandboxes, proofs-of-concept, and internal or cost-sensitive workloads, delivered as a virtual cluster that shares the management hosts. Soft isolation, and not positioned to a regulator as hard isolation. (LIVE)
- Standard (Business)
- A private Kubernetes API for SaaS, staging, and non-regulated enterprise workloads, with its own API server and scoped access as a virtual cluster running on shared nodes. (LIVE)
- Dedicated-BFSI
- A whole cluster per tenant with its own API server, datastore, and dedicated worker nodes that share no kernel, API server, or datastore with any other tenant. Aimed at banks, financial institutions, and government/defense. (LIVE)
Built on open source
Moncho is assembled entirely from open-source foundations, the k0rdent control-plane manager, k0smotron hosted control planes, and Cluster API, rather than a proprietary cloud stack. Its supply-chain trust, the signing and verification of add-on images, runs on self-held keys with no runtime dependency on external, public-good signing or transparency services. That is what lets the whole platform, and the clusters and data it manages, be operated as a self-contained sovereign estate by Vigilus Labs.
Before you evaluate
Availability & limits
OSCAL export is built, not live. Adding a node joins a pre-staged machine, not elastic autoscale. There is no financially-backed availability SLA until a second-site disaster-recovery drill is published, and a fully in-country substrate for restricted data is planned, not yet deployed.
Common questions
A little more context.
What does Moncho's compliance-evidence pack cover?
It maps each control to CIS Kubernetes Benchmark, ISO 27001, and Bangladesh-regulatory framework references, with continuous CIS benchmarking. It is a control crosswalk, not a certification — Moncho reports posture against these frameworks; it does not certify your cluster.
How isolated is each customer's cluster?
Isolation is a spectrum you choose. At the low end, a shared virtual cluster suits sandboxes and cost-sensitive workloads; at the high end, a whole cluster per tenant gets its own API server, datastore, and dedicated worker nodes that share no kernel with any other tenant — aimed at banks, financial institutions, and government.
How does Moncho secure the add-ons it installs?
Add-ons come from a signed catalog — mirrored, scanned, and signed — and are enforced at deploy by an admission policy, so only approved, verified images run in the cluster.
What are Moncho's current limits?
Adding a node joins a pre-staged machine, not elastic autoscale. There is no financially-backed availability SLA until a second-site disaster-recovery drill is published, and a fully in-country substrate for restricted data is planned, not yet deployed.
Your next step
Bring your cluster requirements.
Talk with an engineer. See the product against a scenario that matters to your team.
A conversation with the people building the product.