Key facts
| RAG endpoints | POST /v1/embeddings, POST /v1/rag/collections and POST /v1/rag/query |
| Embedding models | plugsky-embed-v1 (1536 dimensions, OpenAI-ada compatible) and plugsky-embed-large (3072 dimensions) |
| Retrieval modes | Keyword, vector and hybrid search with optional cross-encoder reranking |
| Citations | Every query returns ranked chunks with source attribution |
| Ingestion | Documents are chunked, embedded and indexed automatically per collection |
| Batch limits | Up to 2,048 inputs per embeddings request, max 8,191 tokens each |
| Data handling | Per-collection encryption at rest; API data is not used to train models |
| Deployment | Hosted, VPC, on-prem and air-gapped options; 30+ models behind one API |
TL;DR
- Start with your own docs, then add per-tenant customer content.
- A collection per tenant prevents cross-customer retrieval leaks.
- Separate retrieval from generation to control latency and cost.
- Stream responses and route simple questions to efficient models.
- Flat monthly pricing keeps unit economics predictable as usage grows.
How it works, step by step
- Pick the first corpus: product documentation, help centre or release notes.
- Create collections per tenant or corpus class and keep keys server-side.
- Set a latency budget and choose retrieval mode and model tier to meet it.
- Stream answers and show citations so users can verify and give feedback.
- Add per-tenant rate limits and quotas to prevent noisy-neighbour effects.
- Build an evaluation set from real support questions and track recall.
- Open customer-content corpora tenant by tenant after the first corpus works.
Original data
Try it yourself
Open the embedding model comparison →
Why SaaS teams need RAG grounded in their own content
SaaS teams reach for RAG for two reasons: support deflection and product experience. Answers grounded in your documentation reduce ticket volume, and answers grounded in the customer's own workspace — tickets, notes, uploaded files — make the product feel like it understands the account. Both need the same retrieval core.
The hard parts are multi-tenancy and latency. A shared index across tenants is a data leak waiting to happen, and an answer that takes eight seconds is worse than a search box. Design collections per tenant or per corpus class, and set an explicit latency budget before choosing models.
The Plugsky RAG stack: embeddings, collections, queries
Plugsky collapses the usual multi-vendor RAG stack into three OpenAI-compatible endpoints: POST /v1/embeddings turns text into vectors, POST /v1/rag/collections creates and manages collections, and POST /v1/rag/query returns ranked chunks with citations. Ingestion is automatic — documents are chunked, embedded and indexed per collection — and retrieval supports keyword, vector and hybrid modes with optional cross-encoder reranking. The embedding models are plugsky-embed-v1 (1536 dimensions, OpenAI-ada compatible) and plugsky-embed-large (3072 dimensions). For SaaS teams the same endpoints run internal documentation search and customer-facing answers, with collection boundaries keeping tenants apart.
The controls SaaS teams should configure first
Run retrieval with managed collections and keep tenant keys server-side. Each tenant gets a collection boundary, per-key rate limits and quotas, and usage attribution through audit logs that record user, model and region. Because the embeddings endpoint is OpenAI-compatible, you can also keep vectors in your own store if your architecture already has one.
For latency, separate the paths: retrieval is fast and cacheable, generation is the slower leg. Use efficient models for classification and short answers, reserve stronger models for complex questions, and stream responses so perceived latency drops. Publish a status page and use the same region pinning story in your own security docs.
A practical pilot path
Ship your own documentation first, measure deflection and answer quality, then open customer-content corpora tenant by tenant. Build an evaluation set from real support questions and track retrieval recall as the corpus grows. Prototype on the free plan, then scale on a flat monthly plan. See the live pricing page for current plans.
Honest comparison
| Capability | Plugsky | Assembling your own stack | Keyword search only |
|---|---|---|---|
| Retrieval | Keyword, vector and hybrid with optional reranking | You integrate and tune each component | Keyword matching, no semantics |
| Citations | Ranked chunks with source attribution | You build attribution yourself | Document links, not passages |
| Embeddings | plugsky-embed-v1 (1536d) and plugsky-embed-large (3072d) | Model choice spread across vendors | Not applicable |
| Deployment | Hosted, VPC, on-prem and air-gapped | Depends on every component | Usually on-prem already |
| Data handling | Per-collection encryption; API data not used to train models | You audit every vendor | Existing controls apply |
| Time to first answer | One collection and a query call | Weeks of integration work | Days, with lower answer quality |
Frequently asked questions
How do we keep tenant data separate?
Use a collection per tenant and a scoped key held server-side by your gateway, with per-key quotas and audit logs. The retrieval boundary is explicit rather than implied by metadata filters.
Will this stay affordable as usage grows?
Self-serve plans are flat monthly with unlimited fair-use usage and no per-token billing, so cost does not scale linearly with every query; see the live pricing page for current plans.
Do we have to change our application code?
No. The RAG endpoints are OpenAI-compatible, so existing SDKs, prompts and evaluation harnesses keep working when you point the base URL at Plugsky.
Is there a free plan?
Yes — plugsky-micro and plugsky-lite with 2 API keys and no credit card. A 14-day full-access trial is also available.
How is pricing structured?
Self-serve plans are flat monthly with unlimited fair-use usage and no per-token charges or overage fees. See the live pricing page for current plans.
Does Plugsky train on our data?
Plugsky states that API data is not used to train models, and collections are encrypted at rest; on Enterprise you can keep everything inside your own VPC.