> 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/backends/custom-backend/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/backends/custom-backend/python-workers-lower-level) | You need the older `register_model` and `serve_endpoint` path for features the unified backend does not cover yet. |
| [Runtime Containers](/dynamo/dev/backends/custom-backend/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 needs features that are still outside the unified contract, such as multimodal, LoRA adapter management, logprobs, guided decoding, engine-specific routes, or custom request handling.

If your custom engine wants KV-cache-aware routing, also implement [KV Events for Custom Engines](/dynamo/dev/integrations/kv-cache-integrations/kv-events-for-custom-engines) so the Dynamo router can track which workers hold each prefix.