Key facts
| Endpoint | POST /v1/embeddings (OpenAI-compatible) |
| Models | plugsky-embed, plugsky-embed-multilingual and plugsky-embed-nim in a 30+ model catalogue |
| Input limit | 8K-class text per request; live limits published per model |
| Vector dimension | Published per model on /models — read it before creating a collection |
| Use cases | RAG, semantic search, clustering and recommendations |
| Indexing | Batch embeddings for large corpora; re-embed when the model version changes |
| Isolation | Per-tenant collections and scoped keys per pipeline |
| Service model | Template the stack so onboarding is configuration, not code |
TL;DR
- OpenAI-compatible /v1/embeddings with the plugsky-embed family in a 30+ model catalogue.
- Dimension is published per model — read it before creating the collection.
- One reference pipeline, instantiated per tenant with its own keys and plane.
- Automate isolation checks; a misconfigured collection is a cross-tenant incident.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Read the model's live vector dimension from the catalogue and create the collection with it.
- Chunk by document structure, embed in batches, and store metadata for citations.
- Validate retrieval on a labelled question set before moving to production traffic.
- Build one reference retrieval pipeline with tenant parameters as configuration.
- Provision per-tenant collections, keys and audit metadata automatically.
- Run isolation checks before every customer onboarding.
Original data
Try it yourself
Open the embedding model comparison →
Embeddings for MSPs: what changes
MSPs run retrieval as a service across customers, which makes isolation the core requirement. Each tenant's vectors, metadata and logs must stay separate — and appear separate in audits — while the pipeline itself is operated once.
Plugsky exposes an OpenAI-compatible /v1/embeddings endpoint with the plugsky-embed family inside a 30+ model catalogue: plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages such as Arabic and English, and plugsky-embed-nim for teams standardised on NVIDIA-style profiles. Inputs are 8K-class per request, and each model's vector dimension is published on the model catalogue — read it before you create the collection.
Architecture and controls
Use per-tenant collections and scoped keys per pipeline, keep each customer's data in the agreed jurisdiction, and template the stack so onboarding is configuration. Keep audit metadata per tenant so reviews can be answered without cross-tenant exports.
Integration pattern and rollout
Package retrieval as a tiered service: managed index, hybrid search, scheduled refresh. Build one reference pipeline, then instantiate it per customer with their model, plane and retention profile.
Treat the dimension as a schema contract. When you change embedding models the vectors change, so plan a new collection and a backfill rather than an in-place swap. Chunk by document structure, store metadata alongside vectors, and combine vector similarity with keyword search and a reranker for production retrieval. Batch indexing jobs and re-embed only when the model version or chunking strategy changes.
Limits, evidence and cost
Isolation is not free: vector stores, keys and audit paths multiply with tenants, and a misconfigured collection is a cross-tenant incident. Automate provisioning checks, and price the operational overhead into the service.
Embeddings are available on platform plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card to build the application layer, then add the indexing workload when retrieval is on the roadmap. The 14-day full-access trial covers larger models.
Honest comparison
| Concern | Plugsky embeddings | Typical API provider | Self-hosted embedder |
|---|---|---|---|
| API shape | OpenAI-compatible /v1/embeddings | Usually compatible, varies | Custom serving stack |
| Model choice | plugsky-embed family inside a 30+ model catalogue | Provider catalogue only | You package each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Dimension changes | Read live dimension from /models; plan new collections | Varies by provider | You manage every migration |
| Operational load | Managed endpoint with batching | Managed endpoint | GPU capacity, patching and autoscaling |
| Tenant isolation | Per-tenant collections and scoped keys | Single-tenant tiers | You automate provisioning |
Frequently asked questions
Do we need to re-embed when we change models?
Yes. Vectors depend on the model and dimensions can change. Plan a new collection, backfill, validate, then cut over — re-embedding is a data migration, not a config flip.
Are embeddings region-locked?
Yes, when the workload is pinned to a region-locked plane. Keep the vector store, backups and logs in the same jurisdiction as the source data.
Which embedding model should we start with?
plugsky-embed for English-dominant corpora, plugsky-embed-multilingual for mixed languages, and plugsky-embed-nim for NVIDIA-style profiles. Evaluate on your own content.
How do we keep tenant indexes isolated?
Use per-tenant collections and scoped keys, and template provisioning with automated checks so a misconfiguration cannot cross tenants.
Can we offer retrieval as a managed service?
Yes. Package index management, hybrid search and refresh schedules as tiers, with residency options mapped to each customer.
What is the main operational risk?
Configuration drift across tenants. Automate checks and keep audit metadata per tenant so reviews stay answerable.