NetBox and Redis: how much of the required backing-service footprint can a low-traffic deployment safely shrink?

Question

I'm planning a NetBox deployment for a low-traffic internal workload and want to keep infrastructure cost minimal. Since NetBox is open-source, the real cost driver is its documented stack: the Django application plus one PostgreSQL database and one Redis instance. I'm trying to decide how far I can consolidate that footprint without breaking supported behavior.

My understanding is that Redis is a hard dependency, used both for caching and for the RQ background task queue (webhooks, reports, custom scripts), so it can't simply be dropped. That leaves consolidation as the main lever: running NetBox, PostgreSQL, and Redis on a single small host, reducing gunicorn worker counts and RQ worker processes, and keeping plugins disabled. But I haven't found documented guidance on where the practical floor is, or whether the interoperability boundary with Redis is strict.

Two points remain unresolved for me. First, managed PostgreSQL and Redis services dominate small-deployment cost, but self-hosting both on the same node removes redundancy — acceptable for a lab, questionable otherwise. Second, Redis-protocol-compatible alternatives (such as Valkey) are not in NetBox's documented support matrix, so substituting one to cut managed-service cost feels unverified and version-sensitive.

Is there any documented minimum or recommended footprint for a low-traffic NetBox instance, or is sizing purely empirical per dataset? Does NetBox officially support Redis-compatible alternatives at the caching/RQ boundary, or only Redis itself? And is co-locating all three components on one host considered a supported topology, or merely a tolerated one?

Tasadduq Burney · Answer

NetBox low-traffic footprint: what can be safely shrunk?

There is no published official minimum server footprint for NetBox; sizing is driven by object count, query volume, and caching load. The following points are confirmed from the available knowledge base:

Redis is a hard dependency: Django caching and the RQ background task queue (webhooks, reports, custom scripts) both require a Redis-compatible store. NetBox does not officially support Valkey or other Redis-protocol alternatives at the caching/RQ boundary.
Co-locating Django, PostgreSQL, and Redis on a single host is not a formally supported topology. It is common for labs and development environments but may introduce resource contention.
Empirical guidance for low-traffic internal use suggests a single VM with approximately 2 vCPU and 4 GB RAM can run NetBox, PostgreSQL, and Redis when gunicorn is limited to 1-2 workers, RQ workers to 1-2 processes, plugins are disabled, and the managed object count stays in the low-thousands.

Likely explanation vs confirmed facts

Confirmed: Redis cannot be dropped; no official alternative is supported. Co-location is tolerated but not endorsed. Sizing above 10k objects or increased concurrent webhook delivery may degrade performance on reduced worker pools.

Likely empirical: A 2 vCPU / 4 GB RAM host is sufficient for low-traffic workloads with a few thousand objects, modest query rates, and Redis memory under 256 MB. Actual limits vary with dataset growth and webhook frequency.

To refine the recommendation, the following detail would help:

Approximate total managed object count (prefixes, VLANs, devices, IP addresses, etc.) and the expected concurrent webhook or report generation rate.

NetBox and Redis: how much of the required backing-service footprint can a low-traffic deployment safely shrink?

1 answer

NetBox low-traffic footprint: what can be safely shrunk?

Likely explanation vs confirmed facts

Your perspective belongs here.

0 question comments