Open runtime for production AI applications

Build governed AI applications, not just AI demos.

Democr.ai is an open, self-hostable Python runtime for AI software: server-driven UI, tools, document ingestion, model orchestration, sandbox policy, quotas, audit trails, and local-to-cluster deployment.

See A2UI in action Read the architecture GitHub

For developers building AI features

Build modules in Python and YAML while the runtime handles UI effects, provider access, storage, tasks, and document context.

For platform teams standardizing AI

Give teams one boundary for engines, extractors, tools, quotas, observability, and single-node or clustered orchestration.

For organizations that need control

Keep AI execution inspectable with sandbox policy, scoped data, token/request limits, and correlated audit evidence.

The problem

The model is not the application.

The first demo usually proves that the model can help. The hard part is everything around it: UI state, tools, documents, identity, permissions, model routing, cost control, deployment, and evidence that explains what happened.

The UI changes while the agent works

Agents need to stream text, progress, choices, forms, tables, and actions. Democr.ai makes UI a server-driven protocol, not a custom frontend rewrite for every workflow.

A2UI YAML layouts multi-client

Documents become governed context

Uploads flow through configured extractors into markdown, chunks, metadata, vector search, and graph context without losing scope.

extractors knowledge scope

Models need routing and limits

Application code asks for a model, objective, or capability. The runtime resolves providers, enforces quotas, and can place work across a cluster.

engines quotas cluster

Extensions need a real boundary

Modules, engines, extractors, tools, agents, and skills use SDK contracts instead of private core internals, with sandbox policy around runtime access.

SDK boundary sandbox policy

Every important step should be visible

Actions, tasks, tool calls, model calls, ingestion state, and data mutations can be correlated into inspectable execution flows.

audit events traceability

Deployment should evolve without rewrites

Start local with SQLite and local services. Move storage, media, queues, model execution, and observability outward by configuration.

local-first distributed providers

What it is

An application runtime around AI, not a model wrapper.

Democr.ai is the layer that binds product code, UI, model execution, documents, policy, and observability into one coherent system. Clients render. Modules own behavior. The runtime carries context and governance.

Clients Qt desktop, web, Tauri, React variants, mobile-oriented client
Core runtime Routing, auth, SDK context, tasks, effects, observability
Extensions Modules, engines, extractors, tools, agents, skills
Providers Storage, media, vector, graph, audit, local or cloud AI
Sandbox policy Quota checks Request correlation Single-node or cluster orchestration

Module authoring

Feature code stays small because the runtime owns the plumbing.

A module defines models, YAML UI, actions, tools, agents, and skills. It does not need to own frontend state management, direct model loading, media transport, or knowledge indexing.

modules/chat/utils/ui/yaml/index.yaml layout 
- kind: Row
  id: chat_page
  stretch: true
  children:
    - kind: ThreadList
      id: chat_thread_list
      action:
        name: chat.open_thread
    - kind: MessageList
      id: chat_message_list
      capabilities:
        - messages.append
        - messages.replace
    - kind: Composer
      id: chat_composer
      send_action:
        name: chat.start_thread
        context:
          composer: chat_composer
modules/chat/actions/conversation.py behavior 
@action("submit_message")
@permission_required(["chat.write"])
async def submit_message(ctx, session, module_sdk):
    turn = create_user_turn(module_sdk, ctx)
    stream_id = ctx["stream_id"]

    await module_sdk.effects.publish(
        stream_id,
        module_sdk.effects.ui_collection_append(
            "chat_message_list",
            "messages",
            message_row(turn["message"]),
        ),
    )

    await run_chat_orchestration(
        module_sdk,
        ctx,
        turn["conversation"],
        turn["message"],
    )

Local to distributed

Start with local providers, move services out by configuration.

Democr.ai is local-first, but the same runtime shape can point to external infrastructure when a deployment needs shared services or distributed workers.

Capability Local setup Distributed setup
Relational storage SQLite for core and module data Postgres or compatible managed database
Media Local filesystem storage S3-compatible object storage and optional public delivery endpoint
Knowledge graph Ladybug local graph store Neo4j-compatible graph backend
Vector retrieval sqlite-vec Milvus or Pinecone-style vector providers, certification varies by provider
Runtime coordination Local gRPC/IPC services and in-memory response streams Redis streams, queue-backed engine invocation, node-aware workers
Engine governance Configured model defaults and local context guards Token/request quotas by user, role, organization, guest, or global scope
Observability SQLite-backed event and audit storage Postgres, ClickHouse, and optional OTLP export, certification varies by provider

Data and state

SQLite PostgreSQL Redis

Knowledge and vectors

Ladybug Neo4j SQLite Milvus sqlite-vec

Media and observability

S3-compatible ClickHouse OTLP

Provider logos show implementation targets, not certification status. Pinecone and ClickHouse are implemented but still require validation through the current integration pass.

See implemented engines See ingestion pipeline Read configuration overview

Use cases

Where Democr.ai fits best.

Democr.ai is strongest when AI is not a side panel, but part of an application with users, state, permissions, documents, model choices, and operational accountability.

Internal AI copilots

Back-office workflows where agents need forms, actions, document context, permissions, and audit.

Document-heavy products

Applications that ingest files, preserve extracted content, retrieve scoped knowledge, and expose status.

Self-hosted AI platforms

Teams that need local and remote providers, pluggable storage, sandbox policy, quotas, and logs.

Multi-client AI tools

One backend UI definition rendered across desktop, web, Tauri, React variants, and mobile-oriented clients.

AI extension ecosystems

Products where modules, tools, agents, engines, and extractors should be installable but bounded.

Controlled enterprise deployments

Environments where AI usage must be inspectable, rate-limited, scoped, and deployable on chosen infrastructure.

Positioning

Use the pieces you already like. Stop rebuilding the application layer around them.

Democr.ai does not replace model providers, databases, or frontend frameworks as isolated tools. It provides the runtime contract that makes those choices usable inside governed AI applications.

Not only

A model router

It includes engines, but also UI, modules, tools, documents, storage, tasks, quotas, and audit.

Not only

A chat UI

A2UI renders structured application surfaces and effects across clients from backend contracts.

Not only

A RAG layer

Knowledge ingestion is part of a larger runtime with scoping, extraction status, and application context.

Instead

An open AI application runtime

A self-hostable foundation for teams that want AI features to remain understandable and governable.

Project status

Built for developers who want agentic apps to remain inspectable.

Democr.ai is an active open-source runtime. The goal is not to hide complexity behind generated application code, but to put the common layers around agentic software in one place so feature modules stay understandable.

Architecture overview A2UI protocol Knowledge runtime