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 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 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:

A way to declare structure — what services exist, how they depend on each other, when they start and stop.
A way to expose them — over the network, behind authentication, with observability built in.
A way to operate — configuration, logging, health, metrics, traces, scheduled work.
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

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 and worked through the quickstart.

Area	When to read
Concepts	Before designing a new Titan-based system
Application	When you start, stop, or supervise an app
Modules	When you organise services into reusable units
Dependency Injection	When you need to control how things are constructed
Decorators	Reference for every decorator the framework ships
Validation	When inputs cross a trust boundary
Errors	When you need typed, classifiable failures
Netron RPC	When you expose services over the network
Configuration	When the runtime needs to read settings
Logging	When you need structured, context-aware logs
Tracing	When you correlate work across services
Resilience	When you defend against partial failure
Testing	When you write fast, deterministic tests
Best Practices	When you want the team to converge on conventions
Modules Catalogue	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.

The 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.