Which tool should you use to deploy OpenStack in 2026? This guide covers every major option — from quick dev setups to production-grade multi-node clusters — so you can make an informed decision without wasting days on the wrong approach.
Why Choosing the Right Tool Matters
Deploying OpenStack manually is a multi-day exercise in frustration: dozens of services, intricate inter-dependencies, networking configuration that can silently break in three different layers. Deployment tools exist to abstract that complexity — but they don't all do it the same way, and picking the wrong one for your use case is a real cost.
The ecosystem has also shifted significantly in recent years. Some tools that dominated five years ago are now deprecated or unmaintained. New ones have emerged targeting containerized and Kubernetes-native workflows. And a persistent gap has remained for anyone wanting a clean, native deployment on Debian/Ubuntu without containers.
This article analyses every relevant tool available today, from the simplest all-in-one installer to enterprise-grade orchestrators. Each entry covers: what it is, how it works under the hood, its strengths and weaknesses, and when you should (and shouldn't) use it.
The Tools at a Glance
| Tool | Base Technology | Target OS | Node Support | Containers | Active? |
|---|---|---|---|---|---|
| DevStack | Bash scripts | Any Linux | Single | ❌ | ✅ |
| Packstack | Puppet | RHEL / CentOS | Single / Multi | ❌ | ⚠️ Legacy |
| OpenStack-Ansible | Ansible + LXC | Ubuntu / Debian | Multi | LXC | ✅ |
| Kolla-Ansible | Docker + Ansible | Any Linux | Multi | Docker | ✅ |
| MicroStack / Sunbeam | Snap / MicroK8s | Ubuntu | Single / Small | K8s (Sunbeam) | ✅ |
| TripleO | Heat + Ironic + Puppet | RHEL | Multi (Bare Metal) | ❌ | ❌ Deprecated |
| OpenStack-Helm | Kubernetes + Helm | Any (K8s) | Multi | K8s | ✅ |
| DeployStack | Python CLI | Debian / Ubuntu | Single | ❌ | ✅ |
DevStack
Type: Development / Testing tool
Maintained by: OpenStack Community
Repository: opendev.org/openstack/devstack
What It Is
DevStack is the official "get OpenStack running right now" tool. It is a collection of shell scripts that download, compile, and configure OpenStack from source, targeting a single machine. Its primary audience is developers working on OpenStack itself, or people who need a quick functional environment to test an API or prototype an integration.
How It Works
DevStack pulls the latest code directly from each OpenStack project's repository, installs Python dependencies into virtual environments, and launches all services as systemd units or screen sessions. The entire stack runs as processes on the host — no containers, no virtualization.
Strengths
- Fastest path to a running OpenStack — installation takes 15–30 minutes on a reasonably fast machine
- Always up to date — runs from source, so you can test bleeding-edge changes
-
Highly configurable — a
local.conffile controls which services to enable, which backends to use, and how networking is configured - First-class documentation — as the official dev tool, documentation and community support are excellent
Weaknesses
- Not for production, ever — the project documentation itself says so explicitly. Services are not hardened, HA is not supported, and the setup is fragile by design
- Repeated runs are destructive — re-running DevStack on an existing installation will wipe it and start fresh
- Consumes significant resources — running all core services on a single node requires at least 8 GB RAM
- Breaks after reboots — services are not always reliably recovered after a system restart
When to Use It
Use DevStack when you are developing or debugging OpenStack code, testing a new feature upstream, or need a throwaway environment for a few hours. Never use it as a baseline for anything that needs to persist or serve real workloads.
Packstack
Type: Rapid deployment tool for RHEL-based systems
Maintained by: Red Hat / RDO Project
Repository: github.com/openstack/packstack
What It Is
Packstack is a command-line utility that uses Puppet modules to deploy OpenStack on Red Hat Enterprise Linux, CentOS, and derivatives. It was the go-to tool for quickly standing up an OpenStack node on the RDO (community RHEL OpenStack distribution) ecosystem, and it remains the conceptual reference point when describing "a simple, single-node OpenStack installer for Linux."
How It Works
Packstack generates a configuration file (answer file) through an interactive questionnaire, then drives Puppet to configure all OpenStack services using RPM packages from the RDO repository. It supports both single-node all-in-one (AIO) and basic multi-node deployments.
Strengths
- Simple to use — a few commands are enough to get a working environment
- Answer file driven — the generated config file is reproducible and shareable
- Mature codebase — years of battle-testing on RHEL environments
- No container overhead — deploys directly as OS packages
Weaknesses
- RHEL/RPM only — does not support Debian, Ubuntu, or any non-RPM distribution
- Limited to PoC / lab use — lacks proper HA support and is not recommended for production by the RDO project itself
- Puppet dependency — requires Puppet to be present and correctly configured, which adds its own maintenance surface
- Slow development pace — the project has seen significantly reduced activity as focus shifted to Kolla-Ansible
When to Use It
Use Packstack if you are on a RHEL-based system and need a fast proof-of-concept or learning environment. It is the closest thing to "apt-get install openstack" for the RPM world. Do not use it for production, and do not expect it to work on Ubuntu or Debian.
The Debian/Ubuntu gap: There is no equivalent of Packstack for Debian/Ubuntu systems — no tool that deploys OpenStack natively via APT packages with a simple CLI workflow. This gap is what motivated the creation of DeployStack (covered below).
OpenStack-Ansible (OSA)
Type: Production deployment and lifecycle management
Maintained by: OpenStack Community
Repository: opendev.org/openstack/openstack-ansible
What It Is
OpenStack-Ansible is one of the two "serious" production deployment tools maintained directly under the OpenStack project umbrella. It uses Ansible playbooks to deploy OpenStack services either directly on bare metal or inside LXC containers on each host, providing process isolation without the overhead of full Docker containerization.
How It Works
OSA provisions LXC containers on target hosts — one or more containers per service — and deploys OpenStack packages inside them. Networking between containers uses a set of Linux bridges and VLAN-tagged interfaces. The deployment is driven by a layered configuration system where operators override defaults at increasing levels of specificity.
Strengths
- Production-grade — supports full HA, rolling upgrades, and multi-region deployments
- LXC isolation without Docker — containers provide service isolation and easier troubleshooting than bare-metal deployments without introducing Docker's complexity
- Deep customization — virtually every aspect of the deployment is configurable through Ansible variables
- Good Debian/Ubuntu support — OSA has first-class support for Ubuntu, making it one of the few production tools that works well in that ecosystem
- Actively maintained — regular releases aligned with OpenStack's release cycle
Weaknesses
- High operational complexity — the learning curve is steep; understanding the LXC topology, the bridge networking, and the Ansible variable hierarchy takes significant time
- Slow deployments — a full OSA install can take 1–3 hours depending on hardware and the number of services
- Heavy on resources — the LXC container overhead means OSA is realistically a multi-node tool; single-node AIO is possible but resource-intensive
- Documentation can be inconsistent — some areas are well-covered, others require reading source code
When to Use It
OSA is ideal for organizations that want a production-grade, non-containerized OpenStack on Ubuntu and need full control over the deployment without adopting Docker or Kubernetes. It is a strong choice for environments where LXC is already familiar or where Docker is not an option.
Kolla-Ansible
Type: Production deployment via Docker containers
Maintained by: OpenStack Community
Repository: opendev.org/openstack/kolla-ansible
What It Is
Kolla-Ansible is currently the most widely adopted production OpenStack deployment tool in the community. It packages every OpenStack service into purpose-built Docker containers and uses Ansible to orchestrate their deployment across one or more nodes. The project's stated mission is to provide "production-ready containers and deployment tools for operating OpenStack clouds."
How It Works
Kolla builds Docker images for each OpenStack service (Nova, Neutron, Keystone, etc.) and publishes them to Docker Hub and Quay.io. Kolla-Ansible pulls these images and deploys them using Ansible, managing configuration files, networking, and service startup. HAProxy and Keepalived are used for HA virtual IPs; MariaDB Galera for database clustering.
Strengths
- Production-ready out of the box — HA, rolling upgrades, and multi-region are all supported and well-documented
- Container isolation — each service runs in its own container, making upgrades, rollbacks, and debugging cleaner
- Broad OS support — works on any Linux distribution that runs Docker
- Large community and ecosystem — the most active OpenStack deployment project; bugs get fixed quickly, new features land regularly
- Good all-in-one support — single-node deployments are a first-class use case, making it viable for both development and small production environments
Weaknesses
- Docker is a hard requirement — you are adopting Docker's entire operational model: image pulls, registry access, container lifecycle management
-
Steep initial learning curve — the
globals.ymlandpasswords.ymlconfiguration system, combined with Docker's networking model, has many failure modes for newcomers - Upgrade complexity — while upgrades are supported, they require careful orchestration and can fail in non-obvious ways
- Image size — pulling all Kolla images for a full deployment requires several gigabytes of downloads
When to Use It
Kolla-Ansible is the default recommendation for production OpenStack in 2025, particularly for multi-node deployments. If you have Docker familiarity, Ansible experience, and need a reliable, well-supported path to production, this is your tool. It works equally well for single-node environments if Docker overhead is acceptable.
MicroStack / Sunbeam
Type: Simplified single-node / small-scale deployment
Maintained by: Canonical
Repository: github.com/canonical/snap-openstack (Sunbeam)
What It Is
MicroStack was Canonical's effort to make OpenStack deployable in a single snap install microstack command. Sunbeam is its successor and current iteration, offering a more polished experience built on top of MicroK8s (Canonical's single-node Kubernetes distribution) and Juju operators. It targets users who want OpenStack running quickly without deep cloud infrastructure expertise.
How It Works
Classic MicroStack packaged OpenStack services as a monolithic snap package. Sunbeam rearchitects this: it uses MicroK8s as the underlying platform, deploys OpenStack services as Kubernetes workloads managed by Juju charms (operators), and exposes a simplified CLI for bootstrapping and management.
Strengths
- Fastest path to a working OpenStack on Ubuntu — literally a handful of commands
- Self-contained — snap packaging handles dependencies, avoiding conflicts with system packages
- Low barrier to entry — designed for users without deep OpenStack or Linux networking expertise
- Active development by Canonical — frequent updates and good integration with Ubuntu
Weaknesses
- Snap confinement limits flexibility — networking and storage customization is harder than with a bare-metal install
- MicroK8s dependency (Sunbeam) — you are now running OpenStack on top of Kubernetes on a single node, adding a significant layer of complexity that can be opaque to debug
- Not suitable for production at scale — designed for small footprints; scaling Sunbeam beyond a few nodes is not straightforward
- Ubuntu-only — the snap ecosystem does not extend to Debian or other distributions
- Limited driver support — some Neutron backends and Nova drivers are not supported in the snap packaging
When to Use It
Use Sunbeam/MicroStack for demos, learning, and development on Ubuntu workstations or laptops. It is the easiest way to show OpenStack to someone who has never seen it. It is not a production deployment tool in the traditional sense, and the hidden Kubernetes layer can make troubleshooting non-trivial.
TripleO
Type: Enterprise bare-metal deployment (DEPRECATED)
Maintained by: Red Hat (historically)
Status: ❌ Officially deprecated as of 2023
What It Was
TripleO (OpenStack On OpenStack) was Red Hat's enterprise-grade deployment framework for large-scale, bare-metal OpenStack. Its core concept was elegant and ambitious: use a "undercloud" OpenStack instance to provision and manage the "overcloud" production OpenStack, leveraging Nova for compute provisioning, Ironic for bare-metal management, and Heat for orchestration.
Why It Was Deprecated
The approach proved difficult to maintain and operate in practice. The undercloud added a significant resource and complexity burden. Upgrades were notoriously difficult. As Ansible matured and Kolla-Ansible gained traction, Red Hat shifted its investment toward those tools and eventually announced the deprecation of TripleO in favor of TripleO-based Ansible workflows and, eventually, Kolla-Ansible for new deployments.
Should You Use It?
No. If you are running TripleO today, migration to Kolla-Ansible or OpenStack-Ansible is the recommended path. New deployments should not use TripleO under any circumstances.
OpenStack-Helm
Type: Kubernetes-native production deployment
Maintained by: OpenStack Community + AT&T, SK Telecom, others
Repository: opendev.org/openstack/openstack-helm
What It Is
OpenStack-Helm (OSH) packages every OpenStack service as a Helm chart for deployment on Kubernetes. It targets organizations that already operate Kubernetes infrastructure and want to run OpenStack as a workload on top of it — treating OpenStack services the same way they treat any other cloud-native application.
How It Works
Each OpenStack service is a Helm chart with templated Kubernetes manifests. Configuration is managed through Helm values files. A companion project, openstack-helm-infra, provides the underlying infrastructure components (MariaDB, RabbitMQ, Memcached, Ceph, etc.) also as Helm charts. Deployment requires a functioning Kubernetes cluster as a prerequisite.
Strengths
- Cloud-native operations model — rolling updates, pod-level restarts, Kubernetes-native health checks and autoscaling
- Infrastructure as Code — everything is declarative YAML, version-controllable, and reproducible
- Strong for edge and hybrid deployments — the Kubernetes substrate makes OSH well-suited for environments that already operate K8s at scale
- Active community — supported by several large telcos and cloud operators who use it in production
Weaknesses
- Very high operational complexity — you need to be proficient in both Kubernetes and OpenStack to operate this stack. Debugging a broken service means reasoning about Kubernetes pods, persistent volumes, services, and ingress on top of OpenStack's own internals
- Kubernetes is a hard prerequisite — this adds substantial infrastructure overhead for environments that don't already run K8s
- Not beginner-friendly — there is no "quick start" in any meaningful sense; the documentation assumes deep familiarity with both ecosystems
- Resource heavy — running Kubernetes plus OpenStack on a single node requires substantial RAM and CPU
When to Use It
OpenStack-Helm is the right choice if your organization already operates Kubernetes at scale and wants to manage OpenStack as part of the same operational framework. It is not appropriate for learning, PoC, or environments without dedicated Kubernetes expertise.
DeployStack
Type: Native Python CLI installer for Debian / Ubuntu
Maintained by: Community (open source)
Repository: github.com/St3vSoft/DeployStack
What It Is
DeployStack is a Python-based command-line tool for automated, single-node OpenStack deployment on Debian and Ubuntu systems. It was created to fill a gap that has existed for years: there is no Packstack equivalent for the Debian/Ubuntu ecosystem. Every existing production-grade tool either targets RHEL, requires Docker, requires Kubernetes, or is scoped to development use only.
DeployStack deploys OpenStack directly via APT packages and Python configuration — no containers, no additional runtimes, no intermediary abstraction layers. It is the most direct path from a fresh Ubuntu or Debian installation to a functional OpenStack single-node environment.
How It Works
DeployStack provides a CLI with subcommands (deploystack deploy, deploystack image upload, deploystack volume detach, etc.) that orchestrate the installation and configuration of all core OpenStack services. It uses a YAML configuration file for deployment parameters, supports both OVS and OVN as Neutron backends, and includes a batch command runner with progress feedback. The tool is idiomatic Python and designed to be readable and extensible.
Strengths
- Native Debian/Ubuntu support — first-class APT-based deployment, no RPM, no snap, no Docker
- No container overhead — services run directly on the host, making resource usage predictable and debugging straightforward
- Simple CLI interface — designed around the user's workflow, not the tool's internal architecture
- Ubuntu 24.04 LTS (Noble) optimized — tested and validated against the recommended long-term support platform with native Caracal packages
- OVS and OVN support — flexible Neutron backend selection via config
- Actively maintained — real-world bug reports from community users are addressed quickly
- Extensible architecture — centralized template management, separated CLI and orchestration logic, batch executor with spinner feedback
Weaknesses
- Single-node only (currently) — multi-node support is on the roadmap but not yet implemented
- Ubuntu/Debian only — intentionally scoped; not a cross-distribution tool
- Younger project — smaller community and ecosystem compared to Kolla-Ansible or OSA
When to Use It
DeployStack is the right choice when you need a production-capable, single-node OpenStack on Debian or Ubuntu without Docker, Kubernetes, or the complexity of Kolla-Ansible. It is particularly well-suited for:
- Homelab and on-premises private cloud deployments
- Learning and development environments where native-package deployments are preferred
- Environments where Docker is not available or not desired
- CI/CD pipelines that need a lightweight, reproducible OpenStack setup
- Anyone who would have used Packstack if they were on RHEL
Decision Guide: Which Tool Should You Use?
┌─ Are you on RHEL / CentOS?
│ ├─ Yes, PoC / lab only → Packstack
│ └─ Yes, production → Kolla-Ansible
│
├─ Are you on Ubuntu / Debian?
│ ├─ Single-node, no Docker → DeployStack
│ ├─ Single-node, quick demo → Sunbeam (MicroStack)
│ ├─ Multi-node, production → Kolla-Ansible or OpenStack-Ansible
│ └─ You manage Kubernetes → OpenStack-Helm
│
├─ Any Linux, development only → DevStack
│
└─ Legacy TripleO environment → Migrate to Kolla-Ansible
Final Comparison Table
| Tool | OS | Nodes | Containers | Complexity | Production | 2025 Status |
|---|---|---|---|---|---|---|
| DevStack | Any Linux | Single | ❌ | 🟢 Low | ❌ | ✅ Active |
| Packstack | RHEL only | Single/Multi | ❌ | 🟡 Medium | ⚠️ PoC | ⚠️ Slow |
| OpenStack-Ansible | Ubuntu/Debian | Multi | LXC | 🔴 High | ✅ | ✅ Active |
| Kolla-Ansible | Any Linux | Multi | Docker | 🟡 Medium | ✅ | ✅ Active |
| Sunbeam | Ubuntu only | Small | K8s (snap) | 🟢 Low | ⚠️ Limited | ✅ Active |
| TripleO | RHEL | Multi (BM) | ❌ | 🔴 Very High | ✅ (was) | ❌ Deprecated |
| OpenStack-Helm | Any (K8s) | Multi | K8s | 🔴 Very High | ✅ | ✅ Active |
| DeployStack | Ubuntu/Debian | Single | ❌ | 🟢 Low | ✅ | ✅ Active |
Conclusion
The OpenStack deployment tool landscape in 2025 is more consolidated than it was five years ago. TripleO is gone. MicroStack has evolved into Sunbeam. Kolla-Ansible has emerged as the community standard for production multi-node deployments. And for the first time, Debian and Ubuntu users have a native, no-containers option in DeployStack.
The right tool depends almost entirely on your use case:
- Learning / dev: DevStack or Sunbeam
- RHEL production / multi-node: Kolla-Ansible
- Ubuntu production / multi-node: Kolla-Ansible or OpenStack-Ansible
- Ubuntu/Debian single-node, no Docker: DeployStack
- Kubernetes-native environments: OpenStack-Helm
There is no universally "best" tool — only the best fit for your OS, your scale, your team's skills, and your operational constraints. Hopefully this guide makes that choice a little clearer.
Found an error or want to add a tool? PRs and comments welcome.
Top comments (0)