allegro/ralph: a Django-based CMDB and DCIM for data center and back office hardware

What problem Ralph solves, and for whom

Ralph is an asset management, DCIM and CMDB system aimed at organizations that own physical hardware and need a single record of it. The README lists four capabilities: tracking asset purchases and their life cycle, a flexible flow system for that life cycle, support for both data center and back office equipment, and built-in data center visualization. That combination is narrower than a general IT service management suite. It is about the physical and contractual facts of a machine: when it was bought, where it sits, what state it is in, and who is responsible for it at each step.

The audience is therefore infrastructure and operations teams in companies large enough to have a real data center footprint or a substantial back office estate, and small enough that a commercial CMDB is hard to justify. Allegro built it for its own environment, which is why the feature list reads like a description of an operator's daily problems rather than a product brochure. The repository description calls it the CMDB and Asset Management system for data center and back office hardware, and the setup.py description adds the word advanced.

One thing to settle early: this is not a monitoring system and not a configuration management tool in the Ansible or Puppet sense. Nothing in the README claims Ralph pushes configuration to machines or observes them. It is a system of record. If your actual problem is drift detection on running servers, Ralph is the wrong layer.

The Django architecture behind the asset model

The repository layout makes the architecture clear enough without running anything. Source lives under src/, the project is packaged with setuptools through pyproject.toml and setup.py, and the dependency list in pyproject.toml is a Django stack: django~=4.2.0, djangorestframework==3.15.0, django-filter, django-import-export, django-reversion, django-mptt, django-taggit, django-money, django-rq and django-redis. That is a conventional Django application with a REST API layer, revision history, hierarchical categories and a background job queue.

Storage is not fixed to one engine. The dependency list contains both mysqlclient and psycopg, and the repository root carries mise.ci-mysql.toml and mise.ci-psql.toml, which indicates continuous integration is run against MySQL and PostgreSQL. Redis appears through django-redis and hiredis, so a Redis instance is part of the expected deployment. django-rq implies asynchronous work is dispatched to workers rather than done inside the request.

Several dependencies point at the operational context Ralph was written for. openstacksdk, keystoneauth1, python-glanceclient and oslo.* packages indicate integration with OpenStack. pyhermes suggests publishing events to a Hermes-style message broker. django-auth-ldap indicates directory-based authentication. django-prometheus exposes metrics. django-reversion keeps a history of changes to records, which matters when an asset's state is a compliance question rather than a convenience.

The front end is built separately. package.json declares version 3.0.0 and requires Node >=22.0.0, with gulp, gulp-sass and bower in the dependency list. So a full deployment has a Python side and a Node side, and the build pipeline in gulpfile.js produces the static assets.

Installation and a first usable record

The README does not contain installation steps. It points to the documentation at ralph-ng.readthedocs.org and to a live demo at ralph-demo.allegro.tech with the credentials ralph and ralph. Anything below is therefore about what the repository files declare, not a walkthrough the project publishes.

What the packaging does tell you is the interpreter floor. setup.py asserts Python 3.10 or newer, and the assertion is a hard failure at build time rather than a warning.

assert sys.version_info >= (3, 10), "Python 3.10+ required."

The same file defines the console entry points, which is how the application is meant to be started. There are separate commands for production, development and test runs, plus a validator.

entry_points={
    "console_scripts": [
        "ralph = ralph.__main__:prod",
        "dev_ralph = ralph.__main__:dev",
        "test_ralph = ralph.__main__:test",
        "validate_ralph = ralph.cross_validator.__main__:main",
    ],
}

Dependencies are split into groups in pyproject.toml rather than a single flat list, so a development install and a production install pull different sets. The prod group contains gunicorn, and the dev group contains django-debug-toolbar, django-silk, ipython and ruff.

[dependency-groups]
prod = [
  "gunicorn==23.0.0"
]
dev = [
  "coverage",
  "django-cors-headers>=3.11.0",
  "django-debug-toolbar>=1.11",
  "django-silk",
  "ipdb",
  "ipython",
]

The static front end is a separate build. package.json pins the Node floor and the asset toolchain, so a deployment that skips this step will have an application shell without its compiled styles and scripts.

{
  "name": "ralph",
  "version": "3.0.0",
  "engines": {
    "node": ">=22.0.0"
  }
}

For a first real use, the honest answer is that the project directs you to the demo instance to see the data model before you deploy anything. Creating an asset record, moving it through a life cycle transition and then looking at it on the data center visualization is the sequence the screenshots in the README illustrate. The README does not document how to seed a fresh database, so plan on reading the readthedocs documentation for that step.

Sources only: what the maintenance model actually means

The most consequential paragraph in the README is the February 2025 update. Allegro states it will maintain development under a sources only model, without guarantees, and that it is not operating under a contribution-based model. It welcomes discussion but does not guarantee responses to issues or support for pull requests. Commercial support is directed to the Discourse forum at ralph.discourse.group.

That is a clear boundary and it should drive the adoption decision more than any feature comparison. The code is published, the licence permits use, and the last push to the default branch ng was on 2026-09-28, with releases 20260902.1, 20260831.2 and 20260831.1 published in the weeks before. So the project is being worked on. What is absent is a commitment to answer you. A team that needs a vendor to acknowledge a severity-one bug within a contracted window is not the intended user, regardless of how well the data model fits.

The stated goal in that update is modernization and long-term maintainability, with investment during 2025. Read that as a project that is being kept alive and improved by its originator for its originator's needs, with the source opened alongside. The dependencies support that reading in a mixed way: django-auth-ldap is pinned with a compatible-release operator, django-reversion likewise, but several packages are pinned exactly, including Babel==2.11.0, Faker==0.9.0 and cmd2==2.7.0. Exact pins make upgrades predictable and make dependency conflicts harder to resolve when you need a newer version of something.

Where Ralph is the wrong tool

The clearest failure mode is expecting support. The README says it plainly, and teams routinely skim past that paragraph because the feature list looks like a product. If your procurement process requires a support contract with response times, Ralph does not offer one through the repository.

The second limitation is deployment weight. Ralph is a Django application with a relational database, Redis, a background worker via django-rq, a Node build step for static assets, and optional integrations with OpenStack, LDAP and a message broker. That is a real stack to operate. A small team that wants to record which laptop belongs to which employee will spend more time on the deployment than on the inventory.

The third is scope. Ralph models hardware life cycle, purchases and physical placement. It does not model software licences, service catalogues or incident management, and nothing in the README claims it does. If the CMDB you need is primarily about application dependencies and service ownership, Ralph's schema is oriented elsewhere.

Finally, the documentation gap is real. The README gives a demo login and a link to readthedocs, and stops there. There are no install commands, no upgrade notes, no rollback procedure, and no statement about supported database versions. Those are the questions you will actually have on day two, and the README does not answer them.

How Ralph differs from NetBox

The natural comparison is NetBox, the other widely used open source DCIM. The difference in approach is visible in the dependency list. Ralph is a Django application with a full asset life cycle engine: django-reversion for change history, django-money for purchase values, django-import-export for bulk data movement, and a flow system the README describes as flexible, which implies transitions between asset states are configurable rather than fixed. Its centre of gravity is the asset record and what happens to it over time, including the financial and purchasing side.

NetBox is oriented around the network and infrastructure model: sites, racks, devices, prefixes, IP addresses, VLANs and circuits, with a strong emphasis on being the source of truth for network automation. Its data model is built so that other systems can read from it.

If your problem is tracking a purchase order, a warranty date and the approval chain that moves a server from ordered to installed to decommissioned, Ralph's model is closer. If your problem is knowing which prefix is free and which interface is connected to which port, NetBox's model is closer. Neither README claim makes one a superset of the other, and the choice usually comes down to which half of the estate is currently undocumented. Ralph's OpenStack dependencies also suggest it was designed to reconcile with a cloud control plane, which is a different integration target from NetBox's network automation ecosystem.

Licence and the cost of staying current

Ralph is released under Apache-2.0, which the README states and the LICENSE file confirms. The licence permits commercial use, modification and redistribution, and it includes an explicit patent grant and a patent retaliation clause. It does not require you to publish your modifications. The NOTICE and AUTHORS files at the repository root are the attribution artifacts the licence expects you to preserve. This is a description of the licence text, not legal advice; if your organization has specific obligations around attribution in distributed products, have counsel read the LICENSE and NOTICE.

The practical cost is upgrade work. The project pins many dependencies exactly, and the Django version is specified as django~=4.2.0, which allows patch releases within the 4.2 series but not a jump to 5.x. When you need a newer version of a pinned library for an unrelated reason, you are resolving that conflict yourself, and the sources-only model means no one upstream is obligated to help. The release cadence visible in the recent tags, three releases within about a month, suggests frequent small updates rather than long-lived stable branches. Track the tags and read the diff before upgrading rather than assuming a release is maintenance only.

Editorial conclusion

Ralph fits organizations that already run Django and PostgreSQL and need an inventory with a configurable life cycle rather than a hosted service. It does not fit teams that need vendor support with response times, because Allegro states it operates sources only and does not guarantee replies to issues or pull requests. Before committing, verify the database backend you intend to use against requirements/ and confirm how the ralph console script is meant to be started in your environment, since the README points to readthedocs rather than giving deployment steps.

Frequently asked questions

Official sources

1. allegro/ralph on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases