starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 05:50:33 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Configure NetBox via Environment Variables #3902

New Issue
Closed
opened 2025-12-29 18:31:53 +01:00 by adam · 3 comments
adam commented 2025-12-29 18:31:53 +01:00
Owner
Copy Link

Originally created by @dgarros on GitHub (Jul 27, 2020).

Environment

  • Python version: 3.7.7
  • NetBox version: 2.8.8

Proposed Functionality

Allow users to define some or all elements in the configuration.py via predefined environment variables.

The users would have the option to define some parameters using the current method in the configuration file or via environment variables. If something is defined in the configuration.py it will take precedence on the environment variable.

See below some examples and proposal of how it could look like


SECRET_KEY = ''   # >> Proposed Env Variable NETBOX_SECRET_KEY

ALLOWED_URL_SCHEMES = (
    'file', 'ftp', 'ftps', 'http', 'https', 'irc', 'mailto', 'sftp', 'ssh', 'tel', 'telnet', 'tftp', 'vnc', 'xmpp',
). # >> Proposed Env Variable NETBOX_ALLOWED_URL_SCHEMES with values in comma separated format

BANNER_TOP = ''    >> Proposed Env Variable NETBOX_BANNER_ TOP
BANNER_BOTTOM = ''   >> Proposed Env Variable NETBOX_BANNER_BOTTOM

DATABASE = {
    'NAME': 'netbox',         # Database name. >> Proposed Env Variable NETBOX_DATABASE_NAME
    'USER': '',               # PostgreSQL username.  >> Proposed Env Variable NETBOX_DATABASE_USER
    'PASSWORD': '',           # PostgreSQL password >> Proposed Env Variable NETBOX_DATABASE_PASSWORD
    'HOST': 'localhost',      # Database server >> Proposed Env Variable NETBOX_DATABASE_HOST
    'PORT': '',               # Database port (leave blank for default)   >> Proposed Env Variable NETBOX_DATABASE_PORT
    'CONN_MAX_AGE': 300,      # Max database connection age.  >> Proposed Env Variable NETBOX_DATABASE_CONN_MAX_AGE
}

Use Case

Using environment variables to configure an application is a popular solution as it allow users to manage different versions of an application without generating a configuration file for each one of them. Grafana is a good example of application that supports environment variables for almost all elements in the configuration file Grafana doc

I've seen several NetBox deployment using Environment Variables in a similar way than what netbox-docker is doing. Currently it's up to each user to implement that in the configuration.py. This feature will help to keep the configuration.py file shorter for some users and it could remove the need to create a configuration.py in some cases.

Database Changes

No change in the database

External Dependencies

No external dependency required but it might be worth looking at django-environ to help, will need further investigation.

