Key facts
| API style | OpenAI-compatible |
| Credentials | One Plugsky key |
| Model source | Plugsky catalogue served directly |
| Routing | Model choice per request |
| Guardrails and caching | Not a gateway feature |
| Pricing | Flat monthly self-serve plans |
| Deployment | Cloud, VPC, on-prem, air-gapped |
| Feature status | Chat, streaming, JSON mode, function calling and embeddings live |
TL;DR
- Portkey governs provider traffic; Plugsky replaces the provider layer for its catalogue.
- Portkey keeps BYOK and per-token economics; Plugsky consolidates billing into plans.
- Guardrails and observability are Portkey strengths Plugsky does not replicate.
- Model breadth and flat pricing are Plugsky strengths Portkey does not provide.
- A production stack can use both: gateway for governance, managed API for capacity.
How it works, step by step
- Inventory what the gateway provides today: routing rules, guardrails, caches, budgets, logs.
- Separate platform requirements from conveniences before changing anything.
- Test a Plugsky endpoint with the same prompts and tools you send through the gateway.
- Decide which workloads should run where and keep model names in configuration.
- Rebuild essential guardrails at the application layer if traffic moves.
- Keep the gateway path available until the new route passes production checks.
Try it yourself
Open the API migration checker →
Two layers, one request path
From the client's perspective both look like a single HTTP call, which can make them seem interchangeable. They are not. The gateway intercepts a call that would otherwise go to a provider, enriches it with policy and forwards it. The managed platform is the destination: it runs the model, meters usage and returns the result.
That difference decides where features live. Retries, fallbacks, semantic caches and guardrails belong to the gateway. Model availability, capacity, model lifecycle and residency belong to the platform.
Governance versus managed capacity
Start with the governance features you truly rely on. If guardrails block disallowed content, or logs provide audit evidence, removing the gateway means rebuilding that behaviour in your application. That is possible, and it is real work.
Then look at the capacity side. A managed catalogue removes provider contracts, key rotation and per-token reconciliation, and adds flat monthly plans with a free plan covering plugsky-micro and plugsky-lite. Private deployment extends to VPC, on-prem and air-gapped. Current plans are on the live pricing page. The pragmatic architecture uses the gateway for policy and Plugsky for serving.
A migration that keeps guardrails
Run both layers in series during migration. Send a copy of production traffic through the managed endpoint, compare outputs and costs, and leave guardrails in place until you decide whether to reimplement them. This avoids a risky big-bang cutover.
Keep the gateway configuration in version control and the model names in environment configuration. When the numbers hold, move workloads one by one. The end state may be gateway plus managed platform, or managed platform alone if governance requirements turn out to live in the application already.
Honest comparison
| Layer | Plugsky | Portkey gateway | What to verify |
|---|---|---|---|
| Role | Serves 30+ models | Routes and governs requests | Which layer owns each feature |
| Credentials | One platform key | Provider keys in the gateway | Secret storage and rotation |
| Policy features | Application-level | Guardrails, caching, budgets | Compliance dependencies |
| Model access | Curated catalogue | Providers you connect | Catalogue coverage |
| Billing | Flat monthly self-serve plans | Provider spend plus gateway fees | Cost at your volume |
| Deployment | Cloud, VPC, on-prem, air-gapped | Hosted or self-hosted | Data path across both layers |
Frequently asked questions
Can Plugsky replace my Portkey gateway entirely?
Only if you do not depend on gateway-specific features. If guardrails, caching policies or cross-provider analytics are requirements, keep the gateway and use Plugsky as an upstream provider.
Do I need provider keys with Plugsky?
No. Plugsky serves its own catalogue, so you only manage a Plugsky key. That removes provider key sprawl but also removes routing to vendors outside the catalogue.
How does pricing differ?
Portkey adds gateway fees or operations on top of per-token provider spend. Plugsky self-serve plans are flat monthly with a free plan for plugsky-micro and plugsky-lite.
Will existing clients work with Plugsky?
Yes, if they use an OpenAI-compatible client. You change the base URL and model names, then re-test tools, JSON mode and streaming per model.
What happens to observability?
Provider-level analytics stay with the gateway. Plugsky provides platform usage views; if you need cross-vendor analytics, keep both layers.
Can the gateway route to Plugsky?
Yes. A gateway can treat an OpenAI-compatible managed endpoint as another upstream, which keeps one request path and one policy layer.
Which option is better for regulated workloads?
Plugsky offers region choice plus VPC, on-prem and air-gapped deployment. A self-hosted gateway can complement it when policy enforcement must also stay private.