Skip to main content
Version: 0.10.x [Latest Beta]

Configuration

This page covers the runtime settings that matter most in deployments.

Environment variables at a glance​

VariablePurposeDefault
DENKFLOW_DATA_DIRECTORYPersistent SDK state, caches, and runtime dependencies.platform-default
DENKFLOW_DEPENDENCY_IMPORT_DIRECTORYAdditional directory searched for .denkdependency archives.current working directory
DENKFLOW_FORCE_MANAGED_DEPSIgnore compatible system provider runtimes and use managed dependencies.unset
DENKFLOW_USE_EXISTING_DEPSUse existing dependency trees without installing, importing, repairing, or verifying them.unset
DENKFLOW_NONINTERACTIVEForce auto-confirm of runtime dependency downloads/terms (same behaviour as when stdin is not a TTY).unset
ORT_DYLIB_PATHAdvanced override for an intentionally supplied ONNX Runtime build.managed by SDK
DENKFLOW_ENABLE_ORT_LOGSEnable provider-level ONNX Runtime logging.unset (disabled)

DENKFLOW_DATA_DIRECTORY​

DENKFLOW_DATA_DIRECTORY controls where the SDK stores persistent data such as:

  • offline license state
  • TensorRT engine cache
  • OpenVINO cache files
  • managed ONNX Runtime 1.22.1
  • verified CUDA, TensorRT, DirectML, OpenVINO, barcode, and Ambarella runtime dependencies
  • other runtime metadata

Default location​

PlatformDefault location
Linux$XDG_CONFIG_HOME/denkflow or $HOME/.config/denkflow
macOS$HOME/Library/Application Support/denkflow
Windows%APPDATA%/Roaming/denkflow

Docker​

You do not need to set DENKFLOW_DATA_DIRECTORY in the container if you mount a host directory onto the SDK default path inside the image (for example -v /srv/denkflow-data:/root/.config/denkflow when the process runs as root inside the docker, matching $HOME/.config/denkflow). Setting DENKFLOW_DATA_DIRECTORY is only necessary when you want data stored somewhere other than that default.

The mount must survive container replacement. Otherwise ONNX Runtime and any managed provider dependencies are downloaded again, offline license state is lost, and accelerator caches are rebuilt.

Linux example​

export DENKFLOW_DATA_DIRECTORY=/opt/denkflow-data
mkdir -p "$DENKFLOW_DATA_DIRECTORY"

Windows example​

$env:DENKFLOW_DATA_DIRECTORY = "C:\ProgramData\denkflow"
New-Item -ItemType Directory -Force -Path $env:DENKFLOW_DATA_DIRECTORY

DENKFLOW_DEPENDENCY_IMPORT_DIRECTORY​

The SDK searches both <data dir>/dependencies/ and an additional import directory for .denkdependency archives. The additional directory defaults to the process current working directory. Set this variable when archives are mounted or staged elsewhere:

export DENKFLOW_DEPENDENCY_IMPORT_DIRECTORY=/opt/denkflow-imports

Imported archives remain in their source directory. Their verified contents are still extracted into the managed <data dir>/dependencies/ tree.

DENKFLOW_FORCE_MANAGED_DEPS​

Set this variable to ignore compatible system CUDA, TensorRT, DirectML, and OpenVINO installations and use the release-pinned managed dependency instead:

export DENKFLOW_FORCE_MANAGED_DEPS=1

This can recover from a system installation that passes version detection but fails when a session is created. ONNX Runtime is always managed regardless of this setting.

DENKFLOW_USE_EXISTING_DEPS​

This advanced escape hatch leaves dependency trees untouched:

export DENKFLOW_USE_EXISTING_DEPS=1

For each dependency, the SDK first uses an existing managed subdirectory without checking its version, hashes, or manifest.db records. If that directory does not exist, it accepts a compatible system installation. If neither exists, dependency resolution continues without installing anything and session creation may fail later.

Use this only for controlled testing or hand-placed runtime trees. It disables dependency installation, local archive import, repair, and verification.

ORT_DYLIB_PATH​

Normally the SDK downloads its pinned ONNX Runtime 1.22.1 under <data dir>/dependencies/onnxruntime/ and configures the shared-library path automatically. Do not set ORT_DYLIB_PATH in standard Python, C-API, or container deployments.

It remains an advanced override for intentionally supplying a custom ONNX Runtime build:

export ORT_DYLIB_PATH=/path/to/libonnxruntime.so
$env:ORT_DYLIB_PATH = "C:\path\to\onnxruntime.dll"

Custom ONNX Runtime builds can be incompatible with the CUDA, TensorRT, DirectML, or OpenVINO versions supported by DENKflow 0.10. If the standard managed runtime cannot be found, repair or import the matching dependency instead of pointing this variable at an arbitrary library.

DENKFLOW_NONINTERACTIVE​

The first pipeline initialization can require a Hub download. Interactive terminals show the applicable terms and one combined download confirmation. Set the variable for unattended services, CI, or containers:

export DENKFLOW_NONINTERACTIVE=1

Non-interactive mode accepts the configured terms and download prompt; it does not provide network access or credentials. For an offline deployment, put the required .denkdependency archives in <data dir>/dependencies/ or the dependency import directory.

Logging​

SDK logs​

import denkflow
denkflow.set_log_level("DEBUG")

The available log levels are (ordered by increasing verbosity): ERROR, WARN, INFO, DEBUG, and TRACE.

ONNX runtime logs​

Enable ONNX Runtime logs if you need provider-level diagnostics:

export DENKFLOW_ENABLE_ORT_LOGS=true

Persistence in containers​

Mount a persistent host directory onto the SDK default data directory inside the container (on Linux, typically /root/.config/denkflow when running as root, i.e. the same path as $HOME/.config/denkflow). That preserves managed runtime dependencies, offline license state, TensorRT engines, and OpenVINO caches without setting DENKFLOW_DATA_DIRECTORY. Alternatively, mount your host directory anywhere you like and set DENKFLOW_DATA_DIRECTORY to that path inside the container.

Also pass /etc/machine-id through for stable licensing and authentication.

See Docker Deployment for full examples.