Originally created by @dgarros on GitHub (Jul 27, 2020). ### Environment * Python version: 3.7.7 * NetBox version: 2.8.8 ### Proposed Functionality Allow users to define some or all elements in the `configuration.py` via predefined environment variables. The users would have the option to define some parameters using the current method in the configuration file or via environment variables. If something is defined in the `configuration.py` it will take precedence on the environment variable. See below some examples and proposal of how it could look like ```python SECRET_KEY = '' # >> Proposed Env Variable NETBOX_SECRET_KEY ALLOWED_URL_SCHEMES = ( 'file', 'ftp', 'ftps', 'http', 'https', 'irc', 'mailto', 'sftp', 'ssh', 'tel', 'telnet', 'tftp', 'vnc', 'xmpp', ). # >> Proposed Env Variable NETBOX_ALLOWED_URL_SCHEMES with values in comma separated format BANNER_TOP = '' >> Proposed Env Variable NETBOX_BANNER_ TOP BANNER_BOTTOM = '' >> Proposed Env Variable NETBOX_BANNER_BOTTOM DATABASE = { 'NAME': 'netbox', # Database name. >> Proposed Env Variable NETBOX_DATABASE_NAME 'USER': '', # PostgreSQL username. >> Proposed Env Variable NETBOX_DATABASE_USER 'PASSWORD': '', # PostgreSQL password >> Proposed Env Variable NETBOX_DATABASE_PASSWORD 'HOST': 'localhost', # Database server >> Proposed Env Variable NETBOX_DATABASE_HOST 'PORT': '', # Database port (leave blank for default) >> Proposed Env Variable NETBOX_DATABASE_PORT 'CONN_MAX_AGE': 300, # Max database connection age. >> Proposed Env Variable NETBOX_DATABASE_CONN_MAX_AGE } ``` ### Use Case Using environment variables to configure an application is a popular solution as it allow users to manage different versions of an application without generating a configuration file for each one of them. Grafana is a good example of application that supports environment variables for almost all elements in the configuration file [Grafana doc](https://grafana.com/docs/grafana/latest/administration/configuration/#configure-with-environment-variables) I've seen several NetBox deployment using Environment Variables in a similar way than what [netbox-docker](https://github.com/netbox-community/netbox-docker/blob/release/configuration/configuration.py) is doing. Currently it's up to each user to implement that in the `configuration.py`. This feature will help to keep the configuration.py file shorter for some users and it could remove the need to create a `configuration.py` in some cases. ### Database Changes No change in the database ### External Dependencies No external dependency required but it might be worth looking at [django-environ](https://github.com/joke2k/django-environ) to help, will need further investigation.
adam added the type: feature label 2025-12-29 18:31:53 +01:00
adam closed this issue 2025-12-29 18:31:53 +01:00
adam commented 2025-12-29 18:31:53 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Jul 27, 2020):

How about setting up your config file to load environment variables using os.getenv ? You can import os at the beginning of the config file, and then set the various settings through os.getenv. The config file is in python anyways.

This would result in a less opinionated, more tailored result for your use case anyways.

@jsenecal commented on GitHub (Jul 27, 2020): How about setting up your config file to load environment variables using [`os.getenv`](https://docs.python.org/3/library/os.html#os.getenv) ? You can `import os` at the beginning of the config file, and then set the various settings through `os.getenv`. The config file is in python anyways. This would result in a less opinionated, more tailored result for your use case anyways.
adam commented 2025-12-29 18:31:54 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Jul 27, 2020):

@jsenecal That's the route I've gone, adding distutils.util.strtobool as well.

@tyler-8 commented on GitHub (Jul 27, 2020): @jsenecal That's the route I've gone, adding `distutils.util.strtobool` as well.
adam commented 2025-12-29 18:31:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2020):

I'm going to pass on this, for three reasons:

  1. As the folks above point out, there's nothing preventing a user from doing this currently.
  2. Supporting this natively would entail hard-coding a barrage of environment variables (NetBox currently accepts over 50 configuration parameters) and forcing users to populate their environment with whatever specific variables we choose. Even if we prefix each variable with e.g. NETBOX_, this is forcing the user's hand in a domain outside the scope of Netbox itself. Better to let the user retain full control over how variables are named and imported.
  3. Supporting both file-based and environment-based configuration parameters in parallel forces us to prefer one over the other, and introduces the opportunity for user frustration where both are defined.
@jeremystretch commented on GitHub (Jul 28, 2020): I'm going to pass on this, for three reasons: 1. As the folks above point out, there's nothing preventing a user from doing this currently. 2. Supporting this natively would entail hard-coding a barrage of environment variables (NetBox currently accepts over 50 configuration parameters) and forcing users to populate their environment with whatever specific variables we choose. Even if we prefix each variable with e.g. `NETBOX_`, this is forcing the user's hand in a domain outside the scope of Netbox itself. Better to let the user retain full control over how variables are named and imported. 3. Supporting both file-based and environment-based configuration parameters in parallel forces us to prefer one over the other, and introduces the opportunity for user frustration where both are defined.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3902
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?