Key facts
| When needed | Rarely early; driven by customer contract or regulation, not by preference |
| Default path | Build on the cloud endpoints with plugsky-micro and plugsky-lite free, no card |
| Trial | 14-day full-access trial for heavier prototyping |
| Portability | OpenAI-compatible API means the same code runs in every tier |
| Hardware reality | Air-gapped means GPUs you own, sized for peak with no bursting |
| Hybrid option | Route sensitive workloads to a private or on-prem tier, keep the rest hosted |
| Update burden | You own model and runtime refreshes in a disconnected estate |
| Status | On-prem and air-gapped tiers are live; enterprise terms per engagement |
TL;DR
- Do not build for an air gap before a customer requires one.
- Develop on the free cloud tier and keep the API integration portable.
- A private endpoint in your VPC or the customer's solves most residency asks.
- Only go disconnected when the contract pays for the hardware and support burden.
- Because the interface is OpenAI-compatible, adding the tier later is a deployment, not a rewrite.
How it works, step by step
- Ask what the customer actually requires: region-locked processing, VPC isolation or genuinely no egress.
- Build your product against the hosted OpenAI-compatible endpoints using the free models for day-to-day development.
- Keep base URL, model names and feature flags in configuration so deployment target is not hard-coded.
- For most enterprise objections, offer a VPC or on-prem tier with controlled egress before discussing a full air gap.
- If a deal requires no egress, price the hardware, deployment and update burden into the contract.
- Deploy open-weight models sized to the customer's hardware, and gate features the local models cannot support.
- Keep one evaluation suite running against every tier so quality expectations stay honest.
Try it yourself
Open the private LLM cost estimator →
Why air gaps rarely fit startups
An air-gapped estate is hardware you buy, size for peak, patch yourself and cannot burst. For a startup, that capital and operational load competes directly with product development, and the market that requires it is small relative to the effort. Most early AI startups should let the customer's requirement pull them into disconnected deployment, not push it speculatively.
The classic mistake is building the hard version first: a bespoke on-prem release with a divergent codebase that slows every subsequent feature for the majority of customers who never needed it.
The hybrid path that actually sells
Start hosted. Use plugsky-micro and plugsky-lite on the free plan to build and demo, and move to a paid plan as usage grows. When a customer raises residency, offer the middle options first: region-locked planes, a private endpoint in your VPC or theirs, or an on-prem deployment with controlled egress. These satisfy most procurement and security reviews at a fraction of the air-gap cost.
- Keep it configurational: base URL, model alias and deployment flags, never hard-coded.
- Gate features: smaller open-weight models will not match frontier quality on every task.
- Price honestly: deployment, refresh cycles and support are recurring costs, not one-off favours.
If a deal truly requires an air gap
Then treat it as a deployment project with a business case. Size GPUs for the customer's concurrency, plan the update bundle process, decide who owns keys and recovery, and confirm who pays for refresh cycles after go-live. Plugsky runs the same OpenAI-compatible endpoints offline with open-weight models, so your application layer does not need a second implementation.
Negotiate scope tightly: one or two workloads, one network segment, a named evaluation set and a support agreement. A successful bounded deployment is a reference; an unbounded one is a sink for engineering time you should be spending on the core product.
Honest comparison
| Startup decision | Start hosted | Private or on-prem tier | Full air gap |
|---|---|---|---|
| Upfront cost | None | Moderate | High — hardware and setup |
| Time to first customer | Days | Weeks | Months |
| Satisfies residency | Region-locked planes | Often yes | Beyond most requirements |
| Update burden | Provider-managed | Shared | Entirely yours |
| Feature quality | Full model range | Full model range | Limited to local models |
| When to choose | Default for startups | Enterprise security review | Regulated contract only |
Frequently asked questions
Do we need GPUs to start?
No. The hosted API handles inference, and the free plan with plugsky-micro and plugsky-lite needs no card. Buy hardware only when a customer contract requires disconnected operation.
How do we answer a residency question in a sales call?
Offer region-locked planes first, then a private endpoint or on-prem deployment with controlled egress. Most buyers accept these; a full air gap is a last resort with real cost implications.
What breaks if we build air-gap first?
You slow every feature for every customer, carry hardware cost early and create a divergent codebase. The requirement usually belongs to one deal, not the product.
Can we support an air-gapped customer later without a rewrite?
Yes. The API is OpenAI-compatible across tiers, so adding a disconnected deployment is configuration, packaging and hardware — not a second implementation.
Who pays for model refreshes in a disconnected estate?
The customer, contractually. Refresh cycles, evaluation and support are recurring work; price them into the agreement rather than absorbing them.
What about a hybrid model?
Common and sensible: keep most workloads hosted and route sensitive ones to a private or on-prem tier through the same API. You get residency where it matters without running everything yourself.
How do we evaluate local model quality?
Keep one evaluation suite per feature and run it against every tier. Gate features behind capability checks when the local open-weight model cannot meet the bar.