Skip to content
Ambiten Runtime

Context-aware MongoDB execution for multi-tenant systems.

Resolve context once. Execute safely everywhere.

Ambiten turns MongoDB data access into a runtime layer for tenant-aware, transaction-safe, observable applications.

Ambiten is a framework-agnostic data runtime for teams building serious MongoDB systems. Tenant identity, request metadata, transaction scope, provider resolution, middleware, and observability move through the application automatically instead of being manually passed from one service to another.

Context-nativeTenant, request, database, and session state follow execution automatically.
Runtime-safeModels participate in context, middleware, transactions, and provider-based resolution.
Adapter-drivenThe same runtime layer can serve Express, Fastify, NestJS, GraphQL, Lambda, and jobs.
One Runtime Flow

A request enters once. Ambiten carries the execution state through the system.

In many MongoDB applications, the difficult part is not the database call itself. The difficult part is preserving the right execution state around that call: which tenant is active, which request triggered the operation, which database should be used, whether a transaction session exists, which middleware should run, and how the operation should be observed.

Ambiten makes those concerns part of one runtime flow instead of leaving them as repeated plumbing across controllers, services, resolvers, jobs, and model calls.

RequestAdapterAmbitenContextAmbitenModelProviderMongoDB
Supported Runtimes

Choose the adapter that matches where your app runs.

Director Observability

Tenant-aware operations insight for the systems Ambiten powers.

Director is the first premium operations surface for Ambiten. It builds on the telemetry produced by measureQuery and turns runtime activity into operational insight: tenant heatmaps, unscoped query detection, rollback-rate analysis, latency patterns, and the early signals teams need before performance, cloud cost, or support load becomes painful.

This is where Ambiten moves beyond model execution and becomes a foundation for operational governance. The same runtime that carries tenant and request context can also help teams understand how their data layer behaves in production.

Runtime SignalsWhat Director is designed to surface
Tenant pressureIdentify tenants creating unusual query volume, latency, or operational load.
Scope driftDetect operations that execute without tenant, request, or policy context.
Transaction healthObserve rollback patterns, long-running sessions, and runtime failure signals.
tenant-aware telemetryquery instrumentationruntime governance
Runtime observability

Execution-aware logging for context-driven systems.

Ambiten Logger is not a console wrapper. It is a runtime-aware observability layer designed to preserve execution context across requests, transactions, adapters, workers, and distributed application flows.

RequestAmbitenContextTransactionInstrumentationLoggerTransports

Context-aware by design

Logs can automatically inherit request IDs, tenant identity, database targets, collection names, and runtime metadata from the active Ambiten context.

Structured runtime telemetry

Every log is treated as structured execution data, making it easier to search, correlate, route, and analyze across production observability systems.

Resilient transport pipeline

Console, rolling files, async batching, HTTP, Elasticsearch, and Loki transports can be composed with retry and circuit breaker protection.

Why Ambiten Exists

MongoDB applications become fragile when execution rules live everywhere.

Most teams can write CRUD operations. The harder problem appears as the application grows: tenant IDs are passed through too many layers, transactions depend on every nested call remembering the right session, policies are enforced inconsistently, and observability becomes incomplete because the model layer no longer knows enough about the request that triggered it.

Ambiten addresses that problem by treating execution context as infrastructure. Models remain focused on data operations, while the runtime carries the state needed for isolation, consistency, instrumentation, and policy-aware execution.

Runtime Experience
    
    await AmbitenContext.withTransaction(async () => {
      const user = await UserModel.create({
        name: 'Amina',
        email: 'amina@team.io'
      });
  await AuditLogModel.create({
    action: 'USER_CREATED',
    userId: user._id
  });
});

The active tenant, transaction session, request metadata, middleware, and provider resolution are handled by the runtime. Application code stays focused on the workflow instead of repeating infrastructure concerns.

Product Delivery

Keep feature code close to product intent.

Ambiten reduces the amount of infrastructure state that product teams need to carry through every workflow. The result is cleaner application code and fewer places where tenant or transaction handling can drift.

Platform Discipline

Make isolation and consistency enforceable by design.

Multi-tenancy, transaction continuity, middleware, soft delete, auditing, and instrumentation become runtime capabilities rather than conventions every engineer must remember manually.

Runtime Portability

Use one data layer across many execution environments.

Ambiten’s adapter model allows the same models and runtime contracts to work behind REST APIs, GraphQL resolvers, NestJS services, Lambda handlers, and background jobs.

Capability Surface

What Ambiten adds beyond ordinary ODM-style model execution.

Ambiten is not only concerned with how documents are created, read, updated, or deleted. Its value is in the execution environment around those operations: context propagation, provider resolution, lifecycle control, transaction continuity, adapter portability, and operational visibility.

Ambient execution stateTenant, request, database, and session context remain available across async execution.
Adapter portabilityRun the same runtime layer across Express, Fastify, NestJS, GraphQL, Lambda, and jobs.
Lifecycle controlValidation, auditing, soft delete, and policy hooks sit at the schema/model boundary.
Transaction continuityNested operations reuse the active session automatically when running inside a transaction.
Provider-based resolutionModels stay stable while the provider resolves database, client, and session per context.
Operational visibilityLogs and instrumentation can include tenant and request metadata without manual plumbing.

Context-aware execution infrastructure for multi-tenant systems.