RAG Me Up: A Docker-Compose RAG Stack With a Standalone GPU Server
Generic rag framework to apply the power of LLMs on any given dataset
At a glance
- What is it?
- RAG Me Up splits a retrieval-augmented generation application into a Postgres-backed Node API, a React client, and a Python RAG server that can run outside Docker to reach a GPU. The split is the point and also the main operational cost.
- Who is it for?
- Adopt RAG Me Up if you want a pre-wired RAG application with a browser UI and you are willing to run three services, or if you need a host-side Python process with CUDA access while the rest stays containerised. Do not adopt it if you want a single-process library to embed in an existing Python service, or if you have no GPU and no reason to run Postgres.
- Can I use it commercially?
- Yes. Apache-2.0 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 3 days 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 problem RAG Me Up packages up
Building retrieval-augmented generation from scratch means writing the same plumbing repeatedly: document ingestion and chunking, an embedding step, a vector store, a retriever, a prompt assembly layer, and an HTTP surface so a front end can talk to it. RAG Me Up is positioned as that plumbing, already assembled. The README describes it as a simple and extensible framework to build RAG applications fast, and the repository ships a React client, a Node.js API server and a Python RAG server rather than a lone Python package.
That packaging choice tells you who it is for. If you want a library you import into an existing service, the three-process layout is overhead you did not ask for. If you want an application you can start with docker compose and then modify, the layout is close to what you would have built anyway. The README also states the framework has been used in production settings, naming SensAI.PT as an example. Treat that as a vendor statement, not an independent evaluation.
Three services, one Postgres, and where the vectors live
The architecture visible in the README is a chain. ParadeDB Postgres sits at the bottom. The Node.js API server talks to Postgres and to the Python RAG server. The React client, served by nginx, talks to the Node API. The Python server is where retrieval and generation happen, and it is the component the README treats as movable.
ParadeDB Postgres is the part worth pausing on. It is the vector store, and it is also the relational store for whatever the application persists. That means the retrieval layer is not a separate vector database you can swap out by editing a connection string; it is a Postgres instance with an extension. The README claims modularity, saying you can use your own chunkers, vectorstores, or retrievers. The claim is plausible given the framework structure, but the only concrete deployment the README documents is the Postgres one, so treat alternative vector stores as something you would verify in the source rather than something the documentation walks you through.
The data flow in hybrid mode is the clearest illustration of the split. The Node server runs in Docker and reaches the Python server on the host through host.docker.internal:5000 by default, controlled by PYTHON_SERVER_URL. Postgres is exposed on the host at localhost:6024, configurable through POSTGRES_PORT. The Python server connects to it with a URI of the form postgresql://langchain:langchain@localhost:6024/langchain, set as postgres_uri in server/.env. Note that the default credentials in that example are langchain, which is fine for a local trial and not fine for anything reachable from a network.
Getting the all-Docker stack up
The quickstart is four commands. Clone the repository, copy docker-compose.env.example to docker-compose.env, edit that file to set at least POSTGRES_PASSWORD and JWT_SECRET, then run docker compose --env-file docker-compose.env up --build -d. The React UI lands on http://localhost, or on whatever HOST_PORT you set in docker-compose.env.
The README is explicit about the constraint here: the full Docker Compose setup runs the Python server in CPU-only mode, with no GPU or CUDA access inside Docker. That is a deliberate limitation, not a bug, and it is the reason the hybrid mode exists. If your embedding model or your inference step is small enough to run acceptably on CPU, the single-command path is the whole story. If it is not, you are in hybrid mode whether you planned to be or not.
Two environment values are named as mandatory in the quickstart: POSTGRES_PASSWORD and JWT_SECRET. The JWT secret implies the Node API authenticates requests with signed tokens, which is consistent with a browser client being part of the default deployment. The README does not document token lifetime, refresh behaviour or user management, so those are questions for the Docusaurus site or the source.
Hybrid mode and the host.docker.internal problem on Linux
Hybrid mode runs Postgres, the Node API and the React client in Docker while the Python RAG server runs standalone on the host, where it can see the GPU. The compose invocation adds an overlay file: docker compose --env-file docker-compose.env -f docker-compose.yml -f docker-compose.hybrid.yml up --build -d.
On the host side you create a virtual environment inside the server directory, activate it, run pip install -r requirements.txt, and start the server with python server.py. It listens on port 5000 by default. Two keys in server/.env matter for this mode: postgres_uri, which must point at the host-exposed Postgres port, and embedding_cpu, which the README says should be set to False to use the GPU.
The networking caveat is the sharpest operational detail in the README. host.docker.internal resolves out of the box on Windows and macOS. On Linux it does not. The README gives two fixes: add --add-host=host.docker.internal:host-gateway to each service in the compose file, or set PYTHON_SERVER_URL=http://172.17.0.1:5000 in docker-compose.env. The second option hardcodes the default Docker bridge address, which will be wrong if you have changed the bridge network or if you are running rootless Docker. The first option is the more durable one, but it means editing the compose files rather than only the env file, which puts you off the documented upgrade path for those files.
Where this design gets in the way
The most concrete limitation is the one the README states outright: no GPU inside the default Docker Compose deployment. Anyone whose embedding or inference step needs CUDA cannot use the one-command setup, and the hybrid path asks them to manage a Python virtual environment, a requirements.txt install and a host process alongside the containers. That is two dependency systems and two upgrade procedures for one application.
The second limitation is the Linux networking workaround described above. It is not fatal, but it means the quickstart is only genuinely quick on Windows and macOS. On a Linux server, which is where most deployments would live, you are editing compose files or pinning a bridge IP before the stack talks to itself.
The third is documentation depth. The README points to a Docusaurus site for architecture docs, API references and guides, and does not reproduce them. Nothing in the supplied material describes chunking strategy, retrieval parameters, supported embedding models, or how to add a custom retriever despite the modularity claim. The README also lists no releases, so there is no changelog in the repository description to tell you what changed between versions or what a version number even means here. If you need to know the upgrade surface before adopting, that information is not in the README.
One more thing to check rather than assume: the README's own badge links point at ErikTromp/RAGMeUp while the repository is SensAI-PT/RAGMeUp. That is likely a leftover from a rename or transfer, but it is the kind of detail that matters if you are writing install scripts or CI that reference the canonical URL.
How it differs from assembling LangChain yourself
The obvious alternative is LangChain plus a vector store, wired by hand. The difference is not the retrieval algorithms, which in both cases come from libraries you did not write. The difference is what you get on day one. With RAG Me Up you get a running HTTP API, a browser UI and an authentication layer, because the Node server and React client are part of the repository. With a hand-rolled LangChain service you get a Python process and whatever API surface you build.
That cuts the other way too. A hand-rolled service is one process with one requirements file and one deploy target. RAG Me Up is three processes, two languages, a database with an extension, and a compose overlay for the GPU case. If your application is a backend service with no user-facing UI, you are carrying a React client and a Node API you will never expose, and the framework's main convenience becomes dead weight.
A second comparison point is the vector store choice. ParadeDB Postgres means your vectors live next to your relational data and you query them with SQL. A dedicated vector database would separate those concerns and add a second system to operate. Neither is universally better; the Postgres route is fewer moving parts if you already run Postgres, and more awkward if you do not.
Licence, maintenance and what to check before you commit
RAG Me Up is Apache-2.0. That permits commercial use, modification and redistribution, and it includes a patent grant. It also requires that you retain the licence and notice files and state significant changes you make. This is a description of the licence text, not legal advice; if you are redistributing the framework or embedding it in a product, have your own counsel read the NOTICE and attribution requirements.
The maintenance picture from the supplied material is thin. The repository is not archived and the last push is dated 2026-08-07, but no releases were retrieved, so there is no versioned artifact to pin against and no release notes to read. For a framework you intend to depend on, that matters more than the commit date. A moving main branch with no tags means an upgrade is a diff review every time, across three services and two dependency manifests.
The practical pre-adoption checklist follows from the constraints above. Confirm that server/requirements.txt resolves on your Python version, since the README does not state one. Confirm the compose overlay you intend to use matches the env keys you set, particularly PYTHON_SERVER_URL, POSTGRES_PORT, postgres_uri and embedding_cpu. On Linux, decide up front between --add-host=host.docker.internal:host-gateway and a pinned bridge address, because that choice affects every compose file you maintain. And read the Docusaurus site at ragmeup.sensai.pt before writing code, since the README delegates the architecture and API details there.
Editorial conclusion
Adopt RAG Me Up if you want a pre-wired RAG application with a browser UI and you are willing to run three services, or if you need a host-side Python process with CUDA access while the rest stays containerised. Do not adopt it if you want a single-process library to embed in an existing Python service, or if you have no GPU and no reason to run Postgres. Before committing, verify the Python and Node dependency sets install cleanly on your platform, confirm that server/.env keys such as postgres_uri and embedding_cpu match the compose file you intend to use, and check the Docusaurus site at ragmeup.sensai.pt for the API and architecture pages the README only links to.
Community notes