Your organization's knowledge base, built to power your AI pipelines too.
PrashFlow Atlas is a self-hosted wiki and knowledge base for organizations: folders, versioned pages and uploaded documents, permissions down to a single document, and watermarked viewing when it matters. Every page and file is also reachable through an authenticated API, so your own AI and RAG pipelines can integrate directly with your knowledge base instead of it staying trapped in a browser tab.
A wiki that was built to be read by more than a browser
Most internal wikis stop at rendering a page in a tab. PrashFlow Atlas keeps that, but treats every page and file as a permissioned, versioned, auditable object that your own tools can reach too, through the same access rules a person would hit clicking around.
Pages you type, files you upload, one model
Write a page straight in the browser, in Markdown, with images dropped in, or upload a file. Either way it's a versioned document in a folder, same permission and audit rules either path.
Permissions down to a single document
A folder-inheriting engine: grant a group or a person view, download, upload, or edit rights on a whole folder, then narrow it for one document without touching the parent grant.
Watermarked when it matters
PDFs and Office documents render with the viewer's name, email, IP, and timestamp burned server-side into every page, not a client-side overlay someone can inspect away.
Built to be read by your own tools
A token-authenticated REST API lists and downloads exactly what its owner can see in the app. Point a RAG ingestion job at it and let it decide what changed since the last run.
An audit trail that doesn't lie
Every login, view, download, and permission change is written to an append-only log, no update or delete path exists in the code, exportable as CSV for a real review.
Own your infrastructure, own your data
Self-hosted on infrastructure you control, the same architecture as every other PrashFlow product.
Most wikis were never built to be queried, only browsed
They work fine until you need to feed one to anything other than a person.
Your knowledge base is trapped in a browser tab
No API means a RAG pipeline or any other tool has to scrape rendered HTML, or someone exports pages by hand. Either way, nothing stays current.
Access control is all-or-nothing
A wiki that's either fully open internally or locked behind one blanket permission leaves no room for a folder that only one team, or one external contractor, should see.
No record of who actually read what
When a sensitive page leaks, or an external reader downloads something they shouldn't have, there's usually no log to check, and no mark on the file to trace it back.
Create, grant, read, query
The same four stages, whether the reader is a person or a pipeline.
Create
Type a page in Markdown, drop in images, or upload a file. Folders, versioning, and password protection all built in.
Grant
Give a group or an individual person exact actions on an exact folder or document. Nearest grant wins, nothing merges upward.
Read
Pages render in-browser, PDFs and Office files watermarked with the reader's identity burned in. A normal login session, nothing extra.
Query
An API token authenticates external tools against the exact same permission rules, for a RAG pipeline or anything else that needs programmatic access.
What's actually built today
No roadmap items, no "coming soon." This is what runs in the app and API right now.
Wikis, folders, pages, and documents
Multiple wikis per organization, nested folders, typed Markdown pages with inline images, uploaded files with full version history: list, restore, or delete a specific version, and a trash with configurable auto-purge.
Groups and invitations
Invite external readers into a group, scoped to the folders that group was actually granted, with optional domain and IP allowlisting.
NDA gate
An optional click-through NDA a reader has to accept before their first view, recorded with a timestamp and IP address.
Token-authenticated REST API
Personal access tokens, scoped to read or export, list every wiki and document a token's owner can see, download a document's original bytes, or pull a bulk manifest built for a RAG ingestion job: name, mime type, folder path, size, version, and a ready-to-call download URL for each document.
Append-only audit log
Every login, view, download, upload, and permission change recorded, exportable as CSV, with no update or delete path anywhere in the service layer.
Password-protected documents
Strong encryption at rest, keyed to a password only the uploader sets, not stored anywhere: lose it, and that document is unreadable, by design, even for an administrator.
Reader engagement scoring
Weighted activity per reader in a wiki, views and downloads ranked, so an admin can see who's actually reading it, not just who has access.
Built to feed a RAG pipeline, not just a browser tab.
An API token authenticates as whichever user created it, so every call is filtered through that person's own permission grants, a token can never read more than they could see in the app. The export endpoint returns a manifest with everything a RAG ingestion job needs to decide what changed and pull it, in one call.
- List every wiki and every document a token can see, folder path and mime type included
- One bulk export call returns the full manifest, name, path, size, version, and a downloadUrl per document
- Scoped tokens, read or export, revocable any time from the dashboard, never a shared API key
A screenshot still exists. It's not anonymous.
No web page can reliably block an OS-level screenshot, so PrashFlow Atlas doesn't pretend to. Every PDF and Office document is rendered server-side, per request, with the viewer's name, email, IP address, and timestamp burned directly into the page. A capture still identifies whoever took it. Screenshot-attempt heuristics log the attempt too, on top of that.
- Rendered server-side per request, not a CSS overlay a reader can disable
- Text, position, opacity, rotation, and which fields to burn in, configurable per organization
- A distinct "fence view" tier for restricted, view-only access, tracked separately in the audit log
Every request checked, browser or API token
There's exactly one permission engine. A session and an API token both resolve to a normal authenticated user, and that user's grants are what every read, download, or list call is filtered through, no separate, looser path for automation.
Browser session or API token
resolves to one authenticated userPermission engine
folder-inheriting, nearest grant winsYour wiki content
never more than that user was grantedYour wiki. Your data. Your control.
We deploy the full stack directly on infrastructure you own. Nothing about your documents, your pages, or who read what ever leaves your environment.
Questions, answered
Give your wiki an API, not just a browser tab.
Self-hosted, permission-checked either way, and ready to feed a RAG pipeline today.