Low-Code RAG Platform with UI
From Confluence to File Upload: Importers, Observability and Operations in Minutes
How an HR Bot Became a Whole Platform
We first got our feet wet with RAGs through an HR bot that grabbed our HR Confluence space as its knowledge base. The cool thing about it: document changes were automatically detected, re-crawled overnight, and available in the bot the next day. A real efficiency win.
With the S3 bots, a new requirement came up: manual upload of guides and policies. Because we learned: hand-crafted, curated overview files simply deliver better results than unstructured data. An article from LangChain emphasizes this too: the quality and structure of data largely determines the quality of answers.
That's exactly where the idea came from: Why not build a platform that combines automated crawlers and manual file uploads – and can be operated without constant developer intervention?
Data Quality Is Everything – Or Almost Everything
The performance of a RAG system depends less on the algorithm than on the quality of the underlying data. Structured, consistent, and current knowledge leads to precise answers – incomplete or outdated sources lead to frustration.
That's why it's not just important that the tech works. The specialist departments also need to actively take responsibility for their content. And this is exactly where the value of a platform shows: specialist areas can maintain, update, and upload their documents themselves. After all, they know best which information is relevant and where adjustments are needed.
A practical example: The HR team discovers an incorrect passage in a policy. Instead of waiting for the next nightly crawl, they upload the corrected file directly and immediately trigger re-indexing. A few minutes later, the bot already delivers the updated information. This immediate cycle shows how important it is that specialist departments can control themselves when and how knowledge is updated.
Importers: Simply Connect and Go
For RAGs to be truly usable in everyday work, data sources must be easily connected – without developers having to intervene every time. Our platform therefore relies on configurable importers that are set up directly via the user interface.
For Confluence, Jira, or Bitbucket, an account with the appropriate rights is sufficient: enter access data, select space or project, define crawl interval – done. The indexing then runs automatically via a cron job and keeps the knowledge base continuously updated.
Manual uploads are just as uncomplicated: specialist areas can add their own files like manuals or policies via drag-and-drop. For public websites, entering a URL is sufficient – the integrated web crawler takes care of the rest. Technical know-how? Not required. The only important thing is knowing which source is relevant.
We've designed the architecture so that additional importers can be added without much effort. New data sources can be connected via clearly defined interfaces – depending on project needs and customer requirements.
Access Control with Projects
The platform supports multiple projects, each completely separated from each other. Each project can be operated independently and connected via authorized endpoints. How and in which bots these endpoints are used lies outside the platform – it only provides clean interfaces.
In practice, we use OpenWebUI for this: bots can be created there that only access a specific RAG project. User groups and SSO then control which employees get access to which bot. This way, project teams A and B can work strictly separated from each other, even though both are based on the same platform. We've described more about our OpenWebUI setup and experiences with it in this previous blog post.
Internal rights management already exists insofar as projects each belong to one user and cannot be collaboratively edited. A real sharing model where multiple users work together on a project or roles are assigned is still on the roadmap.
Under the Hood: Component-Based and Extensible
Our RAG platform is component-based and designed for extensibility. For vector storage and retrieval, we rely on LightRAG. For embeddings, we currently use the Amazon Titan family – the selection of the specific model is configurable and can be replaced by other providers if needed.
The application runs in Amazon Web Services' Elastic Container Service (ECS). This containerization enables standardized deployments, rolling updates, and horizontal scaling. ECS also reduces operational overhead and fits well into existing cloud security and observability practices.
In the application core, we use PocketBase as a lean backend for project and user management, Hono.js for the API layer, and Vue.js for the web UI. For cloud integration, we currently rely mainly on Amazon Bedrock (embeddings). Jobs and their states are already centrally persisted, so executions remain transparently traceable.
What's Next: Collaboration & Better Search
The next step focuses on collaborative work in projects: project sharing with RBAC (Owner, Maintainer, Viewer), audit events for changes and queries, and deeper SSO integration for targeted release to groups of people. The goal is collaboration within a project – without data mixing between projects.
We're also discussing approaches to further improve search results – for example, by returning provenance data directly in the API or through relevance thresholds that specifically hide outdated content. The embeddings layer remains provider-agnostic and flexibly configurable.
For operations, we're examining cloud-native additions like AWS CloudWatch (metrics/alarms) and S3 (backups/snapshots). This way, the platform grows specifically in scalability and observability but remains lean at its core.
Overview Instead of Flying Blind: Observability & Operations
For RAG systems to run reliably, there needs to be transparency about the status of individual jobs and endpoints. Our platform provides an event overview where all import and crawl processes are visible. Users can directly track whether a job completed successfully or if errors occurred.
Additionally, health endpoints are available through which the API's status can be continuously checked. This allows simple monitoring checks or alarms to be integrated that immediately show when a service isn't responding as expected.
For more extensive integrations, the platform also offers an interface in the Model Context Protocol (MCP). Through this, external systems or agents can work directly with the endpoints and receive standardized feedback. A central KPI dashboard is planned as the next expansion step – with metrics like import runtimes, error rates, or cost overviews.
Creating Projects: Setup in Minutes
The platform makes getting started especially easy. New projects can be created in just a few steps via the interface: assign project name, generate API key, set crawl intervals – everything tab-based and without configuration files.
Importers and file converters are selected via dropdowns, cron schedules defined, and permissions for external access set. As soon as a project is saved, authorized endpoints are immediately available that can be directly integrated into bots or applications.
This lean setup process ensures that a RAG doesn't go productive only after days of development and testing, but is ready for operation within minutes. This significantly lowers the entry barrier and accelerates everyday use.
API Integration: Ready Snippets to Get Started
As soon as a project is created, authorized endpoints are available that can be used without additional configuration. The platform provides ready examples in the form of cURL snippets that can be directly tested or adopted into scripts.
Supported endpoints include /query, /query/stream, /health, and /mcp. The response examples are designed so developers immediately see how a request must be structured and which parameters – like mode: hybrid or top_k – are available.
This eliminates the barrier of first having to work through long API documentation. Anyone who wants to quickly build a prototype or test an integration can simply adopt the snippets and get started immediately.
The Biggest Lever: Less Development Effort
The biggest advantage of the platform doesn't lie in individual saved computing cycles, but in the drastic reduction of development and maintenance effort. Until now, every new chatbot meant: setup by developers, manual connection of data sources, tests, and regular updates. With the platform, this process is eliminated – specialist departments can create and update projects themselves.
This not only shortens time-to-value but also relieves IT teams who can concentrate their capacity on more complex tasks. At the same time, the risk of knowledge gaps decreases: changes in documents or new policies are faster in the system and immediately usable.
A side effect: availability becomes an economic factor. If a heavily used bot fails while employees have already gotten used to the new way of working, opportunity costs arise immediately. Through integrated monitoring functions – from event logs to health endpoints – such risks can be recognized early and countermeasures initiated.
Four Typical Use Cases from Practice
The platform's advantages become particularly tangible when applied in everyday work. From internal processes to IT operations – here are four scenarios where structured RAGs deliver noticeable added value:
- Process Bots: Support for internal workflows, such as in HR or IT departments. Policies, instructions, or standard processes are always available – maintained directly by the specialist areas responsible for this content. This reduces inquiries and relieves support teams.
- Project Bots: Access to project-specific documentation. Bots can not only interpret technical content like stack traces but also explain them in professional and conceptual context. Teams keep their own project documentation current and immediately benefit from improvements.
- Runbook Bots: Support in IT operations. They process not only uploaded manuals but combine various sources like troubleshooting guides, incident reports, and known error patterns. Operations teams can continuously expand their runbooks – the bot automatically grows with them.
- Knowledge Bots for Teams: Individually trained bots for specific areas – e.g., an "onboarding bot" for new colleagues or a "tool support bot" for internal software. The content comes directly from the respective teams, who can thus independently bundle and provide their knowledge.
The real added value lies in the fact that knowledge doesn't have to be centrally "imported" but is maintained directly where it originates – in the respective teams. The platform makes this knowledge immediately usable.
Roadmap: What's Coming Next
The platform is already productively usable today: projects can be independently created and used via authorized endpoints. On the short-term roadmap is now the possibility to collaboratively edit projects and introduce a full-fledged permission model with multi-tenancy. This allows granular access control and multiple users can work together on the same projects.
Medium-term, we plan the integration of guardrails to specifically control queries, as well as providing SDK snippets for common programming languages. Additional importers and converters are also planned, so even more data sources can be connected without effort.
An important topic is governance, especially when internal and external content is combined. Clear separation and approval will be necessary here. Additionally, operating costs must be kept in view – for example, through too frequent crawls or large document volumes. With the planned KPI dashboards and monitoring functions, however, we create the basis to recognize these risks early and actively control them.
Conclusion: Fewer Dependencies, More Independence
RAG systems only unfold their value when they can be easily maintained and reliably operated. This is exactly where our platform comes in: it enables specialist departments to independently contribute knowledge while simultaneously providing stable endpoints for bots and applications. This reduces development effort, increases data quality, and allows teams to benefit faster from AI-supported assistants.
For companies, this means: less dependence on individual developers, more independence for specialist areas, and a clear basis for scaling and governance.
Simon Bönisch, January 2026