Azure-Samples/chat-with-your-data-solution-accelerator: a RAG accelerator you deploy with azd up
A Solution Accelerator for the RAG pattern running in Azure, using Azure AI Search for retrieval and Azure OpenAI large language models to power ChatGPT-style and Q&A experiences. This includes most common requirements and best practices.
At a glance
- What is it?
- A Microsoft sample that wires Azure AI Search, Azure OpenAI and Azure Container Apps into a citation-backed chat app. It is a starting point for teams already committed to Azure, not a drop-in search product.
- Who is it for?
- Adopt it if your documents already live in Azure Storage and you want a working RAG reference to fork rather than assemble: the deploy-time choice between Azure AI Search with Cosmos DB and PostgreSQL with pgvector, plus the two interchangeable orchestrators, gives you a real decision to make before you commit.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the accelerator actually solves, and for whom
The README frames the problem in organisational terms: contracts, policies, product manuals and benefit guides sit in unstructured form, are slow to search, and are slower to answer questions from. The accelerator indexes that content and puts a chat interface in front of it, so answers arrive with inline citations back to the source documents. That citation behaviour is the point. A plain language model can answer a question about a policy; only retrieval with source links lets a reader check whether the answer is real.
The intended user is a team that has already chosen Azure and wants a reference implementation of retrieval-augmented generation rather than a blank repository. The README describes it as a solution accelerator and a starting point, and it says the deployer is responsible for assessing risks and complying with applicable laws. That is a fair description of the genre: you get the wiring, and you own the evaluation of retrieval quality and answer accuracy against your own corpus.
The runtime shape: Container Apps, Functions and a deploy-time storage choice
The architecture diagram in the README shows three workloads inside an Azure Container Apps environment: a React and Vite single-page app, a FastAPI backend, and an Azure Functions ingestion worker. The browser talks to the backend over /api/* with server-sent events for streaming. The backend calls Azure AI Foundry for models and retrieval, and optionally Content Safety and Speech.
Ingestion is deliberately separate. Uploads land in Azure Storage as blobs and queue messages, and a queue trigger fires the Functions worker, which parses, chunks, embeds and writes to the index. The diagram notes an optional Event Grid path to the same worker. This split is the most interesting design decision in the repository: query traffic never waits behind a document being parsed, and the ingestion worker can be scaled or restarted without touching the chat path.
The retrieval and chat-history store is chosen at deploy time. With databaseType set to cosmosdb, the backend writes to Azure AI Search and keeps chat history in Cosmos DB. With postgresql, a PostgreSQL instance with pgvector holds both the index and the chat history. The Functions worker writes to whichever index was selected. Authorization runs through a single user-assigned managed identity and Azure RBAC, and the README states there is no Key Vault and no application secrets to manage. That is a real operational simplification, and it also means your RBAC role assignments become the thing you must get right.
Deploying it with azd up and taking a first question
The README does not inline the install steps. It points to docs/DeploymentGuide.md as the quick deploy path, and the headline claim is that everything deploys into your own Azure subscription with a single azd up. The repository also offers Codespaces, Dev Containers and VS Code Web entry points from the README badges.
For local work, the root .env.sample is the canonical template. Its header states that every variable name matches the canonical AppSettings field in src/backend/core/settings.py and the corresponding Bicep output in infra/main.bicep, and warns that pydantic-settings ignores unknown variables, so a typo silently does nothing. Copy it to .env, which the file says is gitignored, and fill in the Foundry values:
cp .env.sample .envThe three model settings in that file come with defaults already filled in, so a local run against mocked services needs no edits:
AZURE_OPENAI_GPT_DEPLOYMENT=gpt-5.1
AZURE_OPENAI_EMBEDDING_DEPLOYMENT=text-embedding-3-large
AZURE_OPENAI_API_VERSION=2024-12-01-previewFor real model calls you must set the two Foundry endpoints. The file notes that AZURE_AI_SERVICES_ENDPOINT must be a non-empty https:// URL or PDF and DOCX ingestion fails fast with an actionable error, and that AZURE_AI_PROJECT_ENDPOINT is used by both orchestrators:
AZURE_AI_SERVICES_ENDPOINT=
AZURE_AI_PROJECT_ENDPOINT=Local development uses docker-compose.dev.yml, which the .env.sample header says hard-codes the local stack (azurite plus a pgvector-enabled postgres container) by overriding AZURE_DB_TYPE, AZURE_INDEX_STORE, AZURE_POSTGRES_ENDPOINT, AZURE_STORAGE_BLOB_URL and AZURE_STORAGE_QUEUE_URL on the backend service. Setting those five in .env has no effect on the default profile, only if you override compose. After deployment, the first real use is to upload a document through the admin experience, wait for the Functions worker to finish indexing, then ask a question in the chat interface and check that the answer carries inline citations back to that document.
The Agent Framework pin is a warning about dependency depth
The pyproject.toml carries an unusually candid comment about the Microsoft Agent Framework dependency, and it is worth reading as a signal about how tightly coupled this stack is to a specific Python runtime. The comment explains that the project pins agent-framework-core and agent-framework-foundry directly rather than the agent-framework umbrella meta-package, because the umbrella depends on agent-framework-hyperlight under the environment marker python_version < "3.14", which in turn requires hyperlight-sandbox-backend-wasm. On the Functions host's Python 3.11 runtime that dependency is unresolvable, so a remote pip build backtracks indefinitely and never completes.
That is a concrete failure mode, not a hypothetical. It also tells you the accelerator is tuned for the Azure Functions host rather than for arbitrary environments: requires-python is >=3.11, and the workaround is a deliberate pin that a future release could invalidate. If you fork this and upgrade the agent framework without reading the comment, you may reintroduce the resolution loop.
Where it is the wrong tool
The README's own note is the clearest limitation: this accelerator is a starting point, not a turnkey production system, and the deployer must evaluate retrieval quality, answer accuracy and responsible-AI considerations against their own data. Nothing in the repository promises an accuracy figure or a latency target.
Three narrower cases push you elsewhere. If your documents already live in a vector store that is not Azure AI Search or PostgreSQL with pgvector, the deploy-time databaseType switch does not help you, because those are the two options the architecture diagram shows. If your organisation cannot grant a user-assigned managed identity RBAC roles across Foundry, Search, Storage, Content Safety, Speech and Container Registry, the passwordless design becomes a blocker rather than a convenience, since the README states there is no Key Vault and no application secrets to fall back on. And if you need a supported product with an SLA rather than a sample you maintain, a solution accelerator is the wrong category of artifact regardless of how well it is built.
How it differs from wiring LangChain to a vector store yourself
The obvious alternative is assembling the same pipeline by hand: a framework such as LangChain or LlamaIndex, a vector database, an embedding model and your own API layer. That approach gives you freedom in every component and no opinion about deployment.
The accelerator takes the opposite position. It fixes the deployment target (Azure Container Apps), the identity model (one managed identity plus RBAC), the ingestion runtime (Azure Functions with a queue trigger) and the retrieval store (one of two options chosen at deploy time). In exchange it hands you the parts that are tedious to build: streaming answers with inline citations, a collapsible reasoning panel showing intermediate steps, Content Safety screening on prompts and responses, speech-to-text input, an admin experience for ingesting and configuring datasets and prompts, and optional Microsoft Entra ID sign-in. Notably, the project does not force a single orchestration framework: pyproject.toml lists both langchain and langgraph alongside agent-framework-core, and the README describes Agent Framework and LangGraph as interchangeable orchestrators that share the same retrieval and grounding pipeline and are selected at deploy time. A hand-rolled stack would make you choose one and live with it.
Maintenance, licensing and what an upgrade costs
The repository is MIT licensed, and the top-level entries include LICENSE.md and a separate CDLA-Permissive-2.md, which suggests some bundled data carries a different permissive licence. Check which files that second licence covers before redistributing the data directory; this is a description of the repository layout, not legal advice.
The last push was on 2026-09-09, five days before this writing, and the repository is not archived. The most recent release is v2.0.0 from 2026-07-23, following v1.15.5 in February 2026 and v1.15.4 in December 2025. The jump from 1.15.x to 2.0.0 is a major-version boundary, and the .env.sample header explicitly says there are no v1 aliases and that the old docker/.env.dev.example file was deleted and should not be recreated. If you are carrying a v1 deployment, treat the configuration surface as renamed rather than extended.
Upgrade cost is dominated by dependency pinning. pyproject.toml pins exact versions for fastapi, azure-ai-projects, azure-ai-agents, openai, agent-framework-core and agent-framework-foundry, and package.json carries overrides for esbuild, nanoid, postcss and others. The Makefile is deliberately small and wraps uv, with typecheck running pyright, test running pytest, and lint running black --check and flake8 over src and tests. That gives you a cheap way to detect breakage after a dependency bump, but the Agent Framework comment shows that a bump can fail at install time rather than at test time.
Editorial conclusion
Adopt it if your documents already live in Azure Storage and you want a working RAG reference to fork rather than assemble: the deploy-time choice between Azure AI Search with Cosmos DB and PostgreSQL with pgvector, plus the two interchangeable orchestrators, gives you a real decision to make before you commit. Do not adopt it if you need a hosted product, a non-Azure vector store, or a system that is production-hardened out of the box; the README states plainly that it is a starting point, not a turnkey production system. Before you deploy, verify which databaseType and orchestrator your workload needs, and confirm that the Foundry endpoints in .env.sample match what your subscription actually exposes, because the file itself warns that a typo in a variable name is silently ignored by pydantic-settings.
Frequently asked questions
What is the Azure chat with your data solution accelerator?
It is a Microsoft sample that implements the RAG pattern on Azure, using Azure AI Search for retrieval and Azure OpenAI models for answers. It deploys a React front end, a FastAPI backend and an Azure Functions ingestion worker into your own subscription, and returns answers with inline citations to source documents.
How do I deploy the chat with your data solution accelerator?
The README says the whole solution deploys into your own Azure subscription with a single azd up, and points to docs/DeploymentGuide.md for the quick deploy steps. Codespaces, Dev Containers and VS Code Web entry points are also offered from the README badges.
Which database can the accelerator use for retrieval and chat history?
The choice is made at deploy time. With databaseType set to cosmosdb, the backend reads and writes Azure AI Search and keeps chat history in Cosmos DB; with postgresql, a PostgreSQL instance with pgvector holds both the index and the chat history.
Does the accelerator need API keys or a Key Vault?
No. A single user-assigned managed identity authorizes every downstream call through Azure RBAC, and the README states there is no Key Vault and no application secrets to manage. The trade-off is that the required RBAC role assignments become part of your deployment.
Is the accelerator ready for production use?
The README describes it as a starting point, not a turnkey production system, and places responsibility for assessing risks and evaluating retrieval quality and answer accuracy on the deployer. Treat it as a reference implementation to fork and harden rather than a supported product.
Community notes