OSIE alternatives: a service layer, not a nicer portal
edgeContinuum vs OSIE, in one line: OSIE makes OpenStack easier to consume and to commercialize, with a modern dashboard and a full billing system. edgeContinuum adds the layer above the infrastructure: managed Kubernetes, managed PostgreSQL, virtual machines and applications, operated for you rather than handed over.
Managed lifecycle above the infrastructurePermissions at the level of the individual actionChecked against their docs, not their marketing
Where each one adds its value
OSIE
Dashboard, identity, billing
OpenStack resources, metered per minute
Your OpenStack
Your infrastructure
edgeContinuum
Managed Kubernetes, PostgreSQL, apps
VMs, networks, firewalls, routers
Your OpenStack
Your infrastructure
One deepens the commercial layer. One adds a service layer.
The short answer, if you want one now
A better dashboard over OpenStack still leaves your customers operating their own Kubernetes.
That is the gap edgeContinuum fills: clusters whose control planes upgrade on request, node pools that scale and autoscale, failed nodes remediated automatically, PostgreSQL with high availability and in-place upgrades, an application catalog, and permissions composed per action rather than per role name. Start a free trial or book a call.
Selling plain OpenStack resources today? You can sell exactly those here too, and add managed services to the same customers when you are ready. OSIE is deeper on billing and on identity federation, and the section below says where.
The layer after provisioning
A portal's job ends at handover. Ours starts there
Kubernetes with real day-2. Cluster API with the OpenStack provider, dedicated or hosted control planes, control plane upgrades, node pools that scale and autoscale, and failed nodes remediated by health checks. OSIE supports creating Magnum clusters and meters them; lifecycle beyond creation is not something their documentation describes.
PostgreSQL under an operator. High availability, in-place version upgrades, storage growth and metrics, provisioned inside the same quotas and roles as everything else.
An application catalog. Helm and container applications, versioned, private to a project or published platform-wide for your tenants.
Permissions per action, not per role name. Roles composed from more than two hundred individual permissions and granted to a user or a group at organization or project scope, so an operations team can power-cycle a machine and scale a node pool while delete and credential access stay out of reach. See identity and access.
Managed lifecycleAction-level rolesUsage export
What you needPoints to
Managed Kubernetes with real day-2edgeContinuum
Managed PostgreSQL, not a VM with a databaseedgeContinuum
An application catalog for tenantsedgeContinuum
Permissions at the level of the actionedgeContinuum
Invoices, tax rules, payment collectionOSIE
SSO with your corporate directoryOSIE
Sovereign or air-gapped, EU-builtedgeContinuum
Selling raw OpenStack today and want more per customeredgeContinuum
The real difference: exposure versus lifecycle
OSIE's coverage of OpenStack is broad and precise: instances, volumes, bare metal through Ironic, object storage, shared filesystems, load balancers, VPN services, Heat, DNS and secrets, each exposed to the customer and metered per minute from creation to deletion.
edgeContinuum covers less of OpenStack on purpose and more of what sits above it. There is no object storage resource, no standalone volumes and no floating IP management. What there is instead is a smaller set of things the platform takes responsibility for keeping in the state you asked for. That is the trade, stated plainly: a portal exposes more of OpenStack than we do, and a service layer owns more of what happens after provisioning than a portal does.
Identity: they federate who gets in. We control what they can do
edgeContinuum composes a role out of individual permissions, one per action the platform exposes, then grants it to a user or a group at organization or project scope. That is what lets an operations team power-cycle a machine and scale a node pool while delete, resize and credential access stay out of reach, across every managed service rather than only the infrastructure.
What OSIE documents is a nested model: a project inside an organization inside a realm, each scope narrowing the one above, with platform, organization and project role sets, organization groups that turn an identity provider claim into access on specific projects, per-realm identity providers, and OpenID Connect through Keycloak, Entra ID, Okta or Auth0. That is a serious identity implementation, and federation is something they have today and we do not.
Their model is strong along a different axis, and it would be misleading to call it coarse: it decides who reaches which projects and federates that with your corporate directory, which is real work done well. The two models answer different questions, and the one that matters for delegating day-to-day operations is which actions a person can take.
OSIE, per their documentation
Scopes: realm, organization, project
Fixed role sets at each scope
Groups driven by identity provider claims
OpenID Connect and Keystone federation
edgeContinuum
Scopes: organization, project
Roles composed per individual action
Groups managed in the platform
No SAML or OIDC federation today
The questions people actually ask, one at a time
Open a row for the detail. Their documentation is detailed, so most of this is verifiable either way.
What can customers order?
edgeContinuumManaged servicesKubernetes, PostgreSQL, apps, plus plain VMs
OSIE covers more of OpenStack than we do: instances and volumes, bare metal through Ironic, object storage, Manila shared filesystems, load balancers, VPN services, Heat, DNS and Barbican secrets, each metered per minute from creation to deletion. edgeContinuum exposes a narrower infrastructure set on purpose and adds managed Kubernetes, managed PostgreSQL and an application catalog above it.
OSIE vs edgeContinuum: who runs it after provisioning
OSIEThe customer doesProvisioned, metered, handed over
More detail
A portal, however good, finishes its job when the resource exists. OSIE supports creating OpenStack Magnum clusters and meters them as a billable resource; lifecycle beyond creation is not something their documentation describes. edgeContinuum provisions through Cluster API with the OpenStack provider and owns the day-2 work: control plane upgrades, node pool scaling and autoscaling, and remediation of failed nodes through health checks.
How fine can permissions get?
edgeContinuumPer individual actionRoles you compose from individual permissions
OSIENested scopes and role setsRealm, organization, project, plus OIDC
More detail
Both are serious, along different axes, and it would be misleading to call theirs coarse. OSIE documents a project inside an organization inside a realm, with role sets at each level, organization groups that map an identity provider claim onto project access, per-realm identity providers, and OpenID Connect with Keycloak, Entra ID, Okta or Auth0. edgeContinuum composes roles from individual permissions, one per action, granted to a user or a group at organization or project scope. Their model decides who reaches which projects and federates it with your directory; ours decides which actions someone can take across the managed services.
What about databases?
edgeContinuumManaged PostgreSQLOperator-run, HA, in-place version upgrades
OSIEDatabase as a serviceBacked by Severalnines
More detail
Both offer managed databases, through different engines and different partners. OSIE added database as a service backed by Severalnines in recent releases, billed through their own resource types. edgeContinuum runs PostgreSQL under a Kubernetes operator with high availability, in-place version upgrades, storage growth and per-instance metrics, and PostgreSQL is the only managed data service today.
How does the money work?
edgeContinuumPer managed resourceUsage metered per tenant, exported to your billing
OSIEPriced on provisioned VM RAMFull billing built into the portal
More detail
OSIE is the deeper commercial product by design: per-minute metering, price plans with flat, tiered, savings and commitment rules, wallets with auto top-up, postpaid credit limits, branded invoices, tax rules, payment gateways and a reseller model on OpenStack domains. Their free edition runs to 256 GB of provisioned VM RAM with no feature restrictions. edgeContinuum meters usage and quota per organization, project and managed resource and exports it as JSON or CSV into the billing you run, priced per resource the platform manages.
Sources: OSIE documentation at v26.5 plus their features and pricing pages, checked September 2026.
Same infrastructure. More to sell on it
Where OSIE is focused
Deep commercial tooling inside the portal: per-minute metering, price plans, wallets, tax rules and payment gateways.
Corporate identity federation. OpenID Connect with your directory is available on their side today.
Reselling the full OpenStack surface, including bare metal, object storage, shared filesystems and VPN services.
What you can sell here
The virtual machines, networks, routers and firewalls your customers buy today, self-service.
Plus managed Kubernetes and managed PostgreSQL, so customers consume them without operating them.
Plus an application catalog your own teams publish into, private to a project or shared platform-wide.
Delegation per individual action, so teams operate without being able to destroy.
Which makes the choice simpler than it looks. If all you want is to sell OpenStack resources well, both products do that. Only one of them also turns the same infrastructure into managed Kubernetes, managed databases and applications sold to the same customers, which is where revenue per customer actually grows.
And because these are different layers, running both is coherent: OSIE for the commercial and identity layer, edgeContinuum for the managed services, with usage exported into their billing. The thing to think about is two portals, not two products.
Compare it against what you actually sell
Bring your product line and your OpenStack, and we will map which parts are lifecycle problems and what you could be selling on the same infrastructure within a quarter.
For an OpenStack billing system and customer dashboard, the comparable products are Fleio, HostBill and WHMCS with an OpenStack module, or building on Horizon with your own metering. If the reason you are shopping is that a better dashboard over OpenStack still leaves customers operating their own Kubernetes and databases, the alternative is a managed services platform rather than another portal, and that is where edgeContinuum sits.
Is edgeContinuum an OSIE alternative?
For the self-service portal and tenancy, yes. The commercial layer works differently: OSIE meters per minute and invoices from the portal, while edgeContinuum meters per tenant and exports the figures into the billing system you run. On identity federation OSIE supports OpenID Connect with major providers today. Where we go further is the layer above the infrastructure: managed Kubernetes lifecycle, managed PostgreSQL, an application catalog and action-level permissions across them.
Does OSIE have granular access control?
Along a different axis to ours, and it would be misleading to call it coarse. Their documentation describes realm, organization and project scopes with role sets at each, plus groups that map identity provider claims onto project access. That decides who reaches which projects. edgeContinuum composes roles from individual permissions, so you can grant one action and withhold another across every managed service, which is what delegating day-to-day operations actually needs.
Which should a service provider choose?
Ask what you are selling. If the product is OpenStack resources and the hard part is metering, pricing and getting paid, OSIE is built around exactly that problem. If the product is managed services that customers use without operating, that work is what edgeContinuum automates. If both are true, run both, with usage exported from the platform into their billing.
How does billing work with edgeContinuum?
Metering is detailed: per organization, project and managed resource, with JSON and CSV export. It is designed as an input to the BSS a provider already runs, so there is no second source of truth for revenue to reconcile. Bring the billing system you use to a call and we will walk through the export and how per-tenant figures land in it.
Do you support SSO with our identity provider?
Not today. Authentication is email and password with optional two-factor, and users join an organization by invitation. Access inside the platform is then governed by roles you compose and grant to users or groups at organization or project scope. If federating with Entra ID, Okta or Keycloak is a hard requirement for your deployment, raise it on the call before anything else and we will talk about how it fits your timeline.
What about Kubernetes on both sides?
OSIE supports creating OpenStack Magnum clusters and meters them as a billable resource; managed lifecycle beyond creation is not something their documentation describes. edgeContinuum does not use Magnum. Clusters are provisioned through Cluster API with the OpenStack provider, with dedicated or hosted control planes, and day-2 is the product: control plane upgrades, node pool scaling and autoscaling, and remediation of failed nodes. The architecture guide explains the provisioning routes.
Where did these facts come from?
OSIE's own documentation at v26.5 plus their features and pricing pages, read in September 2026. We deliberately used their documentation rather than their marketing pages for the identity model, because the two describe different things and the documentation is the accurate one. Where their documentation was silent we wrote that, rather than treating silence as absence.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Preferences
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
