What an OpenStack implementation involves
An OpenStack implementation plan starts with a decision to build a private cloud in data centers you control, and that decision should be tested before any hardware is ordered. The plan covers the control plane services you choose to run, the compute, network and storage design beneath them, the deployment tooling, the identity integration, and the team that will operate the platform after handover. Each piece has a cost, and each is easier to size once the scoping inputs below are written down.
The scoping inputs are workloads, tenants, growth and compliance. For workloads, list VM counts, sizes, operating systems, and whether any need GPUs, high-throughput storage or direct network attachment. For tenants, record how many teams or customers will share the cloud, how projects map to them, and what isolation each group expects. For growth, agree on a capacity model with headroom for maintenance and host failure. For compliance, identify which controls apply to the platform and which evidence an assessor will request. DeployOpen prepares that evidence, while independent auditors issue any reports.
OpenStack's official code is licensed under the Apache License, Version 2.0, so the upstream software carries no license fee. The cost sits in design, hardware, deployment, integration and operations: the racks, switches and storage you buy or lease, the engineering time to design and deploy, the connections to your identity, backup and monitoring systems, and the people who patch and upgrade the platform. OpenInfra reports OpenStack running in more than 300 public cloud data centers, which shows the code is used at scale. Your own sizing still depends on your workloads and tenants.
For in-house versus partner delivery, the short answer is that building in-house suits teams that already run Linux, Ansible or Kubernetes at scale and can staff upgrades and on-call for a cloud. A partner suits teams that lack those skills for the first build or that have a fixed timeline and a scope agreed in writing. Whichever route you choose, ask for a written scope that lists services, hardware assumptions, handover documents and who operates the platform after go-live. Confirm the current release and its maintained status on the OpenStack releases site before you fix the design.
What the implementation scope covers
Each package below is a bounded piece of work with a named deliverable. Items marked optional add cost and should be priced separately in the written scope.
Release and deployment tooling
Choose the target OpenStack release and the deployment tool before hardware is ordered. The 2026.1 Gazpacho release is a SLURP release, which affects the upgrade path, and 2026.2 Hibiscus is the later option. Kolla-Ansible runs services in Docker containers, while OpenStack-Ansible uses LXC containers or bare metal. Deliverable: a pinned release and a version-controlled inventory and configuration repository.
Core services in scope
Name each enabled service in the written scope: Compute (Nova), Networking (Neutron), Block Storage (Cinder), Image (Glance), Identity (Keystone) and Dashboard (Horizon). Optional extras such as orchestration, object storage or load balancing add integration and test time. Deliverable: a service inventory listing enabled, disabled and deferred components, with the reason for each.
Control plane, hardware and network design
Agree how controllers, the database and the message queue are placed, how many nodes carry each role, and how compute, storage and management traffic are separated. Ask for rack elevations, NIC and switch specifications and the IP plan before purchase. Deliverable: a documented topology and bill of materials for review before any hardware is ordered.
Storage backend selection
Decide whether Ceph serves Glance images, Cinder volumes and Nova guest disks, or whether another backend is used. Ceph block devices let virtual machines boot without local hypervisor storage, but Ceph needs its own nodes, pools and failure domains. Optional: S3-compatible object storage through Ceph. Deliverable: pool design, a sizing worksheet and boot-from-volume test results.
Identity federation with Keystone
Keystone can federate with an existing identity provider over SAML 2.0 or OpenID Connect, and mapping rules assign federated users to groups, roles and projects. Confirm which system holds the user directory and whether Keystone-to-Keystone federation is needed. Deliverable: the federation configuration, the mapping rule set and a tested login matrix for each role.
Monitoring, backup and operator handover
Agree the metrics and log sources, alert routing, and a backup scope that covers control plane databases, Glance and Cinder data and configuration repositories. Restore tests should be part of acceptance, not an afterthought. Deliverable: runbooks, architecture documentation, backup and restore procedures and a handover session with the team that will operate the cloud.
What drives cost and duration
Each row names a factor that moves OpenStack implementation effort or schedule, why it matters, how to keep it manageable and what to ask a partner to state in the quote.
| Driver | Why it moves effort | How to keep it down | What to ask in the quote |
|---|---|---|---|
| Number of hosts and sites | Each compute, storage and controller host needs racking, network cabling, bootstrap, inventory entries and burn-in testing, and each additional site adds its own network design and failure domain planning. | Standardize on a small number of hardware profiles and deploy one site first; treat additional sites as a later phase. | Host count per role, number of sites, and which hardware profiles the quote assumes. |
| Services enabled | Every OpenStack service adds configuration, API endpoints, database schemas, policies, monitoring and upgrade testing, so the service list is the largest scope lever. | Limit phase one to compute, networking, image and block storage and identity; add orchestration, load balancing or dashboards later. | Named list of services in scope and the services explicitly excluded. |
| Storage backend and data volume | A Ceph cluster needs its own pool design, failure domain layout, network separation and capacity testing, and migrating or seeding large data sets adds transfer time. | Decide the storage backend early, size pools from expected workloads, and defer bulk data migration to a separate workstream. | Storage backend, usable capacity assumed, replication or erasure coding choice, and whether data migration is included. |
| Identity sources and federation | Connecting Keystone to an identity provider over SAML 2.0 or OpenID Connect, or adding LDAP, requires attribute review, mapping rules to projects and roles, and joint testing with the identity team. | Confirm the single identity provider and the group model before build; keep mapping rules to a small role set at first. | Identity sources in scope, federation protocol, number of mapping rules and who supplies the identity provider configuration. |
| Integrations with existing tooling | Monitoring, logging, ticketing, CMDB, backup software, DNS and certificate authorities each need credentials, data flows and failure handling that the cloud team does not own. | List integrations by priority, and agree which ones are required for go-live and which follow afterward. | Each integration named, the owning team for each, and whether vendor-side work is included. |
| Customization of dashboards, policies or templates | Horizon branding, custom Keystone or Nova policies and Heat templates each need design, review and regression testing, and custom code raises the cost of every later upgrade. | Use default policies and standard templates where possible; record each customization with its reason so it can be reviewed at upgrade time. | Customization items listed, the test scope for each and how upgrade impact is handled. |
| Number of environments (lab, staging, production) | Each environment needs its own deployment run, configuration variables and validation pass, and keeping them aligned is ongoing work. | Build the lab with the same deployment tooling as production and promote configuration through version control rather than hand edits. | Environments included, whether they run on separate hardware, and how configuration is promoted between them. |
| Compliance evidence requirements | Assessors may ask for configuration baselines, access reviews, logging evidence, encryption settings and change records, which takes time to collect and document. | Agree the control framework early and design logging and change records into the build instead of adding them at the end. | Evidence items to be produced, format, and confirmation that DeployOpen prepares evidence while independent auditors issue any assessment result. |
| Client team readiness | Staff who have not run OpenStack need time for hands-on operation, and gaps in Linux, networking or storage skills extend handover and knowledge transfer. | Assign named operators early, schedule training during build, and plan supervised operation before handover. | Who is trained, how knowledge transfer is delivered, and what support is included after go-live. |
Implementation phases and outputs
The sequence moves from agreed workloads to a tested, handed-over OpenStack cloud, with each phase closing on a written output.
Inventory workloads and requirements
Your team and DeployOpen review the services, tenants, workloads, compliance obligations and growth expectations the cloud must support. The output is a workload inventory and a requirements document, signed off by the business owners who will use the platform.
Design architecture, hardware and network
DeployOpen drafts the control plane layout, compute, storage and network topology, identity approach and deployment tooling choice, with the reasons for each decision recorded. The output is an approved design document and a bill of materials that lists every server, switch, disk and licence your team needs to order.
Build the lab with the chosen tooling
Using the deployment tooling selected in the design, such as Kolla-Ansible or OpenStack-Ansible, the team builds a non-production environment that mirrors the planned topology. The output is a version-controlled inventory and configuration set that deploys the lab from a clean start, with the deployment steps documented.
Onboard a pilot tenant
A small group of real users or a representative workload moves onto the lab or early production cloud through the planned projects, quotas, roles and identity mappings. The output is a pilot report listing defects found, changes made to the design and open questions for the production build.
Build the production environment
DeployOpen and your team build the production cloud from the same version-controlled configuration used in the lab, adding the storage backends, backup targets and monitoring defined in the design. The output is a production build record that lists versions, host configurations and any deviations from the design, each with a reason.
Test including failure and recovery
The team runs functional tests, then deliberately fails hosts, storage nodes, network links and control plane services to confirm the cloud behaves as designed and can be restored. The output is a test report with results, a tested recovery runbook and an acceptance checklist that the sponsor signs before handover.
Hand over and train operators
Your operators receive the runbooks, architecture records, monitoring setup and access model, then practice routine and recovery tasks under supervision. The output is a completed handover package and a record of which operators have passed the agreed training exercises. Ask for phase timing and the handover criteria in the written scope.
What to keep in-house and what to outsource
This table compares the OpenStack work teams usually keep internally with the work they often hand to a partner, and lists the skills the internal owner needs for each row.
| Work area | Usually kept in-house | Often outsourced | Internal skills needed |
|---|---|---|---|
| Workload ownership | Tenant onboarding, project quotas, flavor requests and day-to-day tenant support | Not usually outsourced after handover | Linux basics, OpenStack CLI and Horizon use, basic Nova and Neutron troubleshooting |
| Tenant policy decisions | Who gets which roles, which projects map to which groups and what images are allowed | Drafting policy files as a one-time input to the design | Keystone role and mapping concepts, identity administration, policy file review |
| Day-to-day operations | Monitoring, capacity checks, service restarts, log review and routine maintenance windows | Initial monitoring and alerting setup, with handover to the internal team | Linux and networking, Ceph operations, Kolla-Ansible or OpenStack-Ansible runs, incident response |
| Change approval | Sign-off on upgrades, configuration changes and maintenance windows | Preparing change packages with test evidence for each proposed change | Change management practice, reading release notes, judging risk per service |
| Architecture review | Final decisions on network design, storage layout and failure domains | Independent review of the design against the scoped requirements | Networking, storage design concepts, enough OpenStack depth to challenge proposals |
| Initial deployment | Operating the environment after go-live and taking part in acceptance tests | Building the control plane and compute, storage and network integration on your hardware | Python or Ansible for reading and changing deployment code, inventory and secrets handling |
| Integration build | Owning business-side integrations and their credentials after handover | Building Keystone federation, Ceph backends and other integrations to the agreed design | Identity administration, Ceph operations, Python or Ansible for integration scripts |
| Hardening and runbook creation | Reviewing runbooks and running recovery drills on a schedule | Writing hardening baselines, TLS and policy settings and first-draft runbooks | Linux security, TLS and certificate handling, incident response, documentation habits |
| First upgrade rehearsal | Running the upgrade in production and signing off the result | Rehearsing the first upgrade in a non-production copy and documenting each step | Ansible or Kolla-Ansible runs, service-by-service testing, rollback procedures |
What usually goes wrong and how to prevent it
Each pattern below appears often in OpenStack projects. Each one has a scoping or acceptance decision that prevents it.
Undersized control plane or fabric
Control services, the database and the message queue are often sized for a lab, then carry the full tenant API load in production. The network fabric is also sized late, so Ceph replication traffic and tenant traffic end up sharing the same links. Ask for a sizing review tied to the expected instance count and storage traffic before hardware is ordered.
Storage designed without a pool plan
Ceph-backed Glance, Cinder and Nova can end up sharing pools that nobody assigned, so image, volume and guest disk data land wherever the defaults point. Agree the pool layout, the replication or erasure coding choice, and the failure domains in the scope document before the cluster is built. Confirm an owner and a growth assumption for each pool.
Identity mappings that grant wrong projects
Keystone mapping rules translate claims from the identity provider into groups, roles and projects. A loose rule or an overlapping group can give a federated user access to a project they should never reach. Make the mapping a written acceptance item: test each rule with sample users from every group, and confirm that unmatched users receive no project access.
Release chosen outside its maintained window
Check each candidate release's phase on the OpenStack releases site during scoping, and record it in the design. Stable branches are maintained for approximately 18 months, after which only SLURP releases move into an unmaintained phase before end of life. Upgrades are supported between SLURP releases as well as between adjacent releases, so write the planned upgrade path and the end date into the acceptance criteria.
Drift from manual, undocumented changes
A lab tuned by hand rarely matches production, so tests pass in one environment and fail in the other. Manual fixes on hypervisors or control nodes that never reach the configuration repository create the same gap. Keep deployment inputs under version control, require every change to be committed, and include a drift check in the handover acceptance.
No tested backup or restore
Backups of the database, Glance images, Cinder volumes and Ceph pools are often configured but never restored. Only a restore into an isolated environment proves that the set is complete and consistent. Put a timed restore of each component into the acceptance tests, and name the person who runs it on a set schedule.
How the work changes by starting point
A new data center lets the design start from the workload plan, so most scope items are settled in the order they are needed. Hardware, network and identity can all be fixed before the first control plane node is installed.
- Scope: Service selection is the main scope decision, including whether Ceph is built alongside compute or added in a later phase.
- Cost drivers: Costs are mostly purchase-side, covering servers, switches, rack power, cooling and cabling. These are largely one-time costs.
- Decide early: Choose the deployment tool (Kolla-Ansible or OpenStack-Ansible), the release you start on, and the identity source that Keystone will federate with.
- Ask for: A bill of materials with vendor-confirmed lead times, a rack elevation with a power budget, and a written test plan for the first build.
Reusing servers and storage moves much of the effort from procurement to assessment. Each component has to be checked against the OpenStack release and Ceph version you plan to run before the design is final.
- Scope: Add a compatibility review of CPU generations, network adapters, drive types and firmware levels for every host class.
- Cost drivers: Costs shift toward remediation and testing, such as firmware updates, drive replacement and extra nodes for capacity the older hardware cannot provide.
- Decide early: Settle whether existing storage arrays stay in service and whether reused hosts run compute only or also join the Ceph cluster.
- Ask for: An inventory listing model, firmware and age for each host, the vendor's support status, and burn-in results per host class. If you are also moving workloads, see Migrate from VMware to OpenStack for the hardware reuse pattern.
In a sovereign or air-gapped network, the deployment must pull every package and image from sources you host. The mirror becomes part of the scope, and each update has to pass through it before reaching production.
- Scope: Add an internal mirror for container images, operating system packages, Python packages and source repositories, and confirm the deployment tool uses only that mirror.
- Cost drivers: Costs include mirror infrastructure, artifact storage and validation time. Re-mirroring and retesting each update is a recurring cost that grows with the number of platforms you run.
- Decide early: Define how updates enter the enclave, who approves them, and how identity reaches an external provider through a controlled path, if one is needed.
- Ask for: A list of every external endpoint the deployment touches, a mirror manifest with versions, and an evidence record showing the install completed with no outbound access. For the update cycle, see OpenStack upgrades and support.
A multi-site design multiplies the build, because each site needs its own power, network and storage layout. Separate failure domains only work if the sites are designed to fail independently and the links between them are sized for that role.
- Scope: Plan each site's control plane and storage, then design cross-site replication for images, backups and identity.
- Cost drivers: Costs grow with duplicated hardware per site, inter-site links and the staff time to run more than one environment. Link capacity is a recurring cost.
- Decide early: Decide whether sites are separate regions or cells, where the identity provider runs, and which site loss the design must survive. Ceph CRUSH failure domains set how data is spread across racks and rooms.
- Ask for: A written failure-domain map, link latency and bandwidth targets confirmed by your network team, and a test plan that simulates the loss of one site. For control plane design, see OpenStack high availability.
What you need to provide before work starts
The fastest way to a firm OpenStack scope is to name the people and inputs that the design depends on before the first workshop. Most change orders on private cloud projects trace back to a decision that was assumed rather than confirmed, such as which team owns the Neutron provider networks or whether the spine switches already have spare ports. Ask your organization to name one accountable owner each for networking, storage, identity and security, with authority to approve design choices in their area.
Hardware and facility data drive the compute, Ceph and network sizing. Provide the server models, CPU, memory and disk configuration, NIC speeds and the BMC and out-of-band management details for each host. Add rack elevations, available power per rack, cooling capacity and cable routing constraints. Without these, the plan cannot confirm how many control plane nodes fit, whether storage nodes can share racks with compute, or where a failure domain begins and ends.
Network and naming data prevent rework during the build. Supply IP address plans for management, tenant, storage and API networks, the VLAN IDs already in use, the planned MTU, routing boundaries, DNS zones and the certificate authority that will sign API endpoint certificates. Identity needs the same treatment: the identity provider product and version, metadata or discovery URLs, the group structure that should map to OpenStack projects and roles, and the attributes your provider can release.
Access and workload data complete the picture. Grant the delivery team the cloud accounts, hypervisor console access, switch management access and change windows they need in a test environment first. Provide a workload inventory with vCPU, memory, storage and network needs, expected growth over the first year, and any workloads that must be isolated. Also name the compliance requirements, the evidence owner for each control and the decisions on release choice, deployment tooling and support model, because these settle which maintained branch, Kolla-Ansible or OpenStack-Ansible path, and support arrangement the estimate assumes.
Questions buyers ask about OpenStack implementation
What drives the cost of an OpenStack implementation and what should a fixed-scope quote include?
Scope drives most of the cost: which services run, how many compute, storage and network nodes you need, and how many integrations are built. A fixed-scope quote should list the services in scope, the hardware and network design review, the deployment tooling and environments, the identity and Ceph storage work if included, the testing and handover steps, the documentation delivered, and the assumptions the price depends on. Ask that each deliverable has a named acceptance check and that exclusions are written down. Your own hardware, power and staff costs sit outside the implementation quote.
Does OpenStack charge license fees, and where do the main costs sit?
No license fee applies to the upstream code. Official OpenStack projects must be licensed under the Apache License, Version 2.0. The main costs sit elsewhere: hardware, data center power and cooling, network equipment, the implementation work, and the engineers who operate the cloud after handover. Commercial distributions and vendor support contracts are a separate choice with their own pricing, so request that in writing. Ask every provider to separate one-time costs (design, build, migration) from recurring costs (support, staff time, hardware refresh).
How long does an OpenStack implementation take, and what sets the timeline?
The written scope sets the duration, so no single timeline applies across projects. The main drivers are how many services are in scope, how many hardware and network designs must be approved, whether storage is Ceph-backed, how many identity sources are federated, how many workloads must migrate, and how quickly your teams return approvals and access. Ask for a timeline with milestones tied to deliverables and a list of dependencies on your side. If the project includes a VMware migration, confirm that phase as a separate line in the quote.
What skills and inputs must our team supply for an OpenStack build?
Your side needs a named owner who can approve design decisions, network and IP plans, hardware access, and identity source details. Engineers who will run the cloud after handover should understand Linux, VLANs and routing, storage concepts, and the basics of Ansible and containers. Typical inputs include a hardware inventory, rack and power details, IP address ranges, DNS and certificate authorities, and identity provider metadata. Whether your team can build it alone depends on those skills and the time they can commit, so ask the partner which tasks transfer to your staff.
How do I choose between Kolla-Ansible and OpenStack-Ansible?
Choose on the operating model your team will maintain, since both tools deploy OpenStack. Kolla-Ansible deploys services in Docker containers driven by Ansible, while OpenStack-Ansible deploys in LXC containers or on bare metal. Evaluate which container approach fits your standards, how your team already handles Ansible and image builds, and how you will rehearse upgrades. Check the current guidance in the OpenStack 2026.1 deployment guides before deciding. Then use the Kolla-Ansible deployment guide to plan the operating steps.
How should we pick an OpenStack release for a new private cloud?
Prefer a SLURP release, because upgrades are supported between SLURP releases as well as between adjacent releases. The 2026.1 Gazpacho release is a SLURP release, released on 2026-04-01. The 2025.1 Epoxy release, also SLURP, was released on 2025-04-02 and remains in the maintained phase, as does 2025.2 Flamingo. The 2026.2 Hibiscus release was released on 2026-09-30, and 2027.1 Indri, also SLURP, is in development with an estimated release of 2027-03-24. Confirm the current status of any release on the OpenStack releases site on the day you decide.
How DeployOpen scopes and delivers OpenStack
DeployOpen plans, implements, hardens, documents and supports OpenStack inside the infrastructure you control, from a written scope agreed before work starts. The cost and timeline follow from what that scope includes, so the scoping stage is where most decisions are made.
How we scope
- Engagements are fixed-scope, with services, deliverables and timelines agreed in writing before work starts.
- We map which OpenStack services, hypervisors and storage backends your workloads need, including whether Ceph is in scope.
- We review your data center or cloud network, hardware inventory, identity sources and compliance evidence needs before estimating effort.
- You receive a quote that follows directly from the written scope, so changes in scope show up as changes in cost.
How we build
- We choose between Kolla-Ansible and OpenStack-Ansible based on your operating model, then build from version-controlled inventories and configuration.
- Keystone federation, mapping rules to projects and roles, and Ceph block device integration are configured and tested against your requirements.
- Each service is tested in a staging environment before cutover, and the test results are recorded as part of the deliverables.
- Network, storage and control plane designs are documented so your team can review the decisions before production use.
How we hand over
- You receive architecture documentation, runbooks, configuration repositories and the test evidence collected during the build.
- We walk your engineers through day-two operations, including upgrades, backups and host maintenance, before the engagement closes.
- Upgrade planning follows the release cadence and the maintained-branch window, and we document the path from your current release.
- Access, secrets and administrative accounts are transferred to your team in a controlled handover with a record of what changed.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Retainer scope should state which services, environments and response processes it covers, and you should confirm these in writing.
- Upgrades between releases are tested per service before they reach production, following the change process you agree on.
- Support terms, response expectations and any SLAs are set in the written agreement, so confirm them with us before signing.
