# OpenStack Horizon: Django dashboard for cloud administration

> OpenStack Horizon is the web dashboard and reusable Django framework for administering OpenStack services. It suits operators who need a browser interface, but its Python 3.11 requirement and extensive service dependencies make deployment more involved than a standalone application.

**openstack/horizon** — OpenStack Dashboard (Horizon). Mirror of code maintained at opendev.org.

- Repository: https://github.com/openstack/horizon
- Website: https://opendev.org/openstack/horizon
- Stars: 1,409 · Forks: 1,248
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/openstack-horizon

## Horizon's role in an OpenStack deployment

OpenStack Horizon addresses a specific gap in a distributed cloud platform: many OpenStack projects expose APIs, command-line clients, and service-specific interfaces, but operators still need a shared web console for routine administration. Horizon supplies that console as a Django project and also offers reusable components for building additional dashboards. Its intended users are OpenStack system administrators and the technical staff who support them, rather than application developers looking for a general-purpose Python web framework.

The repository separates those two roles. The `horizon` package provides the reusable dashboard framework, `openstack_auth` handles authentication-related application code, and `openstack_dashboard` acts as the reference Django site. The top-level `manage.py`, combined with `openstack_dashboard`, gives operators an assembled dashboard rather than a collection of components they must wire together from scratch.

Horizon is a console for an existing OpenStack environment. The README does not say that it creates compute instances, stores objects, or manages identity on its own. Those actions depend on connections to the corresponding OpenStack services. That distinction matters during evaluation: installing the dashboard does not provision an OpenStack cloud, and a useful Horizon deployment still needs the underlying services and their APIs to be available.

## Django, OpenStack clients, and dashboard components

The implementation is a Django-based web application backed by Python client libraries. The dependency list names `Django>=4.2`, `openstacksdk>=4.5.0`, and service-specific packages including `python-cinderclient`, `python-glanceclient`, `python-keystoneclient`, `python-novaclient`, and `python-swiftclient`. This indicates a server-side flow in which Django views receive browser requests, interact with OpenStack APIs through client libraries, and render dashboard pages.

The packages shown in `pyproject.toml` are `horizon`, `openstack_auth`, and `openstack_dashboard`. That arrangement supports a separation between reusable application code and the deployable reference implementation. The README describes `openstack_dashboard` as a reference Django site that uses the `horizon` app for web-based interactions with OpenStack projects.

Horizon also contains a frontend build and test system. `package.json` describes Angular-related assets and defines scripts for ESLint and Karma. Its test script runs Karma once for both `horizon/karma.conf.js` and `openstack_dashboard/karma.conf.js`. The lint command covers static directories under `openstack_dashboard`, `horizon`, and dashboard packages. This is more than a pure Python codebase. Asset compilation, JavaScript linting, browser tests, policy configuration, and Django settings are all part of its operational surface.

The dependency file contains lower bounds with an explicit warning that the maintainers do not test every bound for correctness. That warning limits how confidently the declared minimum versions can be treated as a verified compatibility matrix. Operators should use the installation and release documentation for their selected OpenStack release rather than assume that the lowest listed versions form a tested set.

## Installing Horizon against an existing OpenStack cloud

The README does not provide a self-contained installation command sequence. It directs users to `doc/source/install/index.rst` and the Horizon Installation Guide for deployment steps, detailed settings, and configuration. Consequently, there is no documented `pip install` or server invocation command to reproduce from the repository information alone.

The confirmed packaging metadata describes Horizon as a Python 3 project requiring Python 3.11 or later. The listed classifiers include Python 3.11, 3.12, 3.13, and 3.14. A first deployment should begin by selecting a supported Python environment and following the versioned installation guide rather than copying package lower bounds into an ad hoc environment.

The repository can perform one documented local verification. Its documentation build uses tox:

```bash
$ tox -e docs
```

The README states that generated results appear in `doc/build/html`. This verifies the documentation environment rather than a running dashboard. For the first real use, follow the official installation guide, open the deployed dashboard through the procedure it specifies, authenticate against the configured OpenStack identity environment, and confirm that the services exposed by selected dashboard panels can be reached. The README does not state a default URL, port, login command, or service-selection settings, so those values should not be guessed.

## Authentication, policies, and deployment boundaries

Horizon depends on `openstack_auth` and includes `oslo.policy`, `keystoneauth1`, and Keystone client dependencies in its package metadata. These entries show that authentication and authorization are part of the application boundary, not optional details that can be ignored when placing Horizon behind a web server. The repository does not document a particular policy file, default login role, reverse-proxy setting, secret-store integration, or session configuration.

That omission limits claims about production configuration. A dashboard can be technically started and still be unusable if its identity endpoint, service catalog, user permissions, or policy rules do not match the OpenStack deployment. A correctly authenticated user may see only the panels permitted by policy. Evaluators need to distinguish a Horizon rendering problem from an identity, policy, service endpoint, or reverse-proxy problem before changing dashboard code.

