Install DevStack on a clean, dedicated Linux host or virtual machine, not on a computer you rely on for other work. For a straightforward lab, use Ubuntu 24.04 (Noble), create a non-root user with sudo access, add a minimal local.conf, and run ./stack.sh. DevStack is intended for interactive development and functional testing, so treat the installation as disposable practice infrastructure rather than a production OpenStack deployment.
Choose and isolate the lab host
Start with a clean, minimal Linux installation. Current DevStack documentation says it attempts to support the two latest Ubuntu LTS releases, Rocky Linux 9, and openEuler. If you have no reason to choose another supported system, Ubuntu 24.04 (Noble) is identified as the most tested option.
A dedicated virtual machine is often a convenient lab target because it can be reset or discarded; a dedicated physical server or cloud VM also fits the project’s deployment model. The DevStack warning is explicit: installation makes substantial changes to the system, and should be run only on a server or VM dedicated to that purpose. Do not install it on your everyday workstation or a host containing services you need to preserve.
For its documented cloud setup, the 2025.2 guidance says performance is best with 4 GB or more of RAM. That is a practical guideline for that setup, not a universal minimum: resource needs depend on which services you enable and what you run in the lab.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
Decide whether one node is enough
A single-node deployment is the simplest route for learning the OpenStack interfaces and basic resource workflows. Choose multiple nodes only when the lesson requires separation between control and compute roles, scheduler placement across hosts, or cross-node networking. The additional realism comes with more network planning and coordination.
| Consideration | Single-node lab | Multi-node lab |
|---|---|---|
| Isolation and reset | One dedicated target is easier to rebuild or discard. | Several dedicated targets must be coordinated and reset. |
| CPU and memory | All enabled services and workloads share the host’s resources. | Resources can be distributed across nodes; plan capacity for the chosen services. |
| Network complexity | Fewer hosts and interfaces to plan. | Requires static IPs, a planned subnet, and coordinated host and floating-IP ranges. |
| Best fit | API, dashboard, image, flavor, network, and volume exercises. | Scheduler placement, cross-node networking, or control/compute separation. |
The official multi-node guide’s example uses the FlatDHCP network controller and a dedicated subnet. Treat its network layout as an example to plan from, not a universal address plan: select ranges that fit your own lab and do not conflict with networks the nodes must reach.
Prepare the account and checkout
Run DevStack as a non-root account that has sudo access. The quick start offers a stack account with /opt/stack as its home directory; whichever account you use, its home directory must be executable so deployment scripts can run. If you create the account manually, grant the required sudo access, then switch to that account before cloning the repository. Make sure Git and sudo are available on the clean Linux system.
- Switch to the non-root DevStack account. Do not run the installation as root.
- Clone the project and enter the checkout:
git clone https://opendev.org/openstack/devstack cd devstack - Create
local.confat the root of the DevStack checkout. Start with the documented minimal configuration below, replacing the sample password with an alphanumeric secret suitable for your isolated lab. - Run the installer from the checkout:
./stack.sh
Configure local.conf
The minimal documented example sets passwords for the administrative account, database, message queue, and services:
Recommended Free Tools
Rank #3
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORDSave the file exactly as local.conf in the repository root before starting stack.sh. The documentation cautions that these passwords should contain only alphanumeric characters; special characters can cause some services to fail. The example uses one value for all four settings for simplicity. Use stronger, unique secrets if the environment could be exposed beyond a private lab, and do not treat the sample word secret as a real credential.
Run the installation and allow for downloads
The OpenStack project’s current documentation estimates that stack.sh takes 15–30 minutes on a clean system. The estimate is driven largely by internet speed and the Git trees and packages that must be downloaded; it is not a guarantee or a fixed timeout. Slow package mirrors, blocked outbound access, limited resources, or an outdated configuration can make a run take longer or fail.
Rank #4
Keep the terminal output and logs if the installation fails. Because DevStack changes system settings, the recovery plan should be to diagnose the failure on this dedicated target and, when appropriate, rebuild or discard the lab rather than assume the host can be returned to its prior state with a simple uninstall.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check that the lab is usable
The default installation includes Keystone, Glance, Nova, Placement, Cinder, Neutron, and Horizon. Once the deployment completes, open Horizon in a browser to exercise the web interface for virtual machines, networks, volumes, and images. In a shell, source the generated openrc file before using the openstack command-line client.
- Load the dashboard and confirm that the sign-in page responds.
- Authenticate through Horizon, then source
openrcand confirm that the CLI can authenticate. - Check that compute, network, image, and block-storage services report healthy status using the interfaces and commands available in your branch and configuration.
- Use the dashboard or CLI to list resources and confirm that the expected services are responding; exact commands and health output can differ by branch and configuration.
A successful installer process is not, by itself, proof that every service is ready for the exercise you have in mind. Check the particular workflow you plan to learn—for example, image availability before an instance launch, or network configuration before testing connectivity.
When a run fails or stalls
Use the symptoms to narrow down what to inspect rather than repeatedly rerunning the installer without changing anything.
- Downloads stop or fail: check that the host can reach the package sources and Git remotes, and consider whether a slow mirror is extending the run.
- Services fail while starting: review the installer output and logs, check the available resources, and verify that
local.confis at the checkout root and uses alphanumeric passwords. - The host is not dedicated to the lab: stop treating it as a safe target. DevStack’s system changes make a disposable VM or other dedicated host the appropriate place to continue.
- A multi-node deployment cannot communicate: revisit the static IP assignments, subnet, and planned host and floating-IP ranges before changing service settings.
For initial practice, a single-node VM minimizes the moving parts. Add nodes only when the exercise itself depends on distributed placement or networking; that keeps early troubleshooting focused on OpenStack rather than on avoidable lab topology.
