---
id: "titan/overview"
title: "Titan Framework"
description: "A composable TypeScript backend framework — DI, lifecycle, validation, and a transport-agnostic RPC plane."
---

# Titan Framework

Titan is **the backend framework**. It runs standalone — no
daemon, no supervisor, no extra runtime. Build a backend with
Titan + the modules you need, then `node dist/main.js`. That's
the entire production deploy.

> **Titan is self-sufficient.** [Omnitron](/docs/omnitron/overview)
> is a separate opt-in layer on top — useful for multi-app fleets,
> web console, declarative infra provisioning, MCP server for AI
> agents. For a single backend service you don't need it. See
> [Titan vs Omnitron](/docs/foundations/titan-vs-omnitron) for
> the precise boundary.

It is intentionally small at its core and large at its surface —
a focused application kernel plus a deep catalogue of opt-in
modules.

## What Titan is

A backend framework gives you four things you would otherwise build by hand:

1. **A way to declare structure** — what services exist, how they depend on
   each other, when they start and stop.
2. **A way to expose them** — over the network, behind authentication,
   with observability built in.
3. **A way to operate** — configuration, logging, health, metrics,
   traces, scheduled work.
4. **A way to recover** — typed errors, graceful shutdown, retries,
   circuit breakers, locks.

Titan provides all four with a deliberately minimal core (the
`Application`, the `Container`, the `Lifecycle`) and a library of modules
that compose into the runtime you actually want.

## What Titan is not

- **Not a "do everything" runtime.** Modules are independently versioned
  packages. You can run a Titan app with one of them.
- **Not opinion-free.** Titan has strong opinions about explicitness:
  declared providers and explicit lifecycle ownership. Request context
  uses AsyncLocalStorage where the transport and authentication APIs require it.
- **Not a NestJS clone.** Titan shares the decorator-driven aesthetic
  with NestJS, but the underlying container (Nexus) is a different
  design — multi-token providers, contextual injection, middleware
  pipelines, runtime-portable across Node/Bun/Deno/browser.

## The mental model

```mermaid
flowchart TB
  subgraph App["Application (kernel)"]
    Bootstrap[Bootstrap]
    Container[Nexus DI Container]
    Lifecycle[Lifecycle State Machine]
    Events[Application Event Bus]
  end

  subgraph Modules["Your modules + ecosystem modules"]
    UserMod[User Modules]
    Auth[titan-auth]
    DB[titan-database]
    Cache[titan-cache]
    Etc[…]
  end

  subgraph Netron["Netron RPC Plane"]
    Services[Your @Service classes]
    Transports[HTTP / WS / TCP / Unix]
    Auth2[Authn + Authz]
    Middleware[Middleware Stack]
  end

  Bootstrap --> Container
  Container --> Modules
  Container --> Services
  Lifecycle --> Modules
  Modules --> Container
  Services --> Transports
  Auth2 --> Middleware
  Middleware --> Services
```

The Application kernel owns the container, the lifecycle, and the event
bus. Modules register providers in the container. Services are providers
that also register themselves with Netron. Netron exposes them over
transports. Middleware wraps every call.

That is it. Everything else — the optional ecosystem modules, the validation
decorators, the resilience helpers — is built on top of these four
primitives.

## What this section covers

This is the reference section for Titan itself. It is dense, technical,
and assumes you have read the
[introduction](/docs/intro) and worked through the
[quickstart](/docs/getting-started/quickstart).

| Area                                                              | When to read                                        |
| ----------------------------------------------------------------- | --------------------------------------------------- |
| [Concepts](/docs/titan/concepts/design-principles)                | Before designing a new Titan-based system           |
| [Application](/docs/titan/application/bootstrap)                  | When you start, stop, or supervise an app           |
| [Modules](/docs/titan/modules-system/defining-modules)            | When you organise services into reusable units      |
| [Dependency Injection](/docs/titan/di/overview)                   | When you need to control how things are constructed |
| [Decorators](/docs/titan/decorators)                              | Reference for every decorator the framework ships   |
| [Validation](/docs/titan/validation/overview)                     | When inputs cross a trust boundary                  |
| [Errors](/docs/titan/errors/overview)                             | When you need typed, classifiable failures          |
| [Netron RPC](/docs/titan/netron)                                  | When you expose services over the network           |
| [Configuration](/docs/titan/configuration/overview)               | When the runtime needs to read settings             |
| [Logging](/docs/titan/logging/overview)                           | When you need structured, context-aware logs        |
| [Tracing](/docs/titan/tracing)                                    | When you correlate work across services             |
| [Resilience](/docs/titan/resilience/overview)                     | When you defend against partial failure             |
| [Testing](/docs/titan/testing/overview)                           | When you write fast, deterministic tests            |
| [Best Practices](/docs/titan/best-practices/structuring-services) | When you want the team to converge on conventions   |
| [Modules Catalogue](/docs/titan/modules)                          | Public modules and their integrations               |

## Versioning and public boundaries

Titan is pre-1.0. Use declared package entry points, pin versions and verify
upgrades against the contracts your application consumes. A minor release
can change a public contract. See [compatibility](/docs/reference/compatibility).

The [API index](/docs/reference/api-index) derives import paths from package
manifests and symbols from TypeScript exports. Source files that are not
reachable through those entry points are implementation details. A source
annotation alone does not make an arbitrary deep import supported.

Read on: [Design Principles](/docs/titan/concepts/design-principles).