The architecture also creates a wider trust surface than a small internal utility. Browser users interact with a Django application that then uses privileged service clients to communicate with multiple OpenStack APIs. The repository files confirm this multi-service direction, but they do not document a complete threat model or a set of reference web-server settings. Those controls must be established through the deployment guide and the organization's existing OpenStack security configuration. The README points contributors to documentation in `doc/source`, which is the documented place for the detailed configuration model.

## Limits for small deployments and direct automation

Horizon is the wrong choice when the requirement is a single-purpose client with a small runtime. Its package set includes Django, authentication libraries, policy support, localization tools, profiling support, image processing, multiple service clients, and frontend tooling. The Python requirement is also explicit. Versions below 3.11 do not satisfy the package metadata. In a locked-down environment that cannot host that runtime or its dependency set, a lighter client may be easier to support.

It is also unsuitable as the sole source of administrative truth. The repository supplies dashboard code and a reference site, not replacements for the APIs and client tools belonging to individual OpenStack projects. An administrator who needs an action that Horizon does not expose would still need another supported interface. The README does not claim that every API operation is represented in the web interface, so the dashboard should not be treated as a complete substitute for service-level automation.

A second limitation is release visibility on this mirror. The repository is not archived and its last push was on 2026-10-15. That indicates recent code activity, but it does not define an upgrade cadence or guarantee compatibility with every adjacent OpenStack service. There are no GitHub releases associated with this repository. Horizon's README points release management to Launchpad and release notes to the OpenStack documentation. Operators therefore need to check those sources to identify the deployed version. A recent push does not, by itself, tell an administrator which release has been packaged for a particular cloud.

## Direct OpenStack clients versus the Horizon interface

The practical alternative is to administer OpenStack through service-specific Python clients or other direct API tooling instead of Horizon. The repository itself names `python-cinderclient`, `python-glanceclient`, `python-keystoneclient`, `python-novaclient`, and `python-swiftclient` as dependencies. Those clients represent the service-oriented route. Code or commands target a particular OpenStack service, with authentication and permissions handled through its client configuration.

Horizon adds a shared browser interface and reusable dashboard components on top of that service layer. This is useful for interactive administration across multiple projects, especially when operators do not want to assemble separate interfaces for identity, compute, block storage, image, and object resources. It also gives organizations a base for custom dashboards built from Horizon components.

The direct-client approach has a different tradeoff. It can avoid running Django, frontend assets, web-server configuration, browser sessions, and dashboard policies. It is also closer to service APIs and easier to embed in existing automation. Horizon is more appropriate when shared visual administration matters more than minimizing the runtime. The service clients are the better starting point for narrowly scoped scripts or environments where adding a web console would create more operational work than user value.

## Maintenance, licensing, and upgrade work

The repository is not archived, and the last push was on 2026-10-15. That supports treating the project as recently changed, but it does not define an upgrade cadence or guarantee compatibility with every adjacent OpenStack service. There are no GitHub releases associated with this repository. Horizon's README points release management to Launchpad and release notes to the OpenStack documentation, so version selection should follow those project-specific sources.

An upgrade can touch more than the Python package. Changes may involve Django requirements, service client lower bounds, authentication and policy behavior, localized assets, Angular dependencies, Karma tests, ESLint rules, and deployment configuration. The repository's separation into Python packages, JavaScript assets, documentation, tests, and integration-test configuration reflects that broader upgrade surface. Organizations that customize dashboards should also account for any local code built against `horizon` APIs, although the repository files do not document a compatibility policy for third-party panels.

Horizon and its metadata use Apache-2.0. The dependency file identifies a mixture of Apache-2.0, BSD, MIT, PIL, and SIL OFL 1.1 components. The project's own permissive license does not remove the need to review the licenses and notices of deployed dependencies. This is a compliance inventory point, not legal advice. Operators should inspect the exact dependency set resolved in their environment rather than assuming every transitive component carries the Horizon license.

## Conclusion

Horizon is appropriate for OpenStack operators who want a maintained, browser-based administration layer and can support its Django deployment, frontend assets, authentication configuration, and service dependencies. It is a poor fit for a minimal administration tool or an environment limited to Python versions below 3.11. Before adoption, verify the installation guide for the intended OpenStack release, confirm that each service client matches the deployed services, and review the dashboard policies and configuration relevant to your users.

## FAQ

### What is OpenStack Horizon used for?

OpenStack Horizon is a Django-based web dashboard for interacting with multiple OpenStack projects. The `openstack_dashboard` package provides a reference site built on the reusable `horizon` app.

### What Python version does OpenStack Horizon require?

The package metadata requires Python 3.11 or later. Its classifiers list Python 3.11, 3.12, 3.13, and 3.14.

### How do I install and start OpenStack Horizon?

The README directs users to `doc/source/install/index.rst` and the Horizon Installation Guide. It does not provide a complete install or startup command sequence, default URL, or default port.

## Sources

- [Issues](https://github.com/openstack/horizon/issues)
- [License: Apache-2.0](https://github.com/openstack/horizon/blob/master/LICENSE)
- [openstack/horizon on GitHub](https://github.com/openstack/horizon)
- [Project website](https://opendev.org/openstack/horizon)
- [README](https://github.com/openstack/horizon/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openstack-horizon