Which to choose: OpenStack or OpenNebula for your private cloud
Choose OpenStack when you need several separate cloud services behind one set of APIs, have a platform team that can run them, and can absorb a release every six months. Choose OpenNebula when you want one management front-end on KVM, a smaller operating footprint, and a single vendor-backed path to enterprise features, and you accept a narrower service catalog. Both projects publish Apache-2.0 licensed core code, so license alone will not separate them. The decision turns on operating capacity, service scope and who carries support. Start with team size and skills. OpenStack is a set of projects that each expose their own services, such as Nova for compute, Cinder for block storage, Swift or Ceph-backed object storage, and Keystone for identity, so you need people who can run several components and their dependencies. OpenNebula centers on a single front-end that persists state in an SQL database and manages hypervisor hosts. OpenNebula's comparison material claims that its architecture is simpler to deploy, operate and troubleshoot with small teams, but that is the vendor's own claim. Ask for a reference architecture and run a proof of concept in your own environment before accepting it.
Next, test the upgrade model. OpenStack ships a release every six months, and only SLURP releases allow skip-level upgrades. The 2026.1 Gazpacho release is a SLURP release, and 2027.1 Indri is also planned as one, so a team that plans around SLURP cycles has a clearer rhythm. OpenNebula's subscription material says some enterprise maintenance and long-term support releases are available only to subscribers, so confirm which release lines, support windows and upgrade tooling your subscription includes. Also decide who supports you: OpenNebula sells Standard and Premium support plans, while OpenStack support comes from distributions and service providers. DeployOpen plans, implements, upgrades and supports self-hosted platforms in your infrastructure, and it does not act as a vendor or certified provider for either project. Confirm Kubernetes, edge and multi-zone needs with each vendor before you commit.
Which platform fits which scenario
This table maps common team situations to the platform that fits better and the condition under which the other platform would still be reasonable. Read each row against your own host count, staffing and upgrade tolerance, since the same requirement can point in different directions depending on those factors.
| Scenario | Better fit | Why and when the other platform still works |
|---|---|---|
| A small platform team replacing VMware with a few hosts | OpenNebula | Its single front-end on KVM with Sunstone is simpler to deploy and troubleshoot, which matters most when a few people run everything. OpenStack remains reasonable if the team already has OpenStack skills or expects to grow into multi-tenant APIs. |
| A large organization needing multi-tenant APIs for many internal services | OpenStack | Keystone provides common authentication across modular compute, storage and networking services, which suits many internal consumers calling APIs directly. OpenNebula also offers multi-tenancy, so it stays reasonable if the API surface needed is narrower. |
| A sovereign cloud requiring a long list of named open-source components | OpenStack | Its modular project model and Apache-2.0 requirement for official projects make it easier to map each named component to a project. Confirm each required component with the project directly, since OpenNebula may cover a shorter list with fewer moving parts. |
| An organization already running Ceph or wanting Ceph as shared storage | OpenStack | Ceph block devices can back Glance images, Cinder volumes and Nova guest disks, so VMs can boot from Ceph. OpenNebula can also use Ceph storage, so confirm the storage driver and support path for your version before deciding. |
| A team needing an edge or multi-zone footprint | OpenNebula | The product comparison page lists multi-zone federation and native edge provisioning, which fits distributed sites managed from one instance. Treat these as vendor claims and confirm them against your topology, since OpenStack edge designs also exist but require more integration work. |
| A team that wants Kubernetes clusters offered as a service | OpenNebula | OneKS provides Kubernetes as a service through CAPONE, a Cluster API provider, which can be simpler than assembling a Kubernetes service on OpenStack. OpenStack suits this too if the organization already runs its own Kubernetes service layer or plans to separate container and VM platforms. |
| A team with no spare platform engineers | OpenNebula | Its architecture is described by the vendor as easier to operate with small teams, and enterprise support tiers are published. Without spare engineers, factor in the subscription cost and ask DeployOpen or the vendor for a written support scope, since a fixed-scope implementation partner can cover initial build work. |
How each platform is built and what that means for operations
OpenStack and OpenNebula both pool compute, storage and networking, but they split the work differently. The cards below compare how many components you run, where a failure can spread and where operators spend their hours, so you can test each claim against your own team and hardware.
Modular services behind common APIs
OpenStack is built as a set of projects that expose their own APIs under common authentication, so compute, block storage, images and networking are separate services you deploy and tune. Each one adds moving parts, but it also lets you replace or scale one service without touching the rest. Check which projects your workloads need on day one, because every extra project adds configuration, monitoring and upgrade work for your operators.
Official deployment projects for OpenStack
Kolla-Ansible deploys OpenStack services in Docker containers driven by Ansible, while OpenStack-Ansible deploys them in LXC containers or directly on bare metal. The choice sets how you patch, roll back and troubleshoot each service, and it decides the skills your team needs. Ask which deployment project matches your existing container and configuration management practices before you commit to a design.
One front-end and an SQL database
An OpenNebula front-end orchestrates cloud resources and stores its state in an SQL database, which makes the front-end the control point for the whole cloud. Losing the front-end or its database affects management of every host, so high availability for the front-end and a tested database backup are central to your design. Confirm how the front-end is protected and restored in your environment, and time a restore during the pilot.
Workload clusters and KVM hosts
OpenNebula keeps hypervisor nodes and storage in workload clusters, with KVM as the principal virtualization layer and LXC supported alongside it. Most day-to-day failure risk sits on the hosts and their storage rather than in the control plane, so host patching and storage design drive much of the operating work. Check how your existing hardware, drivers and storage backends map onto this model before you assume the smaller component count reduces effort.
Sunstone, CLI and API access
OpenNebula gives operators a Sunstone web UI, a Unix-style CLI, the core XML-RPC API, and a RESTful OneFlow API for multi-VM services. Your team can script most tasks against the same interfaces it uses for the UI, which reduces manual work. Confirm that the API bindings and automation tools you plan to use cover your provisioning and reporting needs, and check how well each interface fits your existing change control.
Vendor claims about simpler operations
OpenNebula's comparison material says OpenStack distributions require extensive integration and operations work, while OpenNebula is simpler to deploy, operate and troubleshoot for small teams. These are the vendor's own claims, not independent measurements. Run a pilot that performs your real tasks, including a host failure, a front-end restore and an upgrade, and record the hours and incidents so you can compare the two platforms on evidence from your own environment.
Side-by-side: capabilities, licensing and release model
This table compares how OpenStack and OpenNebula are licensed, governed, released and integrated, so you can separate platform differences from claims made in vendor material. Read the rows on release model, identity and Kubernetes first, because they drive most of the long-term upkeep effort. Where a supplied fact is missing, the cell tells you what to confirm before you shortlist either platform.
| Capability | OpenStack | OpenNebula |
|---|---|---|
| Core license | Apache-2.0. Official OpenStack projects must use Apache-2.0 under the OpenStack licensing requirements. | Main source code under Apache 2.0. Certain enterprise-grade releases are available only to subscribers. |
| Governance and hosting | Hosted by the OpenInfra Foundation, which operates as part of the Linux Foundation. | Developed and promoted by the OpenNebula company. Confirm the project's governance model directly with the vendor. |
| Release model | Six-monthly releases. 2026.2 Hibiscus was released September 30, 2026. SLURP releases allow skip-level upgrades. | Tagged releases include 7.0.0 (July 1, 2025), 7.2.0 (April 3, 2026) and 7.4.0 (July 26, 2026). Confirm the upgrade path between major versions. |
| API surface | Multi-service APIs for compute, storage and networking, with common authentication across services. | Core XML-RPC API, Cloud API bindings for Ruby, Java, Go and Python, and the RESTful OneFlow API for multi-VM services. |
| Web UI | Confirm the dashboard edition and its feature coverage for your release with the OpenStack project documentation. | Sunstone web UI, plus a Unix-style CLI. |
| Identity federation | Keystone supports SAML 2.0 and OpenID Connect, Keystone-to-Keystone federation and mapping rules to groups, roles and projects. | Not covered by the supplied facts. Confirm supported identity protocols and mapping options with the vendor. |
| Multi-tenancy and multi-zone | Multi-tenant by design through projects and the shared API layer. Confirm zone and region layout for your footprint. | Multi-tenancy and multi-zone federation are listed on the vendor's comparison page. Validate them in a proof of concept. |
| High availability | Confirm control plane and compute node redundancy with your chosen deployment project. | High availability for front-end and host nodes, per the vendor's comparison page. |
| Kubernetes | Kubernetes is not bundled. See the sibling OpenStack vs Kubernetes comparison for how the two run together. | OneKS provides Kubernetes as a service, provisioned through CAPONE, a Cluster API provider for OpenNebula. |
What is free and what is paid in each platform
OpenStack's official projects must be licensed under the Apache License, Version 2.0, and the OpenInfra Foundation, which hosts OpenStack, operates as part of the Linux Foundation. The supplied facts do not list a paid OpenStack edition or a vendor subscription that unlocks features, so there is no license fee to budget for the upstream code. The costs that remain come from three places: a distribution or deployment toolchain you choose, a commercial support contract with a vendor, or the internal staff who build, upgrade and operate the cloud.
- No license fee for official projects: The Apache-2.0 requirement applies to official projects, so you can run the upstream code without a per-host or per-core charge from the project.
- Hosting by a neutral foundation: The OpenInfra Foundation hosts the project within the Linux Foundation, which governs the project but does not sell a license.
- Staff time as the main recurring cost: Your engineers plan, patch and upgrade services on a six-month release train, and that labor recurs for the life of the cloud.
- Support is a separate purchase: Any commercial support, distribution subscription or managed service is priced by the vendor, so ask each one for a written scope and price.
- Distribution choice shapes the bill: Deployment tooling such as Kolla-Ansible or OpenStack-Ansible is free to use, but the team that runs it is not.
Before you budget, confirm with each vendor whether a commercial support offering, distribution or managed service exists, what it covers, and which OpenStack release it supports.
OpenNebula's main source code is licensed under Apache 2.0, but the vendor's subscriptions page says certain enterprise-grade releases are available only to subscribers. Those releases include regular maintenance releases and long-term support versions, so the free core and the supported product are not the same thing. The subscription is priced per hypervisor host, and the subscriptions page publishes no prices and asks buyers to request a proposal.
- Per-host pricing with no core, VM or memory limits: The product comparison page states the enterprise subscription is priced per hypervisor host, with no limits on cores, VMs or memory, so a host count drives the quote.
- Subscription-only releases: Maintenance releases, long-term support versions, security patches, enterprise drivers and automated upgrade tools are reserved for subscribers.
- Perpetual license and drivers: Subscribers receive a perpetual license usable after the subscription ends, plus enterprise drivers for Veeam backup and NetApp and Pure Storage integrations.
- Two support tiers: Standard offers 9x5 coverage with 2 named accounts, and Premium offers 24x7 coverage with 4 named accounts, both with unlimited tickets, CPUs, cores and VMs.
- Quote inputs: Ask for the host count, the tier, the named-account count and whether the drivers you need are included.
Before you depend on a long-term support version, confirm which OpenNebula releases your support tier covers and how long each one is supported.
What drives the running cost of each platform
Running cost is set less by the license line than by the hardware under it, the people who operate it and how often the platform forces upgrades. OpenStack and OpenNebula spread these costs differently, so the cards below name the decision behind each driver and what to request before comparing quotes.
Hardware and storage back end
Both platforms need hypervisor hosts and shared or distributed storage, but the storage choice changes the bill. OpenStack can use Ceph to back Glance images, Cinder volumes and Nova guest disks, which lets VMs boot from Ceph without local hypervisor storage. Ceph is a separate design decision with its own hosts, network and failure domains, so budget it as a second cluster. Ask each vendor and integrator which storage backends are in scope and how many nodes the proposed design needs.
Platform staff and operating effort
Staff time is usually the largest recurring cost. OpenStack is a set of modular services with its own identity, networking and storage projects, and each six-month release needs testing and rollout. OpenNebula runs a single front-end that persists state in an SQL database, which typically means fewer components to patch and troubleshoot. Estimate the people who will own each platform, including on-call coverage, and check whether your team already runs Ansible, Kubernetes or Ceph.
OpenNebula subscription fees
OpenNebula's core code is Apache 2.0, but the enterprise subscription is priced per hypervisor host with no limits on cores, VMs or memory, so the fee grows with host count. Subscriptions are recurring, while the perpetual license for software you already received stays usable after the subscription ends. OpenNebula publishes no prices and asks buyers to request a proposal. Ask for the per-host fee, the host count assumed, growth terms and whether the quote covers maintenance releases and enterprise drivers.
Support tier and coverage hours
OpenNebula support plans differ mainly in coverage and named contacts. The Standard plan offers 9x5 coverage with 2 named accounts, and the Premium plan offers 24x7 coverage with 4 named accounts, both with unlimited tickets, CPUs, cores and VMs. Production outages outside business hours change which tier is worth paying for. OpenStack has no single vendor support contract because distributions and commercial support come from several providers. Compare response targets in writing, not marketing summaries.
Upgrade cycles and maintained releases
OpenStack ships a release every six months, and stable branches are maintained for about 18 months, after which only SLURP releases may enter an unmaintained phase. Upgrades between SLURP releases are supported, which lowers how often you must move. OpenNebula's maintenance releases and long-term support versions are available only to subscribers, so the upgrade path you need may depend on your subscription status. Model how many upgrades your team will run over five years and who pays for each one.
External help and integration work
Fixed-scope implementation, integration, hardening and upgrade work is a one-time cost, while retainers for support, upgrades and testing recur. OpenStack deployments usually need more integration work (identity federation through Keystone, storage, networking and deployment tooling such as Kolla-Ansible or OpenStack-Ansible), which raises the one-time cost. Ask for a written scope with deliverables and timelines, and separate the implementation fee from any ongoing retainer and any subscription fee the vendor charges.
Moving between OpenStack and OpenNebula later
This sequence turns a move between the two platforms into a staged, checkable project, so each workload has a named target, a verified copy and a tested way back before any source environment is retired.
Inventory workloads, networks and storage
Your platform team lists every virtual machine, container host, network segment, security group, load balancer, storage pool and backup job, with its owner, data classification and dependencies. Include the automation that builds and changes these objects, such as playbooks, Terraform or Ansible roles, and any hand-built exceptions. Done means a single inventory that both platforms can be checked against, reviewed by the application owners who will sign off each cutover. Ask the vendor or your integrator to confirm which inventory fields their migration tooling can read, since the OpenNebula OpenStack alternative page does not describe a migration path from OpenStack, so the tooling choice is yours to verify.
Decide which platform hosts which workloads
Sort the inventory into three groups: workloads that stay where they are, workloads that move, and workloads that will be retired. Score each candidate on the features it needs, such as multi-tenant project APIs, Kubernetes service options, edge placement or Ceph-backed block storage, and on the team that will operate it. Record the decision in a signed table so that no workload lands on a platform by default. Done means every workload has one target, one owner and one reason for that target.
Rebuild identity federation and tenant structure
Recreate your identity provider trust in the target, then map each existing group, role and tenant to the target's model. In OpenStack this means Keystone federation over SAML 2.0 or OpenID Connect with mapping rules that place federated users into groups, roles and projects. In OpenNebula, confirm how users, groups and multi-tenant access are modeled in the version you run and how SSO is integrated. Done means a test user from each group can sign in to the target and sees only the tenant they should, with access denied for all other tenants.
Move images, volumes and configuration as code
Copy base images, data volumes and backups into the target, verify checksums and boot a test instance from each image. Configuration as code, including templates, playbooks and infrastructure definitions, is rewritten for the target's API and tooling rather than copied unchanged, because the two platforms expose different interfaces. If your storage is Ceph, confirm that the target can attach the same Ceph pool, since Ceph block devices can back OpenStack Glance images, Cinder volumes and Nova guest disks. Done means each migrated volume restores to a known-good state and each template produces an identical test build.
Rebuild monitoring, backup and automation
Recreate alerting, dashboards, backup schedules and deployment pipelines on the target before application traffic moves. Each check that existed on the source should exist on the target, with the same thresholds and the same escalation path. Test a restore from the target's backup product and confirm that the backup agents or plugins you rely on are supported for that platform. Done means a deliberate failure in a test workload triggers the same alert and recovery steps as on the source platform.
Cut over in waves with a rollback plan
Move workloads in small, named waves, starting with low-impact services. For each wave, freeze changes on the source, synchronize data, switch DNS or load balancer targets, and run the acceptance tests agreed with the application owner. Keep the source copy powered and reachable until the wave passes its acceptance window, and write the rollback steps before the switch. Done means each wave has a signed acceptance record and a tested rollback that returned the workload to the source at least once in rehearsal.
Decommission the source environment
Once every wave is accepted and the retention period for source backups has passed, remove workloads, revoke credentials and deregister service accounts on the source platform. Securely erase or destroy storage that held regulated data, and keep the final inventory, evidence of each cutover and the decommissioning record for your audit trail. Done means the source environment holds no production data, no active credentials and no monitored services, and the records are filed with the people who own the compliance evidence.
Where implementation projects run long for each platform
Implementation time on OpenStack is driven mainly by how many services you must choose, configure and test before anything runs for tenants. OpenStack is a modular set of projects, so a private cloud typically means deciding which compute, block, image, network and identity services to deploy and how each one connects to your hardware and existing directory. The first decision is the deployment project: Kolla-Ansible deploys OpenStack in Docker containers with Ansible, OpenStack-Ansible deploys in LXC containers or on bare metal, and OpenStack-Helm runs the services as charts on Kubernetes. Each one assumes different skills, so confirm which your team can operate before scoping. Identity is the next long item. Keystone federation supports SAML 2.0 and OpenID Connect, and its mapping rules decide which federated users land in which groups, roles and projects. Writing and testing those rules against your identity provider's claims often takes more time than the initial install. Storage design follows, whether you use Ceph (where Ceph block devices can back Glance images, Cinder volumes and Nova guest disks) or another back end. Finally, plan upgrades from day one. OpenStack ships a release every six months, and stable branches are maintained for approximately 18 months, so your upgrade cadence must match a supported release. Confirm with the project's release site which releases are in the maintained phase when you start.
OpenNebula has a smaller set of components to stand up: front-end nodes that persist state in an SQL database, hypervisor hosts running principally KVM (with LXC support), and storage back ends. Most of the early effort goes into front-end high availability, host and storage integration, and the enterprise driver setup. OpenNebula's subscriptions page says enterprise drivers such as Veeam backup and NetApp and Pure Storage integrations are available to subscribers, so if your backup or SAN platform is on that list, the driver configuration and testing belong in the scope. Procurement is a step many plans forget. OpenNebula's subscriptions page publishes no prices and asks buyers to request a proposal, and some enterprise-grade releases, including long-term support versions, are available only to subscribers. Obtain the subscription and confirm which release tracks it includes before the build starts, because that choice affects the upgrade path. OpenNebula's own material describes its architecture as simpler to deploy and operate with small teams. That is the vendor's claim, so verify it against your own skills and integration list. Ask for a written scope that names each front-end, host, storage and driver integration, along with your team's role in testing and cutover.
DeployOpen scopes this work in writing before it starts, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in advance. The scope should list the services or components in play, the deployment project or architecture, the identity federation rules, the storage design, the upgrade plan and any enterprise drivers or subscriptions. Effort depends on your environment, your team's skills and the integrations you need, not on the platform name alone. A small team with existing Kubernetes and Ansible experience will face a different workload than one starting from zero, and an environment with many identity sources or specialist storage will add testing. Because the reader's environment governs the result, ask for a written scope that states its assumptions about hardware, network, directory services, backup tooling and internal staffing, and confirm each one with your own team before accepting the quote.
What buyers ask before choosing OpenStack or OpenNebula
How much effort does each platform need from a team of a given size?
The effort depends less on the license than on how many services you run and how many people operate them. OpenStack is a modular set of projects, each with its own APIs, identity integration, networking and storage choices, so the operating load grows with the number of services you enable and the number of tenants you serve. OpenNebula uses one front-end that orchestrates hosts and persists state in an SQL database, so the number of moving parts is smaller. Ask each vendor to describe the components your design needs, then count the people who must own each one. Your own environment, including existing identity sources, network design and storage backends, will set the final load.
Can a small team run OpenStack in production?
A small team can run OpenStack only if it has a narrow scope and clear ownership of each service it enables. OpenNebula publishes its own claim that its architecture is easier to deploy, operate and troubleshoot with small teams, but that is the vendor's statement and should be tested against your own design. For OpenStack, the deciding factors are how many projects you run, whether you need multi-tenant APIs for internal consumers, and whether your team already runs Ansible or container-based deployments. Ask for a named list of owners for compute, networking, storage, identity and upgrades before you commit to either platform.
What upgrade work does each platform imply, including the SLURP path?
OpenStack ships a release every six months, and since the 2022 cadence change, upgrades are supported between SLURP releases as well as between adjacent releases. The 2026.1 Gazpacho release is a SLURP release, and 2027.1 Indri is estimated for March 24, 2027 and is also SLURP. Stable branches are maintained for approximately 18 months, after which only SLURP releases may enter an unmaintained phase, so planning around SLURP versions reduces the number of hops you must make. OpenNebula's own page claims conservative evolution and smooth upgrades, which you should verify against its release history and the upgrade procedure for your version. Ask both vendors for their supported upgrade paths in writing and the test environment they expect you to maintain.
Is an OpenNebula subscription required to get long-term support releases?
Yes, for some releases. OpenNebula states that the software is fully open source, but certain enterprise-grade releases, including maintenance releases and long-term support versions, are available only to subscribers. The subscription also provides security patches, enterprise drivers and automated upgrade tools. Confirm with OpenNebula which versions are open and which are subscriber-only before you choose a release train, because that decision determines whether your support path depends on a paid contract. Your legal and procurement teams should also review the perpetual license terms, which the subscription page says remain usable after the subscription ends.
How does the per-host subscription cost scale for OpenNebula?
OpenNebula prices its enterprise subscription per hypervisor host, with no limits on cores, VMs or memory, according to its product comparison page. Your cost therefore rises with the number of hosts, not with the number of virtual machines packed onto them. Support tier also matters: the Standard plan offers 9x5 coverage with 2 named accounts, and the Premium plan offers 24x7 coverage with 4 named accounts, both with unlimited tickets. OpenNebula publishes no prices and asks buyers to request a proposal, so request a quote that states the host count today, the expected growth, the support tier and whether it covers each zone you plan to federate. OpenStack has no vendor subscription in this comparison, so its cost is driven by the people and services you run.
Does either platform offer Kubernetes clusters as a service?
OpenNebula does. Its OneKS component provides Kubernetes as a service on top of OpenNebula, provisioning infrastructure through CAPONE, a Cluster API provider for OpenNebula. OpenStack's Kubernetes options sit at the boundary between the two projects, so you should check which deployment project and Kubernetes integration fit your design before you assume a managed service. Whether you run Kubernetes on the cloud or inside it changes the team you need, the upgrade cadence you follow, and the number of control planes you operate. Ask each vendor to show a working cluster lifecycle, including upgrades and node replacement, in your environment.
What does the work need from our side before we start?
Either platform needs named owners, a network design, a storage decision and a chosen identity source before deployment begins. Name one owner each for compute, networking, storage, identity and upgrades, and give them authority to decide. For networking, define tenant isolation, north-south routing and any multi-zone or edge sites. For storage, decide whether you use local disks, a shared backend or Ceph, since Ceph block devices can back OpenStack Glance images, Cinder volumes and Nova guest disks. For identity, list the sources to federate. OpenStack Keystone supports SAML 2.0 and OpenID Connect federation and maps federated users to groups, roles and projects, so your identity team must provide the attributes that drive those mappings.
Can we do this work ourselves, or do we need an implementation partner?
Your team can do the work alone if it already operates Linux, networking, storage and identity services, has capacity for a parallel test environment, and accepts ownership of upgrades after go-live. A partner makes sense when one of those is missing or when the timeline is short. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice is about which parts you want to hand over and which you keep. Ask for a written split of responsibilities so you know who owns each function after handover.
What does a DeployOpen fixed-scope engagement cover in writing?
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. The written scope should name the platform, the services in scope, the infrastructure where it runs, the documentation and backup work, the handover and the support or retainer that follows. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the deliverables list, acceptance criteria and the handover plan before you sign.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenStack vs OpenNebula, we start from your team size, upgrade capacity and identity requirements, then agree a written scope before any build work begins.
How we scope
- We confirm which workloads, hypervisors and tenants the private cloud must serve before choosing a platform.
- Scope covers identity federation, storage backend, Kubernetes options and edge sites, each with agreed deliverables.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform in your infrastructure, with the architecture and deployment method documented for your team.
- Integration work covers identity providers, storage, backup and any Kubernetes layer named in the written scope.
- Security testing of the management plane and APIs runs alongside the build, with findings tracked to closure.
How we hand over
- You receive architecture records, runbooks, configuration documentation and upgrade procedures written for your own operators.
- Handover includes a walkthrough of upgrade and rollback steps for the release cadence or subscription model you select.
- Compliance evidence is prepared for your assessor; DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should state which releases, maintenance windows and response expectations your team needs.
- Ask for a written quote built from the agreed scope, since DeployOpen does not publish a price list.
