How to Build a Private Cloud with OpenStack (Step by Step)

To build a private cloud with OpenStack, size the environment for your workloads, choose a deployment method, install the core services (identity, image, placement, compute and networking), add redundancy, design storage and networking, then test node failure, backup restore and an upgrade before production traffic moves. A single-node install suits evaluation only.

How to build a private cloud with OpenStack: what to settle first

A minimal OpenStack deployment is the set of services the OpenStack Installation Guide says you need at a minimum: identity (Keystone), image (Glance), placement, compute (Nova) and networking (Neutron), installed in that order. The guide advises adding the dashboard (Horizon) and block storage (Cinder) once those five are running.

That list is the floor, not the plan. If you want to set up a private cloud with OpenStack for real workloads, settle three things before you buy hardware or run an installer: which workloads the cloud will host, who will operate it day to day, and how much downtime those workloads can take. If you are still deciding whether a private cloud is the right model, start with what a private cloud is.

We cover what an OpenStack private cloud is, and when it fits, in our OpenStack private cloud guide. This article starts after that decision and goes straight to the build.

Evaluation build or production build?

An evaluation build puts every service on one host so you can learn the tooling. It tells you little about production. A production build spreads the services across several machines, keeps more than one copy of the control services, and is rebuilt and upgraded from automation instead of by hand. Decide which one you are doing now, because every step below assumes production.

Step 1: Size the cloud and plan the network

Sizing starts with your workloads, not with a server catalogue. Answer four questions in writing:

1. Which workloads move first, and how quickly will they grow?
2. How many failed machines can the cloud lose before users notice?
3. Who patches, monitors and upgrades it?
4. Which networks must stay apart from each other?

There is no universal server count. Capacity comes from your own workload list, the number of failures you want to survive and the storage layout you choose in Step 5.

The Installation Guide’s example layout shows the network split to draw first. Its management network uses private address space and carries administration traffic such as package installs, updates, DNS and NTP. Its provider network uses routable address space and gives instances their route to the internet. The addresses in the guide are examples, so give each network its own range, and read the host networking section before you finalise yours.

Step 2: Choose a deployment method

The OpenStack documentation points to three routes for an OpenStack deployment, plus the option of having someone else run it. The table sets out what each route’s own documentation says.

Details are in the Kolla Ansible quick start and the OpenStack-Ansible documentation. The Kolla Ansible quick start lists minimum host requirements for its single-node evaluation, and those requirements are not a production size. Check which host operating systems each tool supports before you commit to one.

If you are still choosing a platform rather than a tool, our guide to private cloud software and platforms compares the options.

Step 3: Deploy the core services in order

Install the five core services in the order the Installation Guide gives, and confirm each one works before you start the next. Each project’s documentation describes its role:

1. Keystone, the identity service, verifies API clients, lets services find each other and manages multi-tenant access control.
2. Glance, the image service, lets users register, find and retrieve virtual machine images.
3. Placement is a REST API service that tracks the inventory and usage of resources, organised into resource providers and resource classes.
4. Nova, the compute service, creates virtual servers and, through Ironic, bare-metal machines.
5. Neutron, the networking service, supplies connectivity to devices such as virtual network interfaces.

Then add Horizon, the web-based user interface, and Cinder, which delivers block devices to virtual machines, bare-metal machines and containers.

The Installation Guide includes a Launch an instance section that prepares the networks, flavour, key pair and security group rules for a first instance. Treat a first instance that boots and answers on the network as a first sign that the five services work together.

Our private cloud architecture diagram shows how these services sit in layers.

Step 4: Build in redundancy for the control plane

If the control services run on one machine, losing that machine stops every API call and every dashboard login. Decide three things before workloads arrive:

• how many controller nodes you run, and where they sit
• how traffic reaches the API endpoints if one controller fails
• which traffic you keep off the management network

The project’s High Availability Guide covers configuring a control plane, networking services, storage, the compute node, monitoring and testing. It calls itself a work in progress and was last updated in November 2018. Use it for the list of topics, not as a recipe, and check the detail against current documentation.

The user guide of OpenStack-Ansible has production pages of its own: a production environment example, a Ceph production example, and a guide to HAProxy and Keepalived in LXC containers.

Step 5: Design storage and self-service networking before workloads arrive

Choose where volumes, images and instance disks will live before the first workload lands, because changing the answer later means moving data.

• Storage backend. Cinder’s documentation describes a Ceph RBD driver that lets hosts use Ceph RBD images as volumes. Ceph is one documented option, and the Cinder Ceph RBD driver page shows what it needs. Check the Cinder documentation for the others.
• Self-service networking. The Installation Guide offers two Neutron options: provider networks only, or provider networks plus self-service networks. Pick one deliberately, because it shapes how projects get their own networks.
• First projects, users and networks. Decide who creates them, and in what order.

A wrong storage or network assumption is cheaper to find on paper than during the failure tests in Step 6, so write the layout down and have a second engineer read it.

Step 6: Test failure, restore and upgrade before production traffic moves

Rehearse four failures before any real workload depends on the cloud, and write down what happened:

1. Switch off one controller node. Pass means API calls and dashboard logins keep working.
2. Switch off one compute node. Pass means you know how its instances are recovered.
3. Restore a volume from backup into a new volume. Pass means the data reads back intact.
4. Upgrade a staging copy to the next version. Pass means the cloud still works afterwards, and you have a list of what changed.

A rehearsal that fails is the point of the exercise. It is cheaper than finding the same gap in production.

Upgrades follow the release cadence. As of 27 October 2026, the OpenStack releases page lists 2026.2 Hibiscus, released on 30 September 2026, as the latest series. Gazpacho (2026.1, released 1 April 2026) and Epoxy (2025.1, released 2 April 2025) are the maintained SLURP releases.

SLURP stands for Skip Level Upgrade Release Process. Under the Technical Committee’s 2022 release cadence resolution, every other major release is a SLURP release, you can upgrade directly between two consecutive ones, and a non-SLURP release can only be upgraded to the release that follows it. Plan your upgrade path around that rule before you pick a starting release.

Build it yourself or have it run for you?

Build it yourself if your team can operate OpenStack every day after the install. Four questions decide it:

• Can your people patch, monitor and upgrade OpenStack on the cadence above?
• Can you wait for the build and the rehearsals before the first workload moves?
• Which workloads cannot be down while you learn?
• Would a team of your size rather run the platform or the workloads on top of it?

We run managed private clouds on OpenStack-based environments. We design the architecture first, stay vendor-agnostic and host in carrier-neutral data centres, so your team can keep its attention on the workloads. If that is closer to what you need than a build project, tell us about your workloads.

For the cost side of the choice, see our open source private cloud architecture and TCO article.

Talk to us about your OpenStack private cloud

If building a private cloud with OpenStack is the plan but running it is not, we can start from the architecture with you. You can read about our on premise private cloud service, or talk to an infrastructure specialist directly.

Dandy Pradana

Dandy Pradana is an Digital Marketer and tech enthusiast focused on driving digital growth through smart infrastructure and automation. Aligned with Accrets’ mission, he bridges marketing strategy and cloud technology to help businesses scale securely and efficiently.