Key facts
| Startup fit | Cloud first; on-prem only for a contract, rule or latency requirement |
| Free plan | plugsky-micro and plugsky-lite, no card; 2 API keys |
| Trial | 14-day full-access trial for higher tiers |
| Migration path | Same OpenAI-compatible API; base URL and model name change |
| Models | 30+ models behind one API; on-prem bundles licensed per agreement |
| Live endpoints | Chat, streaming, function calling, JSON mode and embeddings |
| Trade-off | Self-hosting trades token cost for infrastructure, upgrades and on-call |
| Pricing | Flat monthly self-serve plans; enterprise deployment scoped on the pricing page |
TL;DR
- Default to cloud; self-host only when a customer, regulator or latency budget requires it.
- Model breakeven honestly: GPUs, licensing and engineering time versus flat monthly plans.
- Keep the model layer configuration-driven so relocation is a base URL change.
- Prototype free with plugsky-micro and plugsky-lite, no card required.
- If you do move, start with one workload and a fallback path.
How it works, step by step
- Write down the trigger that would justify on-prem: a signed contract, a residency rule, or a latency SLO the cloud cannot meet.
- Estimate total cost of ownership: GPU capacity, licensing, engineering time, monitoring and on-call, then compare against flat monthly plans.
- Keep the model endpoint and model name in configuration so no code path is tied to one deployment.
- Prototype on the free plan and validate demand before committing any infrastructure spend.
- When the trigger arrives, migrate one workload first and keep the cloud path configured as fallback.
- Re-evaluate quarterly: startup volume and requirements change faster than infrastructure decisions.
Original data
Try it yourself
Open the self-hosting breakeven calculator →
When on-prem is actually justified
There are three honest reasons for a startup to self-host. A customer contract requires data to stay in their environment. A regulator or sector rule forbids external processing. Or latency requirements cannot be met over the public internet for an interactive product. Notice that none of these is 'it feels cheaper' — at startup volume it rarely is.
If none of the three applies, stay on cloud or a VPC deployment. Your engineering time is the scarcest resource you have, and on-prem converts it into infrastructure operations that do not differentiate your product.
The breakeven maths
Model the full picture before deciding. On the cloud side: flat monthly plan cost. On the on-prem side: GPU or server capacity, redundancy for failures, licensing under the deployment agreement, and the engineering time to deploy, patch, monitor and answer incidents. Add the opportunity cost of the features your team will not ship.
- Utilisation: low and spiky usage favours cloud; steady high usage favours self-hosting.
- Team: without a platform engineer, the operational load lands on founders.
- Timeline: infrastructure commitments outlive most startup roadmaps.
- Optionality: cloud keeps you able to switch models weekly during product discovery.
How to keep the option open
Design so the move is cheap later. Keep the OpenAI-compatible API, read the endpoint and model name from configuration, isolate extraction and retrieval behind interfaces, and avoid vendor-specific features that do not exist in self-hosted deployments. Then relocation is a deployment exercise with the same prompts and evaluations.
Start free with plugsky-micro and plugsky-lite and no card, move to a paid plan when traffic is real, and compare plan options on the live pricing page. Endpoint coverage is identical across deployments — chat, streaming, JSON mode, function calling and embeddings are live, while audio, images and files are labelled coming soon — so nothing you build against the cloud should surprise you on-prem later.
Honest comparison
| Concern | Cloud plans | VPC deployment | On-prem |
|---|---|---|---|
| Time to ship | Fastest | Days to weeks | Weeks to months |
| Cost at low volume | Flat monthly, predictable | Contract capacity | Capex plus ops |
| Data boundary | Vendor region choice | Your cloud tenancy | Your network |
| Operational load | Vendor | Shared | Yours |
| When it fits | Most startups, most of the time | Regulated deals with cloud allowed | Contract or rule forcing self-hosting |
Frequently asked questions
Should a startup ever start on-prem?
Rarely. Start on cloud unless a contract, regulation or latency requirement makes it impossible. You can relocate workloads later without changing application code.
How do we calculate breakeven?
Compare flat monthly plan cost with GPU capacity, redundancy, licensing and the fully loaded cost of engineering time for deployment, patching and on-call.
What triggers the move?
A signed contract requiring in-network processing, a residency or sector rule, or an interactive latency target the public endpoint cannot meet.
Will our code need rewriting?
No. The on-prem deployment exposes the same OpenAI-compatible API, so the base URL and model name are all that change.
Can we develop without paying?
Yes. The free plan includes plugsky-micro and plugsky-lite and two API keys with no card, which is enough for prototypes and early design partners.
What if only one customer needs on-prem?
Serve that deployment as an enterprise arrangement and keep everyone else on cloud. One configuration-driven codebase supports both.
How often should we revisit the decision?
Quarterly. Startup volumes, customer mix and residency requirements change quickly, and the breakeven point moves with them.