Key facts
| Deployment | Runs in your AWS, Azure or GCP account, or private cloud |
| API | OpenAI-compatible; SDK code does not change |
| Networking | Private endpoints; egress can be restricted |
| Data path | Prompts and outputs stay inside your boundary |
| Billing split | Plugsky plan plus your cloud provider infrastructure costs |
| Provisioning | Scoped enterprise agreement with onboarding support |
| Models | Open-weight models served in-VPC; hosted models via opt-in routing |
| Product status | Live |
TL;DR
- The gateway and models run inside your cloud account, not Plugsky's.
- Private networking and restricted egress are the main reasons to choose VPC.
- Your code stays the same — the API remains OpenAI-compatible.
- Two bills: Plugsky for the platform, your provider for the infrastructure.
- VPC sits between shared cloud convenience and on-prem control.
How it works, step by step
- Define the isolation goal: private ingress, restricted egress, or both.
- Choose the target cloud and region where your data must remain.
- Size the in-VPC compute for your expected concurrency and model shortlist.
- Provision the deployment with the team and wire it to your private network.
- Point existing clients at the private endpoint and run your test suite.
- Set up cost monitoring across both the Plugsky plan and your cloud account.
Try it yourself
Open the private LLM deployment estimator →
How a VPC deployment is shaped
The serving path lives in your account: a gateway that exposes the OpenAI-compatible API, model runtimes on GPU instances, and local logging and storage. Your applications call a private endpoint over your VPC network rather than a public hostname. Because you control the network, you can restrict egress to only what the deployment genuinely needs — and for stricter cases, remove it entirely and adopt the air-gapped pattern. Region choice stays yours, which makes residency conversations concrete rather than contractual guesswork. For many teams this is the first deployment where security, networking and cloud cost reviews happen together rather than sequentially.
VPC versus shared cloud versus on-prem
Think of it as a control-and-effort dial:
- Shared cloud: lowest effort, fastest start, 30+ models, managed encryption. Right for most product teams.
- VPC: your boundary, private networking, your cloud costs, open-weight models with optional routing to hosted ones. Right when network isolation or residency must be demonstrable.
- On-prem: physical control, your data centre, highest operational burden. Right for strict physical or procurement requirements.
Most teams that ask for VPC are solving for network isolation and auditability, not raw capability — and VPC addresses both without the full on-prem burden.
What we do and what we do not do
What we do: deploy and support the OpenAI-compatible gateway and model serving inside your account, help size compute, and keep the API stable across deployments. What we do not do: pay your cloud bill, make every hosted model available in-VPC by default (opt-in routing is needed for external models), or promise turnkey provisioning on a self-serve timeline — VPC is scoped. Read the SLA and plan the operating split: platform operations with Plugsky, infrastructure operations with your cloud team.
Honest comparison
| Capability | Plugsky VPC | Plugsky shared cloud | On-prem |
|---|---|---|---|
| Network boundary | Your VPC | Shared managed region | Your data centre |
| Egress control | Restrictable, can be removed | Provider-controlled | Fully controllable |
| Infrastructure bill | Your cloud provider | Included in plan | Your hardware |
| Provisioning effort | Scoped enterprise onboarding | Self-serve | Highest |
| Model catalogue | Open-weight in-VPC, opt-in routing | 30+ models | Open-weight local |
| Best fit | Network isolation with cloud scale | Fast start and breadth | Physical control |
Frequently asked questions
Which clouds are supported for VPC deployments?
Plugsky documents deployments in major clouds plus private-cloud environments. Confirm the current supported list with the team during scoping.
Does my application code change in a VPC?
No. The endpoint remains OpenAI-compatible; you change the base URL to your private endpoint and keep the same SDK and payloads.
Can egress be fully blocked?
Yes, but then you are effectively running air-gapped: updates and model weights arrive through a controlled transfer process, and hosted models are unavailable.
Who pays for the GPU instances?
You do — they run in your cloud account. The Plugsky plan covers the platform and support; the infrastructure appears on your provider bill.
Are hosted frontier models available in-VPC?
Only through opt-in routing to an external path. For fully private deployments, plan around locally served open-weight models.
How long does a VPC deployment take?
It is a scoped enterprise rollout, not a self-serve toggle. Timelines depend on cloud, region, capacity and security review — start early and in parallel with procurement.
Can I trial before committing to VPC?
Yes. Prototype on the shared cloud with the free plan and the 14-day full-access trial, then scope VPC once the model shortlist and capacity estimates are proven.