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
- Use managed collections to ship, not to build retrieval infrastructure.
- Keep the pgvector path open — the embeddings endpoint is standalone too.
- Route easy questions to small models and protect your burn rate.
- Start free; move to private deployment when a customer asks.
- Exercise the pattern on your own docs before customer data.
How it works, step by step
- Ingest your own documentation and changelog as the first corpus.
- Create a collection and query it with real questions from support or sales.
- Show citations in the UI so users can verify answers and give feedback.
- Route simple questions to plugsky-micro or plugsky-lite and escalate only when needed.
- Track retrieval quality with a small evaluation set as the corpus grows.
- Add scoped keys per environment and audit logging before enterprise conversations.
- Move to region pinning or private deployment when a deal requires it.
Original data
Try it yourself
Open the best model for RAG selector →
Why startups need RAG grounded in their own content
Early-stage teams should not be building retrieval infrastructure. The first version of a RAG feature needs three things: your documents ingested, decent retrieval and answers with sources. Everything else — custom indexes, sharding, model fine-tuning — is a distraction until customers prove they want the feature.
Managed collections get you from documents to a working query endpoint quickly. If your architecture already uses pgvector, you can keep it: call the embeddings endpoint standalone and leave retrieval in your own code. Both paths use the same OpenAI-compatible format, so the decision is reversible.
The Plugsky RAG stack: embeddings, collections, queries
The retrieval pipeline is three calls: embed, collect, query. POST /v1/embeddings converts text to vectors using plugsky-embed-v1 (1536 dimensions, OpenAI-ada compatible) or plugsky-embed-large (3072 dimensions); POST /v1/rag/collections stores and indexes documents with per-collection encryption at rest; POST /v1/rag/query returns ranked chunks with source attribution. Keyword, vector and hybrid retrieval are all available, with optional cross-encoder reranking when precision matters more than raw recall. For startups, managed collections remove a build project: the first version is ingest, query and ship, and the standalone embeddings path stays open if you outgrow it.
The controls startups should configure first
Keep the cost curve flat while you find product-market fit. Start on the free plan and route simple questions to plugsky-micro or plugsky-lite; escalate to larger models only when the answer needs it. Because 30+ models sit behind one key, you can test quality tiers without changing providers, and self-serve plans are flat monthly with unlimited fair-use usage rather than per-token billing.
When the first enterprise buyer asks where data is processed, pin a region or move the workload to a VPC deployment; the application code does not change. Add scoped keys per environment and audit logging before that conversation, not during it.
A practical pilot path
A good first project is documentation Q&A: ingest your docs and changelog, answer questions about your own product, and put the widget on the marketing site. It exercises chunking, retrieval and citations on content you already own, with no customer data risk. Once retrieval quality holds, extend to customer content. 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
Is the free plan enough to build a RAG prototype?
Yes. The free plan includes plugsky-micro and plugsky-lite with 2 API keys and no credit card, which covers a documentation Q&A prototype end to end. A 14-day full-access trial supports wider testing.
Should we use managed collections or our own vector store?
Use managed collections unless you already operate a vector database. Keep the embeddings call OpenAI-compatible so you can swap to pgvector or another store later without changing the model interface.
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.