Local development
Use local storage and local services while building modules and testing runtime behavior.
Deployment patterns
The same runtime shape can start local and move outward.
Democr.ai supports local development, desktop runtime, server mode, and distributed provider setups through configuration rather than feature rewrites.
Modes
Deployment mode changes the providers, not the module contract.
A module should not care whether storage, media, queues, or model providers are local or remote.
Localflow stage
Desktopflow stage
Serverflow stage
Distributedflow stage
Desktop runtime
Qt desktop can run against the same core concepts while keeping UI responsiveness separate from background services.
Server deployment
Web clients connect to a server process with configured storage, media, engine, and knowledge providers.
Provider movement
Infrastructure can move out one concern at a time.
The platform is designed so a local-first setup can evolve toward shared services when needed.
Storage
SQLite can move to Postgres-compatible storage where shared access is required.
Queues
In-memory coordination can move toward Redis or database-backed queues for multi-worker deployments.
Knowledge
Local vector and graph providers can be replaced by Milvus, Neo4j, or compatible backends.
Distributed direction
Queues and workers are the next natural scaling boundary.
Long-running ingestion and model work should be consumable by multiple workers without making one process a bottleneck.
Engine workers
Model runtimes can run in separate processes that hold provider state and model memory.
Knowledge workers
Extraction, embedding, and graph work can be processed asynchronously from ingestion queues.
Configurable backends
Queue storage can move toward database-backed or Redis-backed implementations depending on deployment size.
Next
Related pages
Use these pages to move from the concept to adjacent parts of the runtime.