Key facts
| Deployment target | Customer on-prem or air-gapped estate running open-weight models |
| API continuity | Same OpenAI-compatible endpoints as your hosted product |
| Release model | Versioned bundles with checksums, release notes and rollback |
| Licensing | Offline entitlements that do not require call-home telemetry |
| Tenancy | Customer-managed workspaces and keys inside their perimeter |
| Support | Exported diagnostics and logs instead of remote access |
| Audit | Events export to the customer's SIEM for their compliance evidence |
| Status | Live platform; enterprise deployment terms per engagement |
TL;DR
- Treat the isolated estate as a deployment target, not a separate product.
- Ship versioned bundles with checksums, notes and rollback.
- Design offline licensing that does not depend on telemetry.
- Support through exported diagnostics; assume no remote access.
- Keep the API OpenAI-compatible so the feature set stays identical.
How it works, step by step
- Segment customers by deployment requirement — hosted, VPC or disconnected — and price the disconnected tier for its support cost.
- Keep one integration against the OpenAI-compatible endpoint; make base URL, model names and feature flags configuration.
- Build a release pipeline that emits signed bundles with checksums, migration notes and a rollback procedure.
- Implement offline entitlement checks that work without call-home, and document the renewal path.
- Create a diagnostics export the customer can run locally and send you: logs, metrics, version manifest and audit summary.
- Define which AI features degrade gracefully when a customer runs a smaller open-weight model.
- Validate each release against the customer's evaluation suite before shipping, and keep their version pinned until they upgrade.
Try it yourself
Open the self-hosting break-even calculator →
One product, multiple deployment targets
Disconnected customers are a delivery constraint, not a different product. If your AI features call an internal OpenAI-compatible endpoint instead of a public one, the same code runs everywhere: hosted, customer VPC, on-prem and air-gapped. Configuration carries the differences — base URL, model aliases, feature flags and limits.
That discipline keeps your roadmap singular. A feature ships once and reaches every segment, and customer-specific requests become configuration work rather than a fork you maintain forever. Make the endpoint a configuration value from the first commit; a hard-coded URL discovered late touches every call site in the product.
Releases, licensing and telemetry
An isolated estate cannot stream usage events to your servers, so billing, entitlements and product analytics all need offline designs. Issue signed licences with expiry and capability flags, and provide a reconciliation report the customer can run and send at renewal.
- Versioned bundles: signed artefacts, checksums, release notes and a documented rollback.
- Model pins: record exactly which model versions a customer runs to make support reproducible.
- Graceful degradation: gate features that need larger models behind capability checks.
Support without a connection
Support becomes asynchronous. Ship a diagnostics command that produces a redacted bundle — structured logs, metrics, version manifest and audit summary — which the customer exports and sends through their approved channel. Triage offline, then return a patch as another signed bundle.
Because Plugsky exposes identical endpoints offline, most issues reproduce in your own staging estate if you mirror the customer's model and version pins. Keep that mirror current; it is the fastest path between a customer report and a verified fix.
Honest comparison
| SaaS concern | Plugsky air-gapped | Hosted-only AI | Bespoke on-prem fork |
|---|---|---|---|
| Codebase | One integration across all targets | One target | Fork per customer |
| Feature parity | Same API offline; model-dependent features gated | Full feature set | Diverges over time |
| Licensing | Offline entitlements possible | Online subscription | Contract-dependent |
| Support | Export-based diagnostics | Direct remote support | Ad hoc |
| Updates | Customer-controlled bundles | Continuous delivery | Manual per customer |
| Cost to serve | Higher per account | Lowest | Highest |
Frequently asked questions
Will disconnected customers get every feature?
AI features that depend on model size are gated by capability checks. The API itself is identical offline, so features work wherever the locally deployed open-weight models can support them.
How does licensing work without internet?
Use signed offline entitlements with expiry and capability flags, plus a customer-run reconciliation report at renewal. No call-home telemetry is required.
How do we debug without access?
Ship a diagnostics export that collects redacted logs, metrics, the version manifest and an audit summary. Mirror the customer's model pins in your staging estate to reproduce issues quickly.
Do we need a separate release process?
Yes, for the disconnected track: signed bundles, checksums, release notes and rollback. Keep it aligned with your hosted releases so versions stay understandable.
How do we handle model updates on-prem?
Treat them as product releases. Validate against the customer evaluation suite, ship as a bundle, and pin until the customer schedules the upgrade.
Is the integration really the same?
Yes. The internal endpoint is OpenAI-compatible, so SDKs, prompts and agent loops are unchanged. Only configuration differs between environments.
What does it cost to serve?
More than hosted, primarily in support and release engineering. Price the disconnected tier accordingly rather than subsidising it from cloud margins.