edgeContinuum is an OpenStack management platform that turns the deployment you already operate into managed OpenStack: a self-service console, managed Kubernetes, PostgreSQL and VMs, and real multi-tenancy, without reinstalling anything underneath.
Horizon was built for operators, and it shows: every VM, network and volume is a form to fill, every Kubernetes cluster is a project someone glues together, and every request from a team lands in a queue in front of the few engineers who know OpenStack well. An OpenStack management platform closes that gap without touching what works: edgeContinuum layers a self-service portal, managed services and structural multi-tenancy on top of your existing deployment, and drives everything through declarative desired state instead of tickets. Wondering whether you need this at all when OpenStack already runs? The architectural answer is here.
OpenStack ships the primitives extremely well. What it never shipped is the layer your teams actually touch, which is why so many deployments end up with a capable cloud that only the operators can use. These are the five things that layer has to add, and what each one becomes on the platform.
Managed OpenStack is not a second OpenStack. It is the operating layer that sits above the one you run: your clouds stay where they are, and the platform takes over provisioning, lifecycle and tenancy for everything on top of them.
Keystone, Nova, Neutron and Cinder are untouched and unforked. Operators keep Horizon and their CLIs; the platform authenticates against your cloud and drives it through its own APIs.
Kubernetes clusters, PostgreSQL instances, VMs and marketplace apps are products a team orders, then the platform keeps them in desired state: upgrades, autoscaling and self-healing included.
Organizations, projects, roles and quotas are enforced by the platform’s own IAM, with usage tracked per tenant per resource, rather than improvised on top of OpenStack project names.
That combination is what separates edgeContinuum from most OpenStack cloud management platforms, which stop at making the same primitives easier to drive. What teams actually weigh it against is raw OpenStack with Horizon: an operator tool, no managed Kubernetes or PostgreSQL, projects instead of tenants, and no per-tenant usage to hand to accounting. The self-service platform architecture guide works through that layer component by component, and the Kubernetes on OpenStack architecture guide does the same for clusters.
Point edgeContinuum at your OpenStack and teams stop filing tickets: they create Kubernetes clusters, PostgreSQL instances and VMs from the console, the API or Terraform, inside quotas and roles you define. Horizon stays for your operators; this is the front door for everyone else.
Raw OpenStack ends at VMs, networks and volumes. edgeContinuum adds the layer your teams actually ask for: managed Kubernetes with autoscaling and in-place upgrades, managed PostgreSQL with lifecycle handled, VM catalogs managed like public cloud, and an app marketplace where anything Kubernetes-deployable becomes a one-click product. The databases on OpenStack guide covers the database layer in detail, including why the platform uses neither Trove nor a guest agent inside your instances.
CNCF-conformant, dedicated or hosted control planes.
HA, size and storage declared up front; lifecycle managed.
Image and flavor catalogs, networks and firewall rules.
Helm charts and containers as one-click products.
Most platform teams accumulate a private library of things that are technically easy and organizationally slow: a Redis four teams each deploy differently, an internal service with a chart and a page of setup notes, a monitoring stack somebody maintains out of goodwill. The marketplace is where that stops being folklore. Anything deployable on Kubernetes, a public Helm chart or a private template you wrote, becomes a product in a catalog you curate, with the values you consider sane already set.
Teams stop asking how to deploy the thing and start asking whether they need it. Versions converge, because there is one entry rather than five forks of a values file, and the platform team gets a real distribution channel: publish once, and every organization can order it inside the quotas you already set.
Quotas are the difference between self-service and a slow-motion outage. OpenStack has per-project limits, but they describe raw resources rather than what teams consume, so a project can sit inside its quota and still hold three unmanaged Kubernetes clusters nobody budgeted for. The platform enforces limits where people actually work: organizations, projects, roles, and the managed resources inside them. The users, projects and quotas guide sets out how Keystone models identity and quotas today, and exactly where that model stops short of this.
A platform team can hand a business unit or a client a boundary they cannot accidentally cross, then stop supervising it. Each organization sees its own consumption, roles decide who can create what, and usage is tracked per tenant per managed resource. That is tracking, not invoicing: the figures feed whatever billing system you already run.
Worth being precise about the boundaries, because "managed OpenStack" is a phrase several vendors use to mean quite different things.
It also does not operate the underlying infrastructure for you. Hardware, hypervisor, storage arrays and the physical network stay yours, as does the OpenStack control plane itself. The platform manages the services on top and the experience around them. If what you need is somebody to run OpenStack itself under an SLA, that is a managed service provider engagement, and a different purchase from this one.
Organizations, projects, users, roles and quotas, enforced by the platform’s IAM. Each team or client gets an isolated organization with its own members and limits, and usage is tracked per tenant, ready for your accounting. Isolation is structural, not a naming convention on top of OpenStack projects.
On a bare deployment, who can do what is a role name plus a policy file per service, edited by hand and reviewed by whoever remembers the syntax. There is no catalog to browse, no group to grant once, and no way to say restart this machine but never delete it without writing a rule for it. That is why so many teams end up with two levels of access, full and none, and a queue in front of the few people holding the first one.
edgeContinuum puts one permission model over the whole platform: more than 200 individual permissions, roles you compose from them, granted to a user or a group, at organization or project scope. It covers the managed Kubernetes clusters and PostgreSQL instances as well as the machines and networks underneath. Read how identity and access works, or the guide on users, projects, roles and quotas in OpenStack for what Keystone models natively If you are weighing this against a portal or a billing product on top of OpenStack, the comparisons with Fleio and OSIE set out where each one is stronger.
Connect any number of OpenStack deployments (data centers, private clouds, edge sites) and shape them into your own regions and availability zones. Push that out to many small facilities and you get edge computing on OpenStack, run from the same console. Regions are autonomous: if a site loses its link, workloads and local management keep working and resync when connectivity returns.
one console, one API, one IAM across all of themConnect a lab OpenStack on the free trial, or book a call and we’ll demo the loop end to end: connect, curate, provision, operate.
