Choosing a Deployment Edition

Aivory provides two official Docker Compose deployments. Both run the same product capabilities; the differences lie mainly in infrastructure topology, operational boundaries, and scaling approach, not in the visibility of chat, workspace, knowledge base, or administrator features.

Item	Personal edition	Full edition
Default containers	Only app	app, PostgreSQL, Redis, Qdrant, sandbox, and image keep-alive services
Business data	A single SQLite database	PostgreSQL
Vector retrieval	SQLite embedded vectors, in-process exact retrieval	Qdrant
Cache and queue	In-process	Redis + application queue
Python sandbox	Off by default; optional local profile or external sandbox	Built in by default, but can still be disabled by backend policy
Scaling approach	A single app instance	Suited to running services independently and scaling later
Backup focus	One data directory	A consistent whole-set backup of volumes and data directories
Typical scenarios	Individuals, self-hosted small teams, demos, and low concurrency	Multi-user, long-term production, higher concurrency, organizational deployments

Personal edition boundaries

The Personal edition uses SQLite, SQLite embedded vectors, and in-process caching by default, so there is no need to deploy Redis or Qdrant separately. Vectors remain available; knowledge bases, RAG, persistent files, workspaces, model channels, MCP, and backend administration are not removed.

It should stay single-instance: do not run multiple app replicas at the same time, do not put the SQLite database on a network filesystem such as NFS/SMB, and do not simulate multi-host high availability with a shared database file. The single DATA_DIR is its data root and should be backed up as a whole.

The Personal edition does not use the Docker socket by default and does not pull the two sandbox images. When Python is needed, you can choose a trusted external sandbox, or explicitly enable the local sandbox profile; the latter mounts the Docker socket, and the risks and resource requirements should be accepted by the administrator.

Full edition boundaries

The Full edition splits relational data, cache, vectors, and the sandbox into independent services. The official Compose keeps these services on an internal network; only app is exposed to users or the reverse proxy. It is a better fit for long-term multi-user use, continuous document indexing, more concurrent sessions, and scenarios that require independently backing up PostgreSQL/Qdrant data.

The Full edition also requires more operations: all passwords must be set to distinct random values; PostgreSQL, Redis, Qdrant, the sandbox archive volume, and DATA_DIR must be protected as a single recovery unit; the built-in sandbox needs the Docker socket and should only be used on controlled hosts.

How to choose

Start with the Personal edition if:

• You want the lowest maintenance burden and can accept one machine, one instance.
• The number of users and document scale is currently limited.
• You do not need to share Redis, Qdrant, or sandbox workspaces across multiple app replicas.
• You are willing to include the entire data directory in backups.

Choose the Full edition directly if:

• This is a long-term service for real users, or you already have multiple administrators and ongoing operational needs.
• You need clearer isolation and recovery boundaries for the database, cache, and vector services.
• You expect higher concurrency, more users, more RAG documents, or more complex statistics, payments, and permission management.
• You can take responsibility for the secure operation of multiple persistent services and the built-in sandbox.

Migrating from the Personal edition to the Full edition

We do not recommend copying a live SQLite file directly into a Full edition container, and never let two deployments write to the same data directory at the same time. The correct process is:

1. Create the latest complete backup in the Personal edition admin backend, and separately copy the entire DATA_DIR.
2. On a new host or separate directory, start an empty Full edition and complete its health checks first.
3. Restore using the backup import feature in the admin backend, and handle file and vector data as prompted.
4. Verify administrator login, normal conversations, attachments, knowledge base retrieval, workspaces, and any needed Python features.
5. Do not decommission or delete the old instance until data integrity is confirmed.

For the complete update, restore, and rollback procedures, see Upgrade, Backup, and Restore.