Key facts
| SaaS fit | One codebase; private placement as an enterprise option |
| Private access | Private endpoints; traffic stays in the deployment you select |
| Placement | Region-locked plane, customer VPC, on-prem or air-gapped |
| Isolation | Per-tenant workspaces, scoped keys and namespaced retrieval |
| Retention | Configurable per tenant; confirm your terms in the DPA |
| Audit | Inference, key and admin events exportable for customer review |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing | Flat monthly self-serve plans; embedded deployment scoped on the pricing page |
TL;DR
- Treat private placement as an enterprise packaging option, not a second product.
- Keep endpoint, model and retention configuration-driven so no code branches on deployment.
- Give each tenant its own keys and retrieval namespace, and export per-tenant evidence.
- Publish retention and residency options in contract-ready language.
- Price the managed layer — capacity, upgrades and support — not just licensing.
How it works, step by step
- Segment customers by boundary requirement: shared cloud, region-locked plane, dedicated VPC or in-network deployment.
- Make endpoint, model name and retention settings configuration values so the same build serves every placement.
- Define the private offering: topology, network requirements, identity integration, monitoring and upgrade cadence.
- Provision per-tenant keys and namespaced retrieval, and connect the customer's IdP for SSO with SCIM where required.
- Document retention and residency commitments in contract-ready language, and validate them against actual configuration.
- Automate deployment and upgrade runbooks so each new private customer is repeatable rather than bespoke engineering.
- Pilot with one customer, capture the runbook, and reuse it to protect margin on the next deal.
Try it yourself
Open the private LLM deployment estimator →
What enterprise buyers actually ask for
Private AI requests in SaaS deals usually reduce to four asks: data stays in an agreed boundary, access is attributable, retention is defined, and there is evidence. Buyers rarely need a bespoke product; they need your product to run in an environment their security team accepts. Plugsky's placements — region-locked plane, customer VPC, on-prem or air-gapped — answer the boundary ask, while scoped keys, SSO with SCIM and audit export answer the rest.
Framing it as packaging rather than a new product is what keeps the sales motion repeatable.
One codebase across placements
The discipline that makes private deployments affordable is configuration over branching. Endpoint, model name, retention setting and feature flags come from environment configuration; the application never asks where it is running. Identity and observability stay external: keys from the deployment's secret store, logs to the deployment's monitoring stack, the customer's IdP for SSO.
- Per deployment: keys, namespaces, quotas, audit export.
- Per tenant: model allow-lists, retention and data boundaries.
- Shared: application code, prompts and evaluation suites.
- Versioning: publish the platform and model bundle versions you support.
Pricing, operations and honest scope
Private deployment adds packaging, upgrade testing and support work, so price it as a managed layer. Use the flat monthly plans on the live pricing page for your own cost base and add margin for the operational effort rather than pricing purely on model access.
Keep capability parity honest in customer conversations: chat, streaming, JSON mode, function calling and embeddings are live in every placement, while audio, images, files and batch endpoints are labelled coming soon. If a buyer's roadmap depends on a coming-soon capability, say so during evaluation, not during acceptance testing.
Honest comparison
| Concern | Private placement | Dedicated VPC | Shared cloud |
|---|---|---|---|
| Buyer boundary | Data stays in their network | Data stays in their cloud tenancy | Standard terms |
| Your code changes | Configuration only | Configuration only | None |
| Tenant isolation | Keys and namespaces per tenant | Keys and namespaces per tenant | Logical isolation |
| Operations owner | Negotiated | Mostly you | You |
| Cost to serve | Highest | Moderate | Lowest |
Frequently asked questions
Do we need to fork our product for private AI?
No. Keep endpoint, model and retention configuration-driven so one build serves shared cloud, VPC and in-network placements.
How do we prove retention commitments?
Configure retention per tenant to the contracted period, then verify it in configuration reviews and include it in the customer's audit export.
What identity integration is possible?
The customer's IdP can provide SSO with SCIM for administrative access, while your application authenticates to the model API with scoped keys from the deployment's secret store.
Can we run evaluations across placements?
Yes. The API is OpenAI-compatible, so the same evaluation suite runs everywhere, which surfaces configuration drift before customers do.
How should the private tier be priced?
Cover infrastructure, packaging, upgrade testing and support, plus a margin for the managed layer. Model access alone understates the work.
What triggers the request most often?
Prohibitions on data leaving the customer's network, residency or sovereignty rules, and latency requirements that rule out a shared endpoint.
Which capabilities are live in private placements?
Chat completions with streaming, JSON mode and function calling, plus embeddings. Audio, images, files, batch, moderation, fine-tuning and assistants are labelled coming soon.