# AI Real Estate Assistant: A Self-Hosted RAG Stack for Property Search > AleksNeStu/ai-real-estate-assistant is an MIT-licensed Python and Next.js monorepo that turns natural-language property queries into vector search results. It is a developer platform, not a hosted product, and the README is explicit about which parts are simulated. **AleksNeStu/ai-real-estate-assistant** — Open-source AI real estate search with RAG, vector search, multi-provider LLMs, FastAPI, Next.js, ChromaDB, and a live demo. - Repository: https://github.com/AleksNeStu/ai-real-estate-assistant - Website: https://realestate-web-dz1y.onrender.com/ - Stars: 311 · Forks: 116 - Language: Python - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/aleksnestu-ai-real-estate-assistant ## The Query-to-Listing Gap This Project Fills Property portals are built around filter forms. Bedrooms, price ceiling, district, floor area. That works when a buyer already knows what they want, and fails when the request arrives as a sentence: the README's own example is "2-bedroom apartment in Kraków under 500k". Translating that into structured filters is the whole problem, and it is the problem this repository addresses. The intended audience is developers, not agents. The repository ships as a monorepo with apps/api and apps/web, a Makefile, a Playwright config, k8s manifests and a deploy directory. There is no plugin for an existing CRM and no embeddable widget. If you want a drop-in assistant for a listing site you already run, this is a codebase to read and borrow from, not a service to switch on. One detail is worth flagging early. The live demo at realestate-web-dz1y.onrender.com runs in demo mode, and the README states plainly that it "uses simulated AI responses for instant exploration" and that a production deployment requires API keys. Anyone evaluating the demo as evidence of answer quality is evaluating a mock. ## How the RAG Pipeline and Provider Factory Fit Together The stack is conventional for retrieval-augmented generation, which is a point in its favour. FastAPI serves the API, ChromaDB holds the vectors, and the LLM layer sits behind a provider abstraction. The README lists 13 providers, selected through a DEFAULT_PROVIDER environment variable whose documented values include openai, anthropic, google, xai, deepseek, openrouter, zai, moonshot, opencode and ollama. Ollama matters here: it is the local-inference option, so the pipeline can run without a paid external API. The more interesting mechanism is in apps/api/models/provider_factory.py. Provider imports are conditional on the RENDER environment variable. When RENDER is set to "true", only the active DEFAULT_PROVIDER (documented as zai) is imported at startup and the other twelve load on first use. Otherwise all thirteen are imported eagerly. The README frames this as a workaround for Render's free-tier 512 MB memory cap and states directly that the lazy path "is not a best practice for memory-constrained production deployments in general". That is an unusually candid note, and it should be read as a warning rather than a feature. Around the core search there are financial tools (mortgage calculator, rent-versus-buy comparison, ROI and TCO calculators), clustered map markers, and a v5.1 addition that puts a monthly payment estimate on each listing card. The README gives the defaults for that estimate: 20% down, 30-year fixed, 6.5% APR, and notes it is not a lending offer. ## Installing It Locally and Running a First Search The README offers two paths. The quickest is the demo scripts, which the README says launch Docker containers in 5 to 8 minutes and generate demo data in 2 to 3 minutes. Note the platform: the examples are PowerShell. ```bash .\scripts\demo\01-launch-docker.ps1 .\scripts\demo\02-generate-data.ps1 ``` After those two commands the README says the frontend is at http://localhost:3082, the backend at http://localhost:8082, and API docs at http://localhost:8082/docs. The generated dataset is documented as 250+ properties across Kraków, Warsaw, Gdańsk, Wrocław and Poznań, plus users, saved searches, favorites, agent profiles, leads, activity events, preference profiles and CMA reports. To stop everything, the third script is 03-stop-docker.ps1. The second path is the root package.json scripts, which start both halves of the monorepo together. ```bash npm run dev ``` That runs the web app and, separately, uvicorn on api.main:app with --reload on host 0.0.0.0 port 8000. Before any of it starts, copy .env.example to .env. The file marks ENVIRONMENT and API_ACCESS_KEY as required, with the key generated by: ```bash openssl rand -hex 32 ``` At least one provider key is required for real answers. If you have no paid key, set DEFAULT_PROVIDER to ollama and point it at a local model; the README lists ollama among the accepted values. If you set nothing, expect the simulated responses the demo uses. ## The Memory Ceiling and Other Sharp Edges The provider factory is the clearest limitation. On Render's free tier the backend baseline is documented at roughly 480 MB against a 512 MB cap, which leaves very little headroom. On a VPS, Docker or bare metal the eager path is documented at roughly 530 MB, and the README advises picking a plan with at least 1 GB of RAM on other PaaS platforms. A 512 MB instance is not a safe target, and the lazy-loading trick exists precisely because the eager path does not fit there. There is a second-order cost. Lazy loading means the first request that touches a non-default provider pays the import. The README does not quantify that latency, and it does not document a warm-up step, so if you rely on a provider other than the default on Render, measure the cold path yourself. Demo mode is the other trap. It is genuinely useful for exploring the UI without keys, and the README is honest that responses are simulated. The risk is organisational: a stakeholder who sees the demo and approves the concept has not seen the retrieval quality, the prompt behaviour, or the cost profile of a real provider. Those only appear once keys are configured. Finally, the repository is a monorepo with k8s manifests, a Makefile, semgrep and gitleaks configuration, an accessibility document and a security policy. That breadth is useful if you want the surrounding scaffolding, and heavy if you only want the RAG layer. Expect to spend time deciding what to keep. ## Where It Sits Against a Hosted Assistant The obvious alternative is a hosted conversational search product that you configure rather than build. The difference is not quality, it is the location of the retrieval logic. With a hosted tool, the index, the chunking strategy and the ranking live behind someone else's API. You tune prompts and filters and accept the rest. With this repository, ChromaDB and the FastAPI retrieval path are in your own deployment, which means you can change how listings are embedded, how results are ranked and how the LLM is prompted. That control has a matching cost. You own the index, the provider keys, the memory budget and the upgrades. The README also points to a hosted version called PropVector AI, which is marked "Hosted Soon" and is not described beyond the badge and link. That is a signal about the author's direction, not a documented product, and it is not something to plan around yet. A narrower alternative worth naming is using ChromaDB directly with your own FastAPI endpoints and skipping the monorepo. You would lose the provider factory, the financial calculators, the clustered map view and the nine-language interface, and you would keep full control of the retrieval code. If the eleven providers beyond your chosen one are noise rather than value, that is the leaner path. ## Licence, Maintenance and What Upgrades Cost You The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is permissive and unsurprising for a project of this kind. It says nothing about the data you index, the provider terms you accept, or the accuracy of any valuation or payment estimate the app displays. The README already labels the monthly payment figure as an estimate and not a lending offer, and the v5.1 valuation feature produces an LLM-generated number. Treat both as presentation, not advice, and check your own regulatory position on displaying them. Maintenance looks current rather than abandoned. The last push was on 2026-09-09, and the release history shows v5.1.2, v5.1.3 and v5.1.4 all on 2026-08-15, with the notes describing a broken hosted chart embed, a revert, and a documentation cleanup. Three patch releases in one day is a normal pattern for a small project reacting to a rendering problem, and it also tells you the release cadence is driven by the maintainer's own hosting rather than a roadmap. For upgrade cost, the practical exposure is the provider layer and the frontend framework. Next.js 16 and TypeScript 5.x are pinned in the badges, and the provider list grows over time, so a major framework bump or a provider API change is your work to absorb. The Makefile includes targets such as check-deps, migrate-check and api-diff, which suggests the project has at least some tooling for detecting dependency and API drift before a release. ## Conclusion Adopt it if you are building a property search product and want a working RAG pipeline, a FastAPI backend and a Next.js frontend to fork rather than assemble. Do not adopt it if you need a production-ready hosted assistant for agents today, or if you cannot run Python 3.12, Docker and a model provider key. Before committing, verify three things: that your chosen DEFAULT_PROVIDER is reachable from your network, that your host has at least 1 GB of RAM because the eager provider path sits around 530 MB, and that the demo scripts under scripts/demo/ run on your OS, since the README shows PowerShell only. ## FAQ ### What is the best AI real estate assistant? There is no single answer, but this project is one candidate worth evaluating: an open-source conversational platform for property search, analytics and market insights. The README's example query is "2-bedroom apartment in Kraków under 500k", answered through a RAG pipeline backed by ChromaDB and FastAPI. ### How much would a real estate agent make on a $300,000 house? Agent commissions are not covered by this project. What the README does document is a monthly payment estimate shown on each listing card, using 20% down, a 30-year fixed term and 6.5% APR by default, which it states is not a lending offer. ### What is the 3-3-3 rule in real estate? That rule is not discussed anywhere in the project's documentation. The README does describe a v5.1 valuation feature that returns an LLM estimate of current value plus projections at 1, 3, 5 and 10 year horizons with a confidence band. ### Can I get an AI assistant for free? The code is MIT licensed and the live demo runs without signup, but the README states the demo uses simulated AI responses. A production deployment requires API keys, though the provider list includes ollama, which allows local inference instead of a paid external API. ## Sources - [AleksNeStu/ai-real-estate-assistant on GitHub](https://github.com/AleksNeStu/ai-real-estate-assistant) - [License: MIT](https://github.com/AleksNeStu/ai-real-estate-assistant/blob/dev/LICENSE) - [Project website](https://realestate-web-dz1y.onrender.com/) - [README](https://github.com/AleksNeStu/ai-real-estate-assistant/blob/dev/README.md) - [Releases](https://github.com/AleksNeStu/ai-real-estate-assistant/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aleksnestu-ai-real-estate-assistant