AI Real Estate Assistant: a RAG property search stack you can self-host
Open-source AI real estate search with RAG, vector search, multi-provider LLMs, FastAPI, Next.js, ChromaDB, and a live demo.
At a glance
- What is it?
- AleksNeStu/ai-real-estate-assistant pairs a FastAPI backend and a Next.js front end with ChromaDB vector search and a 13-provider LLM factory. The interesting part is not the chatbot, it is the Render-specific lazy-loading gate documented in the README.
- Who is it for?
- Adopt it if you want a working reference for grounded property search over your own listings and you are willing to run the Docker demo scripts and swap the seeded data for your own. Do not adopt it if you need a maintained data pipeline or a hosted product, because the push cadence is dominated by README and badge fixes and the live demo serves simulated AI responses.
- 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
The query shape this project was built around
The README opens with a single example: a natural language request such as "2-bedroom apartment in Kraków under 500k" returning matched listings. That phrasing is the whole design brief. It is a structured filter (city, bedroom count, price ceiling) expressed as a sentence, and the project's job is to recover the filter and then rank the survivors. Anyone building a property portal already has the filter half. What they usually lack is a retrieval layer that tolerates loose phrasing and a conversational wrapper that keeps context across turns. This repository supplies both, plus the surrounding product surface: mortgage calculator, rent-vs-buy comparison, ROI and TCO calculators, clustered map markers, and nine interface languages (English, Polish, Russian, German, Spanish, Italian, Portuguese, Turkish, Ukrainian). The audience is therefore a developer or small team standing up a property search product, not an end user shopping for a flat.
How the retrieval and provider layers are wired
Two mechanisms are visible in the material. The first is vector search backed by ChromaDB, which is what makes the natural language example work: listings are embedded and queried by similarity rather than by exact keyword. The README lists ChromaDB among the topics and the tech stack but does not print the embedding model, the collection name, or the chunking strategy, so treat those as things to read out of the source before you plan an index rebuild. The second is a provider factory at apps/api/models/provider_factory.py that imports thirteen LLM providers. On a normal host all thirteen are imported eagerly at startup, giving a memory baseline of roughly 530 MB. When the RENDER environment variable is set to "true", the factory switches to lazy loading: only the active DEFAULT_PROVIDER (documented as zai) is imported at startup and the remaining twelve load on first use, which brings the baseline to roughly 480 MB. That is the architecture in one sentence: a FastAPI service in front of ChromaDB, with the model backend selected at runtime by configuration rather than by code change. The README is explicit that the lazy path is a workaround for Render's 512 MB free-tier cap and "not a best practice for memory-constrained production deployments in general".
Getting a local instance up with the demo scripts
The README's local path is PowerShell, not shell. Step one runs .\scripts\demo\01-launch-docker.ps1 and is quoted at 5 to 8 minutes for the containers. Step two runs .\scripts\demo\02-generate-data.ps1 and is quoted at 2 to 3 minutes. After that the front end answers on http://localhost:3082, the backend on http://localhost:8082, and the OpenAPI docs on http://localhost:8082/docs. Teardown is .\scripts\demo\03-stop-docker.ps1, and the README points to scripts/demo/README.md for troubleshooting. The generator seeds 250 or more properties across Kraków, Warsaw, Gdańsk, Wrocław and Poznań, plus 50 users, 100 saved searches, 200 favorites, 15 agent profiles, 150 leads, 300 activity events, 40 preference profiles and 20 CMA reports. That dataset is the thing to plan around. It is Polish-market shaped and demo shaped, so the first real work on a fork is replacing it with your own inventory and rebuilding the vector index. The configuration surface you will touch is small: DEFAULT_PROVIDER selects the active model backend, and RENDER=true forces the lazy import path on a host that is not Render. If you are on a VPS, Docker, Fly.io, Railway or App Runner, the README says to do nothing and take the eager path, but it also advises a plan with at least 1 GB of RAM for safety.
The 512 MB workaround is the most honest part of the repo
Most projects hide this kind of thing. Here it is a table in the README with a memory number per platform and a flat statement that the lazy path is not a general recommendation. The trade-off is real and worth naming: lazy loading buys you roughly 50 MB of headroom at the cost of a first-request latency spike when a non-default provider is touched, and it makes startup behaviour depend on an environment variable that Render sets automatically on every service. That means a bug that only reproduces with RENDER=true will not reproduce in CI, because the README states tests assume the eager path. If you fork this and deploy elsewhere, you inherit a code path your test suite never exercises. The other limitation is the demo itself. The README notes that the live demo "uses simulated AI responses for instant exploration" and that production deployment requires API keys. So the hosted URL is a UI tour, not a retrieval benchmark. Nothing in the supplied material tells you how well the vector search ranks real listings, and no evaluation harness is described.
Where a dedicated search engine fits better
If your listings already live in PostgreSQL, the honest alternative is Postgres with pgvector and a SQL WHERE clause for the structured filters, rather than a separate ChromaDB instance. The difference in approach is where the constraint lives. Here, city and price ceiling are recovered from the sentence by the model and the ranking comes from vector similarity. With pgvector, the price ceiling is a column comparison the planner can index and the embedding only orders the rows that survive it. That is cheaper to operate, gives you exact filter semantics for free, and removes one service from the compose file. The counter-argument is real too: the conversational layer and the nine-language UI are the parts you would have to write yourself, and they are the bulk of this repository. Pick ChromaDB when you want the chat-first experience and your filters are fuzzy; pick pgvector when your filters are contractual and the sentence is just a convenience.
Licence, maintenance and what the release history says
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; if you plan to ship a closed product on top of this, have a lawyer read the LICENSE file rather than this paragraph. Maintenance is the softer question. The last push recorded is 2026-09-09 and the default branch is dev, so the branch you clone by default is not the one the CI badge points at (that badge references main). The three most recent releases, v5.1.2 through v5.1.4, are all dated 2026-08-15 and their notes describe a Star-History chart fix, a revert of a broken hosted embed, and removal of a Note from the README. That is documentation and badge churn, not retrieval work. It does not mean the project is abandoned, but it does mean you should read the commit log on dev rather than the release list if you want to know what changed in the search path. Upgrading between these point releases looks low risk precisely because the diffs are cosmetic; the risk sits in the unversioned state of the vector index and the demo dataset.
Editorial conclusion
Adopt it if you want a working reference for grounded property search over your own listings and you are willing to run the Docker demo scripts and swap the seeded data for your own. Do not adopt it if you need a maintained data pipeline or a hosted product, because the push cadence is dominated by README and badge fixes and the live demo serves simulated AI responses. Before committing, verify three things: that the provider factory in apps/api/models/provider_factory.py exposes the provider you actually intend to use, that the ChromaDB collection can be rebuilt from your own listings rather than the 250 seeded Polish properties, and that your host has at least 1 GB of RAM if RENDER is not set to true.
Community notes