An interactive, single-page visualization of the OneLondon CMDB (Configuration Management Database). It renders services and infrastructure as a pan/zoom SVG dependency graph: click a node to trace its dependencies and dependents, search for a service by name or type, and view full details (repo, docs, pipeline, environments, monitoring, RAG status) in a side panel.
There is no backend — the page reads its data straight from cmdb.yml at runtime.
Live site: https://nhsisl.github.io/OneLondon.ConfigurationManagementDatabase/ — see the User Guide (linked from the site itself too) for how to use it, or CONTRIBUTING.md if you want to add or change a service.
Requires Node.js.
npm install
npm start
Then open http://localhost:8080.
The page must be served over http:// — opening Index.html directly as a file:// URL won't work, because it fetches cmdb.yml at load time and browsers block that under file://. npm start runs a small zero-dependency static server (server.js) for exactly this reason. npm install is needed once, for the yaml package used by the build step below.
To use a different port:
PORT=3000 npm start
Each service or piece of infrastructure is one file under nodes/<type-slug>/<id>.yml — e.g. nodes/azure-function/emis-downloader.yml. This is deliberate: a PR that adds or changes one service touches one small file, not a single shared YAML blob, so concurrent changes from different teams don't collide. Fields:
| Field | Purpose |
|---|---|
id |
Unique, kebab-case, must match the filename. Referenced by other nodes' depends_on lists — this is what defines the graph edges. |
name, type |
Display name and category. type drives the node's legend color and which nodes/<type-slug>/ folder the file lives in. |
repo, documentation, technical_design, deployment_pipeline, iac_repo, iac_deployment |
Links/details shown in the detail panel. |
support_group |
Team responsible for the service. |
rag_status |
Green / Amber / Red — shown as a status dot on the node and in the panel. |
monitoring |
Free-text description of alerting/monitoring in place. |
tags |
Freeform list of strings (optional) — shown as pills in the detail panel, e.g. [pii, tier-1]. |
depends_on |
List of other node ids this service depends on (optional). |
environments.dev/test/prod |
Per-environment resource, url, region. |
To add a service by hand: create nodes/<type-slug>/<id>.yml (type slug = the type value, lowercased with spaces → hyphens). To remove one: delete its file, and remove any depends_on references to it elsewhere. Then run:
npm run build
which runs scripts/build-cmdb.js to regenerate cmdb.yml from the nodes/ files (npm start does this automatically before serving). The script also validates: it fails if an id doesn't match its filename, isn't kebab-case, is duplicated, or a depends_on points at an id that doesn't exist. The same check runs in CI on every pull request that touches nodes/**.
If you introduce a new type value, add a matching color to Component.typeColors in Index.html — otherwise it renders in the fallback grey and won't get its own legend swatch.
Run npm start and use the "+ Add service" link (top of the graph) or the "Edit" link (in a node's detail panel) instead — a form-based UI at add-service.html that writes the right nodes/<type-slug>/<id>.yml file for you. It's local-only by design: those links only appear when server.js's write endpoint responds (checked via ./api/health), and the deployed GitHub Pages site has no server component at all, so nobody can edit the CMDB from the live site — only from a checkout running npm start.
The intended loop: run npm start → add/edit a service via the UI → the resulting nodes/** change appears as a normal file diff → commit, push, open a PR → CI validates it → review and merge → the site redeploys automatically. See CONTRIBUTING.md for the step-by-step version of this.
Node files (and cmdb.yml) are parsed with the standard yaml package, so full YAML is supported — anchors, flow style, multiline scalars, etc. Note that npm run build re-serializes each node's data rather than copying the file text verbatim, so comments and exact formatting in a node file won't appear in cmdb.yml (harmless, since nobody reads cmdb.yml by hand).
cmdb.yml itself is generated and gitignored — never edit it directly, your changes will be overwritten on the next build.
Merges to main trigger .github/workflows/deploy.yml, which builds cmdb.yml from nodes/ and publishes the static site to GitHub Pages.
Index.html the entire app: HTML template + component logic (state, pan/zoom, layout, search)
support.js vendored template-runtime the app is built on (generated — do not hand-edit)
nodes/ CMDB data, one file per node: nodes/<type-slug>/<id>.yml
scripts/build-cmdb.js builds cmdb.yml from nodes/ using the "yaml" package (also the validation run in CI)
cmdb.yml generated from nodes/ by "npm run build" — gitignored, do not hand-edit
add-service.html local-only "+ Add service"/"Edit" form UI — writes to nodes/, never cmdb.yml
user-guide.html end-user guide, deployed alongside the site and linked from its header
server.js static file server for local dev; also serves add-service.html's local-only write API
CONTRIBUTING.md step-by-step guide for adding/editing a service and getting it merged
See CLAUDE.md for a deeper architecture walkthrough if you're making code changes rather than just editing data.