Your pipelines read the model, not a second copy of it.
Danbyte is a native inventory source, renders configuration with Jinja, notices where a box has drifted from the render, and pushes signed events when something changes. Everything the UI does, the API does.
Inventory your tooling already understands
Danbyte answers as a dynamic inventory for Ansible and as a data source for Terraform, with the groups, variables and config contexts you have defined. No export step, no nightly job copying the estate into a second file that drifts.
- Config contexts
- Layered data attached by site, role, platform, tag or tenant, merged in a defined order.
- Export templates
- Jinja over any object type, for configs, spreadsheets, label sheets or whatever your process wants.
- Custom fields
- Typed fields on any object, in the API, in exports, in filters and in templates.
- Webhooks
- Signed events on change, retried, with the payload you choose.
Render the device, then see where it drifted
Everything modelled, routing included, reaches a device's config template as structured data, so one template renders the whole box in whatever vendor syntax you write. Danbyte renders what is modelled; the template stays yours.
The drift runner compares what a box is actually running against that render and shows the difference, and SNMP discovery compares what the device reports about itself against what you documented.
Code that runs where the data is
Scripts are Python running inside Danbyte as the person who clicked Run, with the ORM and the API in reach. Sandboxed by default, so a script reaches the API and nothing else unless you say otherwise.
Config backups, read from Oxidized
Danbyte does not back up configurations. It reads them from your Oxidized server and shows them where you are already looking: the current config with find, copy and download, the history with its commits, and a diff between any two versions.
Matching is cautious. An ambiguous node links to nothing and says why; a new match for a node seen before is only proposed until somebody confirms it, so a namesake appearing in the inventory cannot silently redirect a device's configuration. Reading a config needs a permission no built-in role has.
Sources that sync themselves
Proxmox, vCenter and Cloud Director sync their clusters, hosts, virtual machines, disks, networks and groups on a schedule, each with its own log of what changed and what it refused to change. Placement rules say where a VM is expected to live, and interface drift is reviewed rather than applied blindly.
An API that is the whole product
Every object type, with filtering, pagination, bulk operations and an OpenAPI schema. Tokens carry a scope and inherit their owner's permissions, so an integration can never see more than the person who created it.
Jobs run in a queue you can watch, plugins add their own models, pages and API routes, and the whole thing works air-gapped.
Questions
- Does Danbyte push configuration to my devices?
- No. It renders from the model and tells you where a device differs. Pushing is your automation's job, which is also where your review and approval already live.
- What can a script reach?
- By default the Danbyte API and nothing else, sandboxed with bubblewrap on top of Landlock. A script that genuinely needs to talk to devices is opted out deliberately.
- Is the API complete?
- Yes. The UI is a client of it, so anything you can do in the browser you can do over REST, with an OpenAPI schema to generate from.
In the documentation
See it with real data.
The live demo is a private instance with a populated estate, yours for thirty minutes. Or install it yourself in a few minutes.