Installing DevStack on a clean Ubuntu 24.04 LTS virtual machine gives you a disposable OpenStack cloud for testing or learning. The process takes roughly 15 to 30 minutes and follows a consistent path: create a non-root stack user, clone DevStack from opendev.org, write a local.conf file, and run stack.sh. Do this only on dedicated VMs you are comfortable rebuilding — never on a machine you care about.
Here is the situation. You need OpenStack running quickly, but a full multi-node deployment is overkill. DevStack is designed exactly for this: a single-machine, all-in-one OpenStack environment. The official documentation recommends Ubuntu 24.04 LTS as the most tested release, so that is what this guide uses. Below is the step-by-step workflow, with the reasoning behind each step and the errors to watch for.
Prerequisites to check first
Before you begin, confirm the following. Skipping these is the most common reason an installation fails partway through.
| Requirement | What to use |
|---|---|
| Operating system | Clean, minimal Ubuntu 24.04 LTS (Rocky Linux 9 is also supported) |
| Host type | Dedicated virtual machine or server — not production or multi-use |
| Memory | At least 32 GB RAM recommended for a full OpenStack stack |
| Disk | Sufficient free space for git clones and built images. DevStack can consume significant disk space during installation — see our Linux disk full troubleshooting runbook if you run into space issues. |
| Network | Active internet connection to clone repositories and install packages |
| User | A non-root stack user with passwordless sudo |
The reasoning for the dedicated VM is important: DevStack modifies the host heavily — it installs packages, configures services, and changes networking. Do not run it on a laptop you use daily or on any server that hosts production data.
Step 1: Create the stack user
DevStack must run as a non-root user with sudo privileges. Running it as root is not supported and is unsafe. Create a dedicated stack user, give it a home directory under /opt/stack, and allow passwordless sudo so the installation scripts can perform privileged operations without repeated password prompts. If you are setting up SSH access for this user, see our guide on SSH key permissions — overly open keys are a common reason SSH refuses to connect.
Run these commands as root or with sudo:
sudo useradd -s /bin/bash -d /opt/stack -m stack
sudo chmod +x /opt/stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
What to expect: the stack user is created with a home directory, and the sudoers entry lets that user run privileged commands without a password prompt. If you see a permission error here, fix it before proceeding — the rest of the installation depends on it.
Step 2: Switch to the stack user and clone DevStack
Switch to the stack user and clone the DevStack repository from opendev.org. Clone into /opt/stack/devstack because that is the standard location and keeps everything under the stack user’s home.
sudo -u stack -i
git clone https://opendev.org/openstack/devstack.git
cd devstack
The reasoning: running the clone as the stack user ensures all the files it creates are owned by that user, avoiding permission conflicts when stack.sh later writes to the same directories.
Step 3: Create the local.conf configuration file
DevStack is configured through a file called local.conf in the root of the devstack directory. This is where you set passwords, the host IP, and which services to enable. Without it, DevStack prompts interactively or uses defaults that may not match your network.
Create a minimal local.conf like this:
cat << 'EOF' > local.conf
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
HOST_IP=192.168.1.50
EOF
Important details to pay attention to:
- HOST_IP must be the actual IP of your VM’s network interface. If you guess wrong, DevStack may bind services to the wrong address and Horizon becomes unreachable.
- Passwords — replace
secretwith a real, strong password. All four password variables can share the same value for simplicity in a lab. - The
[[local|localrc]]header is required — it is a meta-section that tells DevStack to treat the variables as shell configuration.
local.conf is covered in depth in a separate reference article because this file is where most configuration questions live.
Step 4: Run the installation script
With local.conf in place, run the main installer. This is the step that takes the most time — typically 15 to 30 minutes depending on the machine and internet speed.
./stack.sh
What happens: stack.sh sources stackrc, reads local.conf, clones OpenStack service repositories from git, installs dependencies, configures databases and message queues, and boots Keystone, Glance, Nova, Cinder, Neutron, and Horizon.
When it finishes, stack.sh prints the access credentials and the Horizon URL. Record the ADMIN_PASSWORD you set in local.conf — that is the password you use to log into Horizon as admin.
Accessing Horizon
Once the installation completes, open the dashboard:
- URL:
http://<your-host-ip>/dashboard - Username:
admin - Password: the
ADMIN_PASSWORDvalue from local.conf
If Horizon does not load, the first things to check are whether HOST_IP matches the VM’s actual address and whether any firewall is blocking the port. You can use grep and sed to search DevStack log files for error messages if the installation did not complete cleanly.
Common errors and how to handle them
Permission errors
If you see “Permission denied” when stack.sh tries to write to a directory, confirm you cloned and are running as the stack user. Do not fall back to running the whole installation as root — that is unsupported and creates a mess of file ownership you would have to clean up.
Wrong HOST_IP
If Horizon is unreachable or services bind to the wrong interface, check HOST_IP in local.conf against the output of ip addr. A mismatch here is one of the most common causes of a seemingly “successful” install that is not actually accessible.
Network or clone failures
If git clone fails, verify the VM has internet access and can reach opendev.org. DevStack pulls a lot of data from git repositories, so an unstable connection causes partial or failed installs.
Rebuilding and cleaning up
Because DevStack is disposable, do not try to patch a broken installation. Instead, tear it down and rebuild. DevStack provides an unstack.sh script to stop services, and clean.sh for a more thorough removal. Run those from the devstack directory as the stack user, then re-clone and run stack.sh again if you need a fresh environment.
Why this process works — and where it does not
DevStack’s installation is genuinely fast for what it delivers — a complete OpenStack cloud on one machine from a single command. But “fast” does not mean “casual.” Respect that it modifies the host heavily, and only run it on VMs you are prepared to destroy and recreate. The configuration in local.conf is the part that trips people up most, so treat it carefully rather than copying and pasting blindly.
Related reading
- What is DevStack? — the core concept and how DevStack differs from OpenStack
- DevStack vs OpenStack — deciding whether DevStack is the right tool
- DevStack local.conf explained — configuration options and examples
References
- DevStack documentation — OpenStack — official installation and requirements
- All-In-One Single Machine — DevStack documentation — official single-machine install guide
- openstack/devstack on GitHub — source repository