AtlasRAG

AtlasRAG is a customer-managed RAG-as-a-Service platform. Each customer organization owns projects and isolated RAG instances; each instance has its own documents, chunks, endpoint, lifecycle, usage, and audit trail. A separate platform-management plane manages customers and sees the global fleet.

The current release is a working local vertical slice:

• persistent SQLite storage for local development;
• password login, persistent users, built-in roles and permissions;
• signed customer and platform sessions;
• customer organization onboarding;
• projects and development/staging/production RAG instances;
• instance-scoped document ingestion and semantic chunking;
• tenant-, instance-, ACL-, and metadata-filtered hybrid retrieval;
• grounded responses with citations and trace IDs;
• customer usage and audit history;
• customer suspension enforced across data operations;
• separate customer and platform-management APIs and browser panels.

The target commercial platform and the honest implementation matrix are in Platform architecture and Implementation status.

Run locally

Prerequisites: Python 3.11 or newer.

python -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[dev]"
Copy-Item .env.example .env
python scripts/seed_demo.py
python -m uvicorn atlasrag.main:app --reload

seed_demo.py prints the demo login accounts. Open:

• Customer panel: http://localhost:8000/panel/
• Management panel: http://localhost:8000/management/
• OpenAPI: http://localhost:8000/docs

Log in with one of the printed accounts. The seed contains two isolated customers, customer owner/builder/viewer roles, platform administrator/support roles, projects, RAG instances, and example policies.

Before login, each URL renders only its portal-specific sign-in screen. The application shell is natively hidden until a protected API verifies the saved session. After login, navigation and actions are filtered by permissions: customer roles never receive platform-management navigation, read-only roles do not receive mutation controls, and platform-support users cannot perform customer-management writes.

Default examples:

Portal	Account	Password	Role
Customer	owner@demo.local	DemoOwner123!	owner
Customer	builder@demo.local	DemoBuilder123!	builder
Customer	viewer@demo.local	DemoViewer123!	viewer
Customer	owner@acme.local	AcmeOwner123!	second isolated customer
Management	admin@atlasrag.local	PlatformAdmin123!	platform administrator
Management	support@atlasrag.local	PlatformSupport123!	read-only support

Local data persists in data/atlasrag.db. To start with a clean local database, stop the application and remove that file deliberately. Do not use the SQLite adapter as a production database.

Development tokens

Normal users should log in through /auth/login. The following utility exists only for API testing and recovery during local development:

python scripts/create_dev_token.py `
  --tenant customer-acme `
  --subject owner-1 `
  --roles owner

Create a platform-management token:

python scripts/create_dev_token.py `
  --tenant platform `
  --subject operator-1 `
  --roles platform_admin

Production must replace local password/JWT identity with the documented OIDC and enterprise IAM path, managed secrets, refresh/revocation controls, and the PostgreSQL tenant-isolation adapter.

Customer workflow

1. Log in to /panel/ with a customer account.
2. Configure the customer organization if it has not been bootstrapped.
3. Create a project.
4. Provision a RAG instance for development, staging, or production.
5. Index text into that instance.
6. Query the instance in the playground.
7. Inspect usage and the audit trail.

Knowledge operations use nested instance endpoints:

POST /v1/rag-instances/{instance_id}/documents
GET  /v1/rag-instances/{instance_id}/documents
POST /v1/rag-instances/{instance_id}/query

There is no implicit global customer knowledge base.

Platform-management workflow

Open /management/ with a platform account. Operators can:

• view global customer, instance, document, and query totals;
• provision customer organizations;
• list all customers and RAG instances;
• suspend and reactivate customers with a required audited reason.

Customer tokens cannot call /management/v1/*.

See the full software and PaaS gap analysis for every missing production service identified in the code review.

Quality and validation

python -m ruff check .
python -m mypy src
python -m pytest
docker compose -f deploy/compose.yaml config --quiet

Tests cover persistence, customer lifecycle, cross-tenant instance isolation, signed group ACLs, metadata filters, usage, audit, management separation, and customer suspension.

Deployment boundary

The Helm, Terraform, Compose, and target architecture assets describe the production evolution to PostgreSQL/pgvector, OpenSearch, object storage, event workers, OIDC, billing, connectors, model providers, and dedicated deployment tiers. Features not present in the implementation matrix are not claimed as working in this release.

License

Apache-2.0. See LICENSE.