Layered Device Configuration with NetBox Config Contexts
NetBox config contexts let you attach JSON data to devices, sites, roles, and tags. This guide walks through creating weighted contexts, assigning them, and retrieving the final merged configuration via the UI and REST API.
05 Jul 2026, 03:38 UTC

Desired Outcome
Centralize per‑device configuration data in NetBox so that automation scripts can pull a single, fully resolved JSON object that reflects global defaults, site‑specific overrides, and device‑role exceptions.
Prerequisites
- NetBox 3.0 or newer, running and accessible over HTTPS.
- Administrative or “Manage Config Contexts” permission on the NetBox instance.
- Existing objects to target: at least one Site, one Device Role, and one Tag (optional).
- An API token with scope
extras.config_contexts.readanddcim.devices.readif you plan to use the REST API.
Creating a Base Config Context
- Navigate to Extras > Config Contexts in the NetBox UI.
- Click Create to open the context form.
- Fill in a Name that describes the purpose – e.g.,
Global‑SNMP‑Defaults. - Paste valid JSON into the Data field. For a global SNMP community string and NTP server:
{ "snmp_community": "public", "ntp_server": "10.0.0.1" } - Set the Weight to
10(lower numbers are overridden by higher ones). - Under Assignments, choose All Devices to make the context apply everywhere.
- Click Create. The UI will validate the JSON; any syntax error will be shown as a form error.
Adding Site‑Specific Overrides
- Repeat the steps above to create a new context named
London‑NTP‑Override. - Use the following JSON to change the NTP server for London devices:
{ "ntp_server": "10.50.0.5" } - Set Weight to
20. - Assign it to the Site object named London.
- Save the context.
Defining a Device‑Role Exception
- Create a context called
Core‑Switch‑Timeout. - JSON payload:
{ "domain_timeout": 60 } - Weight:
100. - Assign to the Device Role named Core‑Switch.
- Save.
Verifying the Merge in the UI
Open any device that falls under all three contexts – for example, a core switch in London. In the device detail page, the Config Context section will display the merged JSON:
{
"snmp_community": "public",
"ntp_server": "10.50.0.5",
"domain_timeout": 60
}
Notice that the NTP server comes from the site context (weight 20) and the timeout from the role context (weight 100). The global SNMP community remains unchanged because no higher‑weight context overrides it.
Fetching the Resolved Context via the REST API
Use the device‑specific endpoint to let NetBox perform the merge:
curl -s -H "Authorization: Token YOUR_API_TOKEN" \
https://netbox.example.com/api/dcim/devices/123/config-context/
Replace 123 with the device ID. The response body will contain a single data object with the merged JSON. Example output:
{
"data": {
"snmp_community": "public",
"ntp_server": "10.50.0.5",
"domain_timeout": 60
}
}
When the JSON in any context is invalid, the API returns a 400 Bad Request with details, and the UI will block saving the context.
Audit and Rollback
All context changes are recorded in the NetBox change log. To revert a mistaken value:
- Navigate to the context’s Change Log tab.
- Find the event you want to undo and copy the Data snapshot.
- Edit the context and paste the older JSON.
- Alternatively, delete the context via the API:
curl -s -X DELETE \ -H "Authorization: Token YOUR_API_TOKEN" \ https://netbox.example.com/api/extras/config-contexts/42/
Common Pitfalls and Safeguards
- Do not store plain‑text secrets in config contexts. Use NetBox Secrets with an encrypted backend instead.
- Missing target objects (e.g., a non‑existent site) will silently ignore the context; double‑check assignments before saving.
- Concurrent edits can cause lost updates. Check the change log for recent edits and use optimistic locking if available.
Practical Check‑List
- JSON is valid – try
jq .locally before pasting. - Weight values are intentional – higher numbers win.
- Assignments match existing objects – use the UI picker to avoid typos.
- After creation, verify the merged output in both UI and API.
- Document the context hierarchy in your configuration management repo for future reference.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.