> For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://docs.nvidia.com/dynamo/llms.txt. For full content including API reference and SDK examples, see https://docs.nvidia.com/dynamo/llms-full.txt.

# Custom Backend Overview

Dynamo supports custom backends through one preferred unified contract, a
lower-level worker path, and a packaging path:

| Path | Use when |
| --- | --- |
| [Writing Unified Backends](/dynamo/dev/advanced-customizations/writing-custom-backends/writing-unified-backends) | You are writing a new token-in-token-out engine in Python or Rust and want Dynamo to own the runtime lifecycle. |
| [Python Workers (lower-level)](/dynamo/dev/advanced-customizations/writing-custom-backends/writing-python-workers) | You need direct control of `register_model`, `serve_endpoint`, or the request payload. |
| [Runtime Containers](/dynamo/dev/advanced-customizations/writing-custom-backends/runtime-containers) | You need to package a built-in or custom backend into a deployable Dynamo image. |

The unified backend path is the preferred starting point for new custom engines.
It gives Python and Rust backends the same lifecycle shape: parse arguments,
start the engine, stream generated chunks, handle cancellation, drain, and clean
up. The Dynamo framework owns runtime registration, signal handling, model
registration, and graceful shutdown.

Use the lower-level Python worker path when your backend must own model
registration, endpoint serving, request handling, or lifecycle behavior.

If your custom engine uses KV-aware routing, [publish KV events](/dynamo/dev/advanced-customizations/writing-custom-backends/publish-kv-events)
so the Dynamo router can track which workers hold each prefix.