Docs
Sign In

You already have OpenStack. Now turn it into a managed cloud

OpenStack gives you compute, networking, storage, identity and APIs. edgeContinuum builds on that foundation and adds organizations, fine-grained access, managed Kubernetes, managed databases and applications, through one self-service experience. Your deployment stays exactly where it is.

See edgeContinuum on OpenStackTalk to us about your cloud
Not a fork, not a distribution, not a new hypervisorNova, Neutron, Cinder and Keystone stay as they are
Where each layer sits
Customers and developers
edgeContinuum
Managed Kubernetes · PostgreSQL · VMs · Applications
Your existing OpenStack
Nova · Neutron · Cinder · Keystone · Glance
OpenStack stays underneath. Nothing about it changes.

OpenStack gives you the building blocks

Nova runs compute, Neutron builds the networks, Cinder provides block storage, Keystone models identity, and each has a real API with projects and quotas behind it. If you operate a deployment today, the hard part of a private cloud already works.

Operating those primitives is a different job from delivering a cloud product. A team that wants a Kubernetes cluster does not want instances, a network and a runbook. A client buying managed PostgreSQL does not want a volume and a flavour. That is the gap this page is about.

What edgeContinuum adds on top

Projects, users, roles and quotas
Organizations holding projects, users and groupsPermissions per action, across an organization or inside one project. See identity and access.
Infrastructure Kubernetes can run on
Kubernetes as a service in the catalogControl plane upgrades, node pool scaling and autoscaling, failed nodes healed. See managed Kubernetes.
Compute, network and storage primitives
PostgreSQL as a managed serviceHigh availability, version upgrades and storage growth handled. See managed PostgreSQL.
Separate APIs, one per component
One console, one API, one Terraform providerHorizon and your OpenStack CLI stay exactly where they are for operators.
One deployment, its own regions
Many infrastructures under one platformSeveral deployments or edge sites, shaped into your own regions and zones.

Same infrastructure. A different consumption model

OpenStack on its own
A team needs a cluster or a database
Instances, networks, volumes, images
Kubernetes and database tooling
Runbooks and internal automation
Nova · Neutron · Cinder · Keystone
edgeContinuum on OpenStack
A team orders from a catalog
One service layer
VMs · Kubernetes · PostgreSQL · Apps
IAM · Quotas · Usage · API · Terraform
The same Nova, Neutron, Cinder, Keystone
Same OpenStack infrastructure. A different consumption model.

What changes for your customer

Open a row if you want the detail behind it.

"We need a PostgreSQL database"

OpenStack on its ownAssemble itInstances, storage, network, replication, then someone owns it
With edgeContinuumOrder itPick a version and a size, get an endpoint
More detail
On raw infrastructure the provider combines compute, storage, networking, the database deployment, high availability and permissions through separate systems, then keeps operating all of it. Here PostgreSQL is a catalog product: the customer picks a version and a size inside their quota and receives a connection endpoint, while the platform runs high availability, in-place version upgrades and storage growth.

"We need a Kubernetes cluster"

OpenStack on its ownBuild the clusterTemplates, images, CNI, storage class, then upgrades forever
With edgeContinuumGet a kubeconfigRegion, control plane model, node pools, minutes
More detail
Kubernetes on OpenStack is a build whichever route you pick, and the cost lands on day two: upgrades, node pool changes, healing, CNI and storage wiring. The platform provisions through Cluster API with the OpenStack provider, offers dedicated or hosted control planes, and owns those operations. The architecture guide compares the routes.

"We need a few virtual machines"

OpenStack on its ownAlready works wellThis is what Nova is for, and it is good at it
With edgeContinuumSame VMs, guardrails around themInside an organization, a quota and a role
More detail
This is the request where OpenStack alone is closest to sufficient, and it would be dishonest to pretend otherwise. What the platform adds is context rather than capability: the machine belongs to a project inside an organization, counts against that tenant's quota and usage, and can be operated only by whoever holds that permission. Existing machines, networks, firewalls and SSH keys can be imported rather than rebuilt.

"We need this application deployed"

OpenStack on its ownSomeone writes it downA chart, a wiki page, a script per customer
With edgeContinuumPublish it onceHelm or container app in the catalog, versioned
More detail
The catalog holds Helm and container applications with versioned manifests and your own registry credentials, private to a project or published platform-wide, so what your team figured out once becomes a product every tenant can order.

Keep the OpenStack you already operate

Not a fork or a distributionUpstream services, upstream APIs, no build of Nova to track.
Not a replacement hypervisorNothing installed on your compute nodes.
Not a replacement for Nova, Neutron or CinderDriven through their own APIs, the ones you already use.
Not a rebuild of your cloudYour architecture, knowledge and hardware investment survive.

It is not zero work either: connecting a deployment means credentials and endpoints, mapping infrastructures onto regions and zones, and curating the catalog. That is a scoping conversation in hours, not a migration in quarters.

Most teams have built half of this layer. The expensive half is missing

OpenStack alone is enough only once all four of these are already true.

A self-service experience your teams use without raising tickets. A tenancy model that reports usage per customer. Permissions fine enough to delegate safely. Automation that upgrades, scales and heals Kubernetes and databases on its own. Most operators have one or two. Building the rest is a platform team and a roadmap; maintaining it is permanent.

For everyone else the question is not whether that layer is needed, it is who builds it and who keeps it running. The self-service platform architecture guide puts an honest number on building it in-house.

The takeaway, in three layers

Your usersManaged services and a self-service experience
edgeContinuumOrganizations · IAM · Kubernetes · PostgreSQL · VMs · Apps · API · Terraform
Your existing OpenStackCompute · Networking · Storage · Identity

OpenStack remains your infrastructure foundation. edgeContinuum turns it into the cloud service your customers and teams consume.

Build on the OpenStack you already have

Connect a lab deployment on the free trial and give a team its own organization, quota and catalog in an afternoon.

Request a free trialBook a call

Frequently asked questions

Why do I need edgeContinuum if I already have OpenStack?
When the goal stops being "provide OpenStack resources" and becomes "provide a managed cloud platform". OpenStack keeps doing compute, networking, storage, identity and APIs exactly as it does now. What it does not ship is the layer above: organizations with their own users and groups, permissions per action, Kubernetes and PostgreSQL delivered as managed services with their lifecycle handled, an application catalog, and one console, API and Terraform provider across all of it.
Does edgeContinuum replace OpenStack?
No, and it cannot: it needs an OpenStack to run on. Not a fork, not a distribution, not a hypervisor. Nova, Neutron, Cinder and Keystone stay upstream and untouched, driven through their own APIs, and your operators keep Horizon and the OpenStack CLI for the work they already do there.
Do we have to rebuild or reinstall our cloud?
No. Connecting an existing deployment means credentials and endpoints, mapping your infrastructures onto regions and zones, and curating the catalog. Existing virtual machines, networks, firewalls and SSH keys can be imported as managed resources rather than recreated. Not zero work, but a scoping exercise rather than a migration.
How is this different from Horizon?
Horizon is an operator interface onto OpenStack primitives and it is good at that. It has no concept of an organization that owns projects and carries a quota envelope, no managed Kubernetes or database service, no application catalog, and no permission model spanning those services. The two coexist: operators keep Horizon, teams and clients work in the edgeContinuum console, API or Terraform.
What happens to Keystone and our existing roles?
Keystone stays where it is and keeps doing its job for your operators and infrastructure. edgeContinuum maintains its own users, groups, roles and permission catalog for the services it exposes, so the two are not required to mirror each other. The guide to users, projects, roles and quotas covers what Keystone models natively.
Do we still need our OpenStack team?
Yes. Somebody still operates the infrastructure: hardware, capacity, upgrades of the OpenStack services themselves, networking and storage. What changes is what that team spends its days on, because the requests that used to arrive as tickets become self-service inside guardrails the team defines once.

Keep exploring

OpenStack management platformIdentity and accessManaged KubernetesManaged PostgreSQLFor service providers