Which OpenStack deployment project fits your team
Picture a platform team that has been asked to replace a VMware estate with a private cloud. Its members know Ansible well, run little or no Kubernetes today, and need the cloud in production within a fixed scope. For that team, Kolla-Ansible is the most direct starting point. It builds OpenStack service containers with Kolla and deploys them on hosts with Ansible, and its quick start ships all-in-one and multinode inventory examples so the team can test the layout before committing hardware. The condition that matters is simple: the team must be comfortable operating Docker-based services on hosts, and it must accept the project's opinionated defaults in exchange for a faster first deployment. Kolla-Ansible still allows complete customization, so the question is how much of the default layout the team wants to change. Choose OpenStack-Ansible when placement per service is a real design input. Its production example uses three infrastructure hosts, and deployers can decide, service by service, whether a component runs in a container (the default) or on the host (on metal). That choice matters most when a storage back end forces the issue: the production example notes that with LVM or iSCSI-based Cinder backends, cinder-volume must run on metal. Teams that already plan Ceph for Cinder, Glance and Nova disks may find that constraint less important. Confirm the exact per-service layout against the current OpenStack-Ansible documentation before you draft the host plan, because it determines which hosts need which kernel and storage access. Choose OpenStack-Helm only when the team already runs Kubernetes and Helm as its operating platform and intends to treat OpenStack as one more workload. Its tested combinations include OpenStack 2025.2 Flamingo and 2026.1 Gazpacho on Ubuntu Noble with Kubernetes 1.33 to 1.35, so check that your cluster version sits inside a tested range before any design work. This path is not cheaper in skill terms. OpenStack-Helm depends on Kubernetes operating skill for control plane health, etcd backups, certificate rotation, persistent storage and network policy, and a team without that depth will spend its effort learning the platform underneath OpenStack. Ask your team to name the person who would own a failed etcd member at 2 a.m. before choosing it.
How the three projects compare on runtime, hosts and skills
This table sets the three official OpenStack deployment projects side by side on how they run services, the host layout the supplied facts describe, tested versions and the skills your team needs. Read each row as a question to put to the project and to your own staff before choosing, since the right answer often depends on whether you already run Kubernetes or Ansible at scale.
| Factor | Kolla-Ansible | OpenStack-Ansible | OpenStack-Helm |
|---|---|---|---|
| How services run | Services run in Docker containers deployed by Ansible, using images built by the Kolla project | Services run in LXC containers by default, or on bare metal where a deployer chooses per service | Services run as pods on Kubernetes, deployed from Helm charts |
| Minimum host layout (from supplied facts) | Quick start lists 2 network interfaces, 8 GB main memory and 40 GB disk per host, with all-in-one and multinode inventories | Production example uses three infrastructure (control plane) hosts, with the cinder-volume service on metal for LVM or iSCSI backends | Requires a Kubernetes cluster underneath; the control plane sizing for kubeadm high availability calls for at least three control plane nodes with a TCP load balancer on port 6443 |
| Fit for Cinder LVM or iSCSI backends | Confirm the cinder-volume placement and host access for LVM or iSCSI with the project's current guidance before you commit | Supplied facts state cinder-volume must run on metal with LVM or iSCSI backends, so plan those hosts outside containers | Confirm how LVM or iSCSI volumes reach pods on your Kubernetes nodes before relying on them; Ceph is the more common documented backend path |
| Tested versions (from supplied facts) | Confirm the tested OpenStack and host OS combinations in the Kolla Ansible documentation for your target release | Confirm the tested combinations in the OpenStack-Ansible documentation for your target release | Tested with OpenStack 2025.2 (Flamingo) and 2026.1 (Gazpacho) on Ubuntu Noble with Kubernetes 1.33 to 1.35 |
| Primary skills required | Ansible for inventory, configuration and upgrades, plus working knowledge of Docker container operations | Ansible roles and playbooks, plus Linux host administration and LXC for the containerized services | Kubernetes operations (networking, storage, RBAC), Helm chart configuration and etcd care for the cluster underneath |
| Licensing | Apache-2.0 as an official OpenStack project | Apache-2.0 as an official OpenStack project | Apache-2.0 as an official OpenStack project; Kubernetes itself is also Apache-2.0 |
| Who this suits | Teams that want OpenStack on containers managed with Ansible and no Kubernetes dependency | Teams that want Ansible-driven control over which services run in containers and which run on hosts | Teams already operating Kubernetes with the skills to run it as the substrate for OpenStack |
Which deployment model suits which team situation
This situation fits teams whose operators already write and run Ansible but have no Kubernetes platform to build on. Kolla-Ansible and OpenStack-Ansible both use Ansible as the deployment engine, so the existing playbook habits transfer directly. The difference is how services are packaged. Kolla-Ansible deploys OpenStack services from its own containers, and its quick start ships an all-in-one inventory that deploys single-node OpenStack on localhost, which is useful for a lab before a production multinode build. OpenStack-Ansible uses LXC containers by default and lets you move individual services onto bare metal. OpenStack-Helm would add a Kubernetes control plane you must also operate, so it usually rules itself out for this team.
- Kolla-Ansible as the default path: Its containers and opinionated defaults suit a team that wants one well-trodden route with room to customize.
- OpenStack-Ansible for per-service control: Its production example runs three infrastructure hosts and lets you choose container or metal placement for each service.
- OpenStack-Helm ruled out: Without a Kubernetes platform, you take on a second orchestration stack before the cloud exists.
- Minimum host sizing: The Kolla-Ansible quick start lists 2 network interfaces, 8 GB of main memory and 40 GB of disk per host as minimums, which are a floor and not a production sizing.
- Release timing: Plan upgrades against the OpenStack release calendar, since 2026.2 Hibiscus was released on September 30, 2026.
Confirm whether your operators can debug container runtime issues as well as Ansible failures, and whether your team will own the upgrade cycle for the chosen project.
This situation fits organizations that already run a supported Kubernetes platform, have Helm and GitOps practices in place, and want OpenStack services managed the same way as their other workloads. OpenStack-Helm deploys OpenStack and related services as Helm charts on Kubernetes, and its readme lists tested combinations with OpenStack 2025.2 (Flamingo) and 2026.1 (Gazpacho) on Ubuntu Noble with Kubernetes 1.33 to 1.35. The condition that rules it out is a team with no Kubernetes operations skill, because a failed control plane then becomes a cloud outage. Kolla-Ansible and OpenStack-Ansible remain viable here but do not reuse your cluster tooling.
- Tested version alignment: Check that your Kubernetes minor version appears in the tested combinations for your target OpenStack release.
- Control plane and etcd layout: The kubeadm guide describes stacked and external etcd topologies with at least three control plane nodes, and that layout becomes part of the OpenStack design.
- Storage and networking dependencies: Cinder, Neutron and Ceph integration all need decisions that the cluster team must support.
- Skew and upgrade sequencing: Kubernetes upgrades and OpenStack upgrades must be scheduled together, so the same people should own both.
- Secrets handling: Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest before placing cloud credentials in the cluster.
Confirm that your Kubernetes distribution is conformant, that your team can run etcd backups and restores, and that the cluster has capacity for the OpenStack control plane alongside existing workloads.
This situation fits teams whose storage design forces some services onto physical hosts. The OpenStack-Ansible production example notes that with LVM or iSCSI-based Cinder backends, the cinder-volume service must run on metal. OpenStack-Ansible is built for this mix because it lets you choose, service by service, whether a component runs in an LXC container (the default) or directly on the host. Kolla-Ansible deploys its services in Docker containers, so a bare metal cinder-volume requirement needs deliberate design. OpenStack-Helm runs services as pods, which makes a host-bound storage backend a poor fit unless the cluster design accounts for it.
- OpenStack-Ansible as the natural fit: Per-service placement is a stated feature, not a workaround.
- Ceph as an alternative backend: Ceph block devices can back Glance images, Cinder volumes and backups, and Nova guest disks, which may remove the host-bound Cinder requirement.
- Host inventory discipline: Metal services need fixed hosts with the right disks and network paths, so inventory and hardware records must be accurate.
- Upgrade effort on metal: Services on hosts are updated with the host, which adds coordination with hardware and OS lifecycles.
- Recovery planning: Losing a metal cinder-volume host affects volume access, so define the failover and restore procedure before go-live.
Confirm your Cinder backend type, whether your storage team can support Ceph as an alternative, and how each service will be placed before choosing the deployment project.
This situation fits organizations that must run the cloud inside their own networks with no reliance on external services during operation. All three projects can be installed inside a client's data center or air-gapped network, but the air-gapped build adds work to each one: container images or chart artifacts must be mirrored in, package and dependency sources must be available offline, and the upgrade path must be tested without internet access. Kolla-Ansible's container images make the image mirror a central task. OpenStack-Ansible's mix of containers and host packages widens the mirror scope. OpenStack-Helm depends on a Kubernetes distribution and charts, so the cluster bootstrap must also be offline.
- Image and artifact mirroring: Every container image, chart and package needed for install and upgrade must be staged inside the enclave.
- Identity federation: Keystone supports SAML 2.0 and OpenID Connect federation, and mapping rules connect federated users to groups, roles and projects.
- Licensing check: OpenStack projects must be Apache-2.0 licensed, which helps with procurement review.
- Release cadence: Plan around SLURP releases, since upgrades can skip between them, which reduces the number of offline upgrade cycles.
- Evidence collection: Record installed versions, configuration and change history, because DeployOpen prepares evidence for assessments without issuing certifications.
Confirm with your security and accreditation authorities which artifacts may cross into the enclave, who approves them, and whether your assessor requires a specific Kubernetes or OpenStack version.
What each project builds underneath the cloud
All three projects deploy the same OpenStack services, but they differ in what they put underneath them: Docker containers on hosts, a three-host control plane with per-service placement, or Helm charts on a Kubernetes cluster. Those choices decide what your team must operate before the first VM boots.
Kolla-Ansible containers and defaults
Kolla-Ansible builds and deploys OpenStack services as Docker containers driven by Ansible. The project describes its defaults as highly opinionated, so a deployment works out of the box, yet you can customize nearly every setting when your design differs. Check how much of your environment you expect to override, because heavy overrides move work from the project's defaults to your own configuration and testing. Confirm the container image and release you plan to use against the Kolla-Ansible documentation before you commit.
OpenStack-Ansible control plane layout
The OpenStack-Ansible production example uses three infrastructure hosts for the control plane. Each service can run in an LXC container, which is the default, or directly on the host (on metal), and you choose that placement per service. This flexibility suits teams that want fine control over where each process lands, but every placement decision adds a row to your runbook. Ask your implementation partner to document the container or metal choice for each service and the reason behind it.
OpenStack-Helm on Kubernetes
OpenStack-Helm deploys OpenStack as Helm charts, so you need a working Kubernetes cluster before any OpenStack service exists. The kubeadm guide describes a stacked control plane with etcd on the same nodes or an external etcd cluster, and it calls for at least three control plane nodes with a TCP load balancer on port 6443. etcd needs an odd member count, with five recommended for production, and a tested backup plan. Your team must operate that cluster as well as OpenStack, so confirm the Kubernetes version against the OpenStack-Helm tested combinations.
Cinder-volume placement constraint
The OpenStack-Ansible production example states that cinder-volume must run on metal when you use LVM or iSCSI-based Cinder backends. This constraint can shape host design and your choice of storage backend before you pick a deployment project. If you plan to use Ceph, Ceph block devices can back Glance images, Cinder volumes, backups and Nova guest disks, which changes where that service must run. Confirm the placement rule for your chosen backend with the project documentation before you size your hosts.
How a first deployment moves from lab to production
The sequence turns a lab-sized proof of concept into a production cloud by checking hosts against published minimums, choosing a deployment layout, pinning a tested release and closing the gaps in hardening and backup before any tenant workload arrives. Each stage ends with a written check that tells the team whether it can move on.
Validate hardware against the published minimums
The platform engineering lead checks every candidate host against the minimums in the Kolla-Ansible quick start: at least 2 network interfaces, 8 GB of main memory and 40 GB of disk space per host. For OpenStack-Ansible and OpenStack-Helm, the team also confirms the production layout it intends to use, including three control plane hosts for the OpenStack-Ansible production example and a Kubernetes cluster that meets the kubeadm high availability guidance. The step closes when a host inventory sheet lists each machine's interfaces, memory, disk and role, and every gap is either fixed or accepted in writing. Hardware that only meets the minimums for a lab should not be counted as production capacity.
Choose an all-in-one or multinode inventory
The deployment owner selects the inventory layout that matches the purpose of the environment. The Kolla-Ansible all-in-one inventory deploys single-node OpenStack on localhost and suits a lab or evaluation, while the multinode inventory is the starting point for a cluster. The team records which services run in containers and which, if any, run on metal, since OpenStack-Ansible lets deployers make that choice per service and requires cinder-volume on metal with LVM or iSCSI-based Cinder backends. The step closes with a written decision record naming the deployment tool, the inventory file and the services that depart from defaults, so later reviewers can see why the layout looks the way it does.
Pin a tested OpenStack release
The release owner selects an OpenStack release from the official releases site and confirms that the chosen deployment tool is tested against it. The 2026.1 Gazpacho release is a SLURP release, and SLURP releases allow skip-level upgrades, which matters for a team that expects to run the cloud for several years. The owner checks that the release is still in its maintained phase on the day of the decision and records the expected end-of-maintenance point from the stable branch policy. Where OpenStack-Helm is the candidate, the owner also checks the tested combinations in the OpenStack-Helm readme. The step closes when the release, the deployment tool version and the operating system are pinned in version control.
Match the Kubernetes version for OpenStack-Helm
If the team chose OpenStack-Helm, the platform engineer selects a Kubernetes version that appears in the tested combinations for the chosen OpenStack release. The OpenStack-Helm readme lists Kubernetes 1.33 to 1.35 alongside OpenStack 2025.2 and 2026.1 on Ubuntu Noble, so the cluster version must fall inside that range for the tested path. The engineer also checks the Kubernetes release status page, because the project maintains only the three most recent minor releases and an unsupported cluster version creates upgrade work before the cloud is even live. The step closes when the cluster version, the Helm chart set and the OpenStack release are recorded as one tested combination. Teams using Kolla-Ansible or OpenStack-Ansible can skip this step, but should note that their Kubernetes exposure is different.
Run a staging build and capture the baseline
The implementation team deploys the chosen layout into a staging environment that mirrors the production network, storage backend and identity source. They confirm that the control plane services start, that a test project can boot a virtual machine, and that the storage backend answers the way the design expects. For Kolla-Ansible and OpenStack-Ansible, this is the first run of the playbooks against real hosts. The team captures a configuration baseline, including the deployment tool version, the globals and inventory files and the service versions in use. The step closes when a repeatable deployment from the recorded files completes without manual edits to the running services, which shows the environment can be rebuilt if it is lost.
Harden the control plane and identity path
The security engineer reviews the staging build before any tenant workload is allowed on it. The review covers management network separation, access to the deployment host and its SSH keys, and how administrators authenticate to OpenStack. Keystone supports federation through SAML 2.0 and OpenID Connect, and mapping rules decide which federated users receive which groups, roles and projects, so the team tests those rules with real accounts. On the Kubernetes side for OpenStack-Helm, the engineer checks that Secrets are encrypted at rest in etcd, since they are stored unencrypted by default, and that RBAC follows least privilege. The team uses the CIS Kubernetes Benchmark and its own control list as reference points. The step closes with a signed-off findings list where every item is fixed, scheduled or accepted by a named owner.
Plan and test backups before production
The operations lead writes a backup plan that covers each stateful layer: the OpenStack databases, the image and volume storage, the deployment configuration and, for OpenStack-Helm, the etcd data that holds the Kubernetes state. For etcd, the Kubernetes documentation describes taking snapshots with etcdctl snapshot save and restoring with etcdutl, and the team runs both against staging. For Kolla-Ansible and OpenStack-Ansible, the team confirms how database dumps and configuration are captured and where they are stored. The step closes when a restore has been performed in staging and the team has recorded how long it took, which becomes the input for its recovery expectations. Production sign-off follows only after this test passes and the findings from the hardening review are closed.
Upgrades, backups and monitoring effort for each project
This table compares what each project asks of your team after the first deployment: upgrade mechanics, the platform layers you must back up, and what you monitor. Read each row as a question to answer for your own environment, since the work differs more by layer than by headline features. The main takeaway is that Kolla-Ansible and OpenStack-Ansible concentrate effort in Ansible runs and host state, while OpenStack-Helm adds a Kubernetes lifecycle and etcd duties on top of OpenStack's own cadence.
| Area | Kolla-Ansible | OpenStack-Ansible | OpenStack-Helm |
|---|---|---|---|
| OpenStack release cadence | Follows OpenStack's six-month releases; plan each move between releases or along a SLURP path such as 2026.1 Gazpacho to 2027.1 Indri. | Follows the same six-month cadence and SLURP skip-level upgrade option, with upgrades run through its playbooks. | Follows the same six-month cadence and SLURP option, and the tested combinations list must match your Kubernetes version. |
| Upgrade mechanism | Ansible run against the existing inventory and configuration; confirm the upgrade procedure for your target release in its notes. | Ansible run that updates services in containers or on metal; confirm the per-service upgrade order in its notes. | Helm chart upgrades per release, layered on Kubernetes rollouts; confirm chart value changes and migration jobs for each target. |
| Kubernetes lifecycle work | None beyond the hosts and containers Kolla manages. | None for the cloud layer; host OS and kernel patching remain yours. | Required: upgrade kube-apiserver one minor version at a time, then control plane components and kubelets, with kubelets up to three minor versions behind. |
| Kubernetes patch window | Not applicable to the platform itself. | Not applicable to the platform itself. | Kubernetes gives about one year of patch support per minor release, so schedule upgrades before your version drops out of support. |
| etcd backup duties | Not applicable; state lives in the database and host configuration you back up. | Not applicable; state lives in the database and host configuration you back up. | You must back up etcd with snapshot tooling and test restores, since Secrets sit unencrypted in etcd by default unless you configure encryption at rest. |
| What to back up beyond etcd | Configuration and inventory in version control, plus database and Ceph or LVM-backed volume data. | Configuration, inventory and the host layout including any cinder-volume services that must run on metal. | Helm values, chart versions, persistent volume data and the database backends OpenStack depends on. |
| Monitoring focus | Container health on hosts, API endpoints, database and message queue health. | Host, container and LXC service health, plus API endpoints and database health. | Kubernetes control plane and etcd health, pod restarts, plus OpenStack API endpoints and database health. |
| Skills the team needs | Ansible, Docker or container operations, Linux host administration and OpenStack operations. | Ansible, LXC or container operations, Linux host and storage administration and OpenStack operations. | Kubernetes administration, Helm, etcd operations, Linux and OpenStack operations. |
| Confirm before committing | Upgrade notes for your target release and the minimum host and network layout they assume. | Per-service upgrade ordering, which services you pin to metal, and how backups of host and storage state are expected to run. | Tested Kubernetes versions for your target OpenStack release, etcd backup procedure, and chart-level upgrade and rollback steps. |
What drives the cost of running each deployment model
The cost of each project is set less by its license than by who does the work. All three projects are Apache-2.0 OpenStack deployment tools, so no one pays a license fee for the software itself. Your costs come from internal platform engineers, hardware, any support contract you buy, and external implementation work. Kolla-Ansible and OpenStack-Ansible need engineers who are fluent in Ansible inventories, roles and group variables. OpenStack-Helm needs engineers who run Kubernetes control planes, etcd and Helm releases. If your team already runs Kubernetes well, OpenStack-Helm may carry less new learning cost. If it does not, that learning is a one-time cost you must budget for. Ask any implementation partner for a fixed-scope written proposal that names the deployment project, the number of hosts, the services in scope and the handover documents, so you can compare quotes on the same basis.
Expect the largest one-time costs in design, first deployment, hardening and documentation. Design covers the network layout, the storage backend and whether any service such as cinder-volume must run on metal. The OpenStack-Ansible production example notes that LVM or iSCSI-based Cinder backends require this, which changes host preparation. Hardening covers the Keystone federation design, including the mapping rules that place federated users into groups, roles and projects. Recurring costs are upgrades, patch cycles, backups and testing. Upgrades follow the OpenStack release cadence, so check how each project's tested versions line up with the releases you plan to follow, and confirm the stable-branch window for your chosen release on the OpenStack releases site. Backups must cover the control plane data and, for OpenStack-Helm, etcd snapshots taken with etcdctl snapshot save. Ask each quote to price these recurring tasks separately from the build.
Switching later is expensive because the deployment project shapes the host layout, the configuration tree and the operational runbooks. Moving from Kolla-Ansible to OpenStack-Helm, for example, changes the platform underneath the cloud, not just the tooling on top, so it is effectively a rebuild with a data migration. Before you commit, ask your team and any partner to write down the exit path: how configuration is stored, how a new control plane would be stood up beside the old one, and how instances and volumes would move. Require the handover package to include the inventory or chart values, the upgrade procedure and the backup restore test results. These documents reduce the cost of any future change, whichever project you choose.
Questions buyers ask before choosing a deployment project
Is Kolla-Ansible the simplest starting point for a private OpenStack cloud?
For many teams that already know Ansible and containers, Kolla-Ansible is a practical first choice. The Kolla project aims to provide production-ready containers and deployment tools, and its docs describe Kolla Ansible as highly opinionated out of the box while still allowing complete customization. The quick start lists minimums of 2 network interfaces, 8 GB of main memory and 40 GB of disk space per host, and it ships an all-in-one inventory that deploys single-node OpenStack on localhost. That all-in-one layout suits learning and testing only. The opinionated defaults reduce early decisions, but you still need skills in Ansible inventories, Docker and overrides once your network or storage design departs from the defaults. Confirm in a pilot that the defaults match your plan before you commit.
Does OpenStack-Helm require an existing Kubernetes team?
Yes, in practice you need people who can already operate Kubernetes. OpenStack-Helm provides Helm charts that deploy OpenStack and related services on Kubernetes, and its tested combinations include OpenStack 2025.2 (Flamingo) and 2026.1 (Gazpacho) on Ubuntu Noble with Kubernetes 1.33 to 1.35. Your team then owns the cluster as well as the cloud: upgrades that follow the Kubernetes version skew policy, etcd backups and Secrets handling. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest and least-privilege RBAC need an owner. The Kubernetes project maintains only its three most recent minor releases, which adds a cluster upgrade cadence on top of OpenStack's. If you lack Kubernetes operators, close that skill gap first or choose an Ansible-based project. Confirm the exact tested combination for your target release.
How many hosts does the OpenStack-Ansible production example use?
The production example uses three infrastructure (control plane) hosts. It lets you choose, service by service, whether each one runs in a container, the default, or directly on the host (on metal). The three-host layout describes the control plane, so you still need to size compute and storage nodes from your own workload. The Kolla-Ansible quick start gives per-host minimums of 2 network interfaces, 8 GB of main memory and 40 GB of disk, which apply to test hosts and should be treated as a starting floor. For OpenStack-Helm, the kubeadm high availability guide calls for at least three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443. The control plane count looks similar across these options, but the platform underneath differs. Ask your candidate partner for a host layout that matches your service list and failure tolerance.
What does cinder-volume on metal mean for LVM or iSCSI storage?
It means the cinder-volume service runs directly on a host, outside a container. The OpenStack-Ansible production example notes that with LVM or iSCSI-based Cinder backends, cinder-volume must run on metal. Your block storage choice therefore shapes host layout before you decide where other services run. An LVM backend keeps volumes on the local disks of the host running cinder-volume, so that host's disk layout and failure handling become part of the cloud design. An iSCSI backend ties the service to network paths to the array, which affects interface design and multipath configuration. If you plan to use Ceph RBD for Cinder volumes, Glance images and Nova guest disks, check the Ceph documentation and your release notes for how service placement applies. Test placement in a pilot, because moving the service later changes the deployment.
How much effort do OpenStack upgrades take across SLURP and non-SLURP releases?
Effort depends mainly on how often you upgrade, which release you start from and where you land. 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. Epoxy (2025.1), Gazpacho (2026.1) and Indri (2027.1) are SLURP releases, and Indri is estimated for March 24, 2027. Hibiscus (2026.2) was released on September 30, 2026. Stable branches are maintained for approximately 18 months, after which only SLURP releases may enter an unmaintained phase. Effort drivers include how much you customized the deployment, the upgrade path of your chosen tool and any Kubernetes upgrades under OpenStack-Helm. Ask any candidate partner for a written upgrade runbook for each release pair you plan to use.
Can our team run OpenStack alone, or do we need outside help?
A team can run OpenStack alone if it already has the skills for its chosen project and can staff on-call work and upgrades. The skills differ by project. Kolla-Ansible and OpenStack-Ansible demand Ansible, inventory management and host operations, while OpenStack-Helm adds Kubernetes operations on top. All three still require OpenStack service knowledge across identity, compute, block storage and networking. Plan for a named owner of each upgrade cycle, a test environment that matches production and a tested backup and restore process for control plane data. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing, and ongoing support and upgrades are available as retainers. Map your staff skills against the chosen project before you decide.
What drives the cost of running a private OpenStack cloud yourself?
The software has no license fee of its own, because official OpenStack projects must be licensed under Apache License 2.0, so the cost sits in people, hardware and time. One-time costs include design, a pilot, integration with identity and storage and the migration of workloads. Recurring costs include staff time for upgrades on each release cycle, patching, monitoring, backups and on-call. The main drivers are the number of hosts, the storage backend you choose, the Kubernetes skills needed for OpenStack-Helm, how often you upgrade and how much compliance evidence you must produce. When you request a quote from any partner, ask for an itemized scope, the roles and hours behind each deliverable, the hosts and backends covered, the upgrade runbooks included and the support hours after go-live. Compare those line items, not headline totals.
When an outside implementation partner makes sense
A fixed-scope engagement makes the most sense when the team lacks the in-house depth to run one of these three deployment paths for years. Kolla-Ansible needs operators comfortable with Ansible inventories, group_vars and Docker-based service containers. OpenStack-Ansible needs the same Ansible skill plus a decision about which services run in LXC containers and which run on metal, and the production example's rule that cinder-volume must run on metal with LVM or iSCSI backends is easy to miss. OpenStack-Helm assumes Kubernetes operators who can manage the cluster itself, including the etcd layout and secrets handling. If none of those skills sit in the team, a written scope with named deliverables is safer than hiring for a single build and hoping the knowledge stays.
Compliance evidence and air-gapped networks are the other common triggers. Where an assessor will ask for configuration baselines, change records and backup restore tests, the deployment work has to produce those artifacts from day one. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, including air-gapped networks, and can prepare controls and evidence for an assessment. It does not issue audit reports, attestations or certifications. Ask the partner to name the independent auditor or certification body your framework requires, and confirm in the statement of work who collects each artifact, in what format and on which schedule.
Before signing, confirm three things in writing: which release line and support window the build will target (check the OpenStack releases site and the Kubernetes releases page for the current status of each), who owns upgrades after handover, and whether ongoing support is a separate retainer. Fixed scope covers the agreed deliverables and timelines, so a planned upgrade to a later SLURP release or a new Kubernetes minor version may need its own agreement. DeployOpen does not publish a price list, so request a quote built from the written scope and compare it against the cost of the internal skills you would otherwise need to hire or train.
How DeployOpen scopes and supports OpenStack deployments
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For an OpenStack build, we start by confirming which deployment project fits your team and hardware, then agree the scope in writing before any work begins.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the chosen deployment project, the OpenStack release, the hypervisor and the storage backend.
- We confirm which services run in containers and which, if any, run on metal, such as cinder-volume with LVM or iSCSI.
How we build
- We build the control plane, network interfaces and storage layout in your cloud accounts, data centers or air-gapped network.
- We customize and integrate identity, such as Keystone federation with your existing identity provider, and document each mapping rule.
- We test upgrade paths against the release cadence and document which SLURP or adjacent-release jump your environment will use.
How we hand over
- Handover includes architecture documentation, runbooks and the configuration repository for your Kolla-Ansible, OpenStack-Ansible or OpenStack-Helm code.
- We document backup and restore procedures for the control plane database and the storage backend in use.
- Your operators receive hands-on walkthroughs so the team can run day-two tasks without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any reports or certifications.
- Before choosing a retainer, confirm response expectations and upgrade windows in writing, since these depend on your scope.
