Key facts
| SaaS fit | One codebase; cloud for most tenants, single-tenant on-prem for enterprise |
| Deployment | Same OpenAI-compatible API in customer VPC, data centre or air-gapped site |
| Application change | Base URL and model name only; prompts and SDK stay |
| Live endpoints | Chat, streaming, function calling, JSON mode and embeddings |
| Isolation | Per-tenant keys, workspaces and namespaced retrieval |
| Audit | Customer-visible key and inference events; SSO with SCIM for admin access |
| Pricing | Flat monthly self-serve plans; embedded deployment scoped on the pricing page |
| Operations | Define who patches, monitors and upgrades per deployment |
TL;DR
- Treat on-prem as an enterprise deal enabler, not a different product.
- Keep one codebase: the deployment target changes, the API and prompts do not.
- Give each customer deployment its own keys, observability and audit export.
- Decide and document operational ownership per deployment before signing.
- Price embedded deployments for infrastructure and support, not just licensing.
How it works, step by step
- Segment customers: those fine with shared cloud, those needing a dedicated VPC, and those requiring in-network deployment.
- Keep the model layer behind your own abstraction so the base URL and model name come from configuration, not from code branches.
- Define the single-tenant package: deployment topology, network requirements, identity integration, monitoring and upgrade cadence.
- Issue per-deployment keys and namespaces, and connect the customer's IdP for SSO with SCIM where required.
- Agree operational ownership in writing: who patches the platform, who monitors, who responds to incidents, and the support windows.
- Automate deployment and upgrade paths as much as possible so each new enterprise customer is repeatable rather than bespoke engineering.
- Pilot with one customer, document the runbook, then reuse it for the next.
Try it yourself
Open the private LLM deployment estimator →
Why enterprise deals ask for on-prem
Enterprise security reviews often decide the outcome of a SaaS deal. When a buyer's policy forbids data leaving their network, offering an in-network deployment converts a blocked deal into a closed one. Plugsky's on-prem variant runs the same OpenAI-compatible API inside the customer's VPC, data centre or air-gapped environment, so your application connects to an endpoint inside the buyer's perimeter.
The alternative — a bespoke integration per customer — destroys margins. Keeping one codebase and changing only configuration is what makes the motion repeatable.
Architecture that keeps one codebase
Two habits make multi-target deployment cheap. First, read the model endpoint and model name from configuration so no code path knows whether it is running in your cloud or the customer's. Second, keep identity, keys and observability external: scoped keys come from the deployment's secret store, logs go to the deployment's monitoring stack, and the customer's IdP handles SSO with SCIM.
- Per deployment: keys, namespaces, quotas and audit export.
- Per customer: model allow-lists, retention settings and data boundaries.
- Shared: prompts, evaluation suites and application code.
- Versioning: publish the supported platform and model bundle versions you test against.
Operations, pricing and honest trade-offs
Embedded deployments move real work to your team: packaging, upgrade testing, customer-specific environments and support. Price for it, and be explicit about who owns patching, monitoring and incident response. Compare your licensing and infrastructure position against the flat monthly plans on the live pricing page before quoting a customer.
Also be precise about capability parity: chat, streaming, JSON mode, function calling and embeddings are live in every deployment, while audio, images, files and batch endpoints are labelled coming soon. If a customer's use case depends on a coming-soon endpoint, say so now rather than discovering it during acceptance testing.
Honest comparison
| Concern | Single-tenant on-prem | Dedicated VPC | Shared cloud |
|---|---|---|---|
| Buyer requirement | Data never leaves their network | Data stays in their cloud tenancy | Standard security review |
| Your code changes | Configuration only | Configuration only | None |
| Operational owner | Negotiated: you, them or shared | Mostly you | You |
| Cost to serve | High: packaging and support | Moderate | Lowest |
| Sales motion | Enterprise, security-led | Enterprise, cloud-standard | Self-serve and mid-market |
Frequently asked questions
Do we need a separate product for on-prem?
No. Keep one codebase and make the endpoint and model configuration-driven. The deployment target changes; prompts, SDKs and evaluation suites stay the same.
How do we handle upgrades in customer environments?
Publish supported platform and model bundle versions, test upgrades first, and agree a maintenance window with the customer. Rollback should be part of the release plan.
Who monitors a customer-hosted deployment?
Decide in the contract. Common splits are customer-operated with your support, or your team operating under a managed agreement with defined SLAs.
What identity integrations are possible?
The customer's IdP can handle SSO with SCIM for administrative access, while your application uses scoped keys from the deployment's secret store.
Can we still use one evaluation suite?
Yes. Because the API is OpenAI-compatible, the same evaluation set runs against cloud, VPC and on-prem deployments, which catches configuration drift early.
How should we price embedded deployments?
Cover infrastructure, packaging, upgrade testing and support, not just model licensing. Use the live pricing page for your own cost base and add a service margin for operational work.
Which requests usually trigger the on-prem ask?
Prohibitions on data leaving the network, strict residency or sovereignty rules, and latency requirements that rule out a shared endpoint.