Skip to main content

​
Migrating from Portkey

Igris is a governance-first LLM gateway. If you’re coming from Portkey, most of your mental model transfers directly — virtual keys, a unified API endpoint, provider routing. The differences are in the policy engine, observability depth, and architectural philosophy. This guide covers SDK migration, virtual key mapping, and a feature-by-feature comparison.

​
Why Igris

DimensionPortkeyIgris
Governance focusObservability + cachingPolicy enforcement + audit trail
Policy engineBasic budget limitsDiscriminated union rules, per-user conditions
Content inspectionNonePII patterns, keyword blocklist, content logging
Anomaly detectionNone5 signals: cost spike, token burn, response length, model shift, error rate
Credential storageCloud-onlySelf-hosted option (Docker / Kubernetes)
Open sourceNoCore proxy open source
Compliance docsNoEU AI Act compliance engine (@igris/comply)

​
SDK migration

The SDK surface is intentionally similar to Portkey. In most cases, migration is three lines: 
import Portkey from "portkey-ai";

const portkey = new Portkey({
	apiKey: "PORTKEY_API_KEY",
});

const response = await portkey.chat.completions.create({
	model: "@openai-prod/gpt-4o",
	messages: [{ role: "user", content: "Hello" }],
});
Key differences:
  • Package name: portkey-ai → @igris-security/sdk
  • Class name: new Portkey() → new Igris()
  • Virtual key slugs: Portkey uses @slug/model — Igris uses the same syntax. Your existing slug names can be reused.

​
Streaming

Both use the same streaming pattern: 
const stream = await portkey.chat.completions.create({
	model: "@openai-prod/gpt-4o",
	messages: [...],
	stream: true,
});

for await (const chunk of stream) {
	process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
}

​
Using existing OpenAI / Anthropic clients

If you’re using the portkey-ai package’s withPortkey() wrapper or a manual baseURL override, the Igris equivalent is the connectLlm() method or a subpath adapter: 
import OpenAI from "openai";
import { PORTKEY_GATEWAY_URL, createHeaders } from "portkey-ai";

const openai = new OpenAI({
	baseURL: PORTKEY_GATEWAY_URL,
	defaultHeaders: createHeaders({ apiKey: "PORTKEY_API_KEY", virtualKey: "openai-prod" }),
});

​
Virtual key migration

Portkey virtual keys map directly to Igris virtual keys. The slug syntax is the same — only the creation UI and API differ.
ConceptPortkeyIgris
CreateDashboard → Virtual KeysDashboard → Virtual Keys → New Virtual Key → LLM type
SlugAuto-assignedYou choose (or auto-generated)
Credential storagePortkey cloudIgris cloud or self-hosted
Supported providers250+59 (growing)
Custom base URLYesYes (customBaseUrl on the virtual key)
Model restrictionsNoYes (model allowlist per virtual key)
If you have existing slugs in Portkey, you can create matching slugs in Igris — the @slug/model syntax works identically.

​
Policy mapping

Portkey has budget limits and basic guardrails. Igris has a structured policy engine with more granular control.
Portkey conceptIgris equivalent
Budget limitlimit.dollars on a PolicyRule
Request rate limitlimit.requests on a PolicyRule
Guardrail hookscontentGuard on a PolicyRule
Metadata filteringconditions on a PolicyRule
Model allowlistVirtual key model restrictions + llm_model deny rules
Portkey budget (before): 
{
	"virtual_key": "openai-prod",
	"budget": { "amount": 100, "reset_strategy": "daily" }
}
Igris equivalent: 
{
	"target": { "kind": "llm_model", "model": "*" },
	"action": "allow",
	"limit": { "dollars": 100, "per": "day" }
}

​
Feature parity table

FeaturePortkey v1Igris v1
Core routing
OpenAI-compatible unified API✅✅
50+ provider support✅✅ (59 providers)
Streaming (SSE)✅✅
Embeddings✅✅
Images / audio✅✅ (passthrough)
Virtual keys
Encrypted credential storage✅✅
Model restrictions❌✅
Self-hosted credential vault❌✅
Policies & governance
Request/token/dollar rate limits✅✅
Per-user conditions❌✅
Metadata-based rules❌✅
Content guards (PII, keywords)✅ (limited)✅
Deny-by-default policy engine❌✅
Observability
Request logs✅✅
Token + cost tracking✅✅
Full prompt/response logging✅ (always)✅ (opt-in per rule)
Anomaly detection❌✅ (5 signals)
CISO dashboard + PDF reports❌✅
Compliance
EU AI Act doc generation❌✅
SOC 2 audit trail❌✅
Infrastructure
Semantic caching✅❌ (roadmap)
Load balancing / fallbacks✅❌ (roadmap)
Self-hosted deployment❌✅ (Docker)
Open source❌✅ (core)

​
Known differences

These Portkey features are not available in Igris v1: Routing strategies (fallback / load balance): Portkey supports fallback chains and weighted load balancing across multiple providers. Igris v1 routes to a single virtual key per request. Multi-key routing is on the roadmap. Semantic caching: Portkey offers vector-similarity caching for identical or near-identical prompts. Igris v1 does not cache. This is planned for a future release. Prompt management: Portkey has a prompt library with versioning and A/B testing. Igris does not include prompt management — use a dedicated prompt registry or keep prompts in your application. Webhook retries: Portkey’s webhook delivery includes automatic retries. Igris alert webhooks are fire-and-forget in v1.

​
Migration checklist

  • Install @igris-security/sdk and remove portkey-ai
  • Create a new Igris account at app.igris.dev/signup
  • Re-create your virtual keys in the Igris dashboard (same slugs are fine)
  • Update new Portkey(...) → new Igris(...) with your Igris API key
  • Update @portkey-slug/model → @igris-slug/model if slugs differ
  • Migrate budget limits to Igris policy rules
  • Verify audit trail in the Igris dashboard
  • Remove any portkey-ai residual code

​
Getting help