Portkey vs Helicone: which fits your LLM gateway needs
Start with the question that usually triggers this comparison: a Portkey renewal, a data residency review, or a wish to run the LLM gateway inside your own network. Portkey fits teams that want a managed or hybrid gateway with a vendor-run control plane and a broad feature set, including prompt management, semantic caching and advanced logging, which its own repository lists as enterprise features outside the open-source gateway. Self-hosted Helicone fits a different team: one that wants the whole stack on its own infrastructure and has the people to run it. Helicone's README describes a gateway with 100+ models, routing and automatic fallbacks, plus logging, cost tracking and prompt versioning, and it deploys with Docker Compose, with a production Helm chart for enterprise workloads available by request.
The decision turns on four questions. First, which enterprise features you actually need, and whether each one is included in the self-hosted build or only in a paid tier you would still have to buy. Second, where logs may live. Portkey's hybrid model keeps the gateway in your VPC but sends control traffic to control.portkey.ai, while a self-hosted Helicone keeps request logs in your own ClickHouse and MinIO. Third, whether Helicone's status is acceptable. Mintlify announced its acquisition of Helicone on March 3, 2026, and both companies say Helicone will continue in maintenance mode with security updates and bug fixes, while Mintlify offers to help customers move to another platform. Fourth, your operating capacity. A self-hosted Helicone runs a Next.js frontend, a Cloudflare Workers proxy, the Jawn log server, Supabase, ClickHouse and MinIO, so you own upgrades and backups for all of them.
Before you decide, ask Helicone for its current maintenance commitments in writing and confirm the Helm chart terms, and ask Portkey which controls your hybrid contract covers. Then price the internal effort honestly: who patches Supabase and ClickHouse, who restores logs, and who answers when the proxy fails. If that team does not exist, a fixed-scope implementation with a retainer for upgrades can be a practical middle path, and DeployOpen can scope that work against your environment.
Which option fits which scenario
This table matches the most common situations to the option that usually fits better, with the condition that decides it. Read each row against your own constraints: where logs may live, how much operating work your team can absorb, and whether you already run Helicone. Treat the rows as starting points to confirm against your environment, not as a substitute for a written scope.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Need hosted logs with minimal operations | Portkey managed tiers | Your team does not want to run a logging database, object store or web frontend, and accepts a vendor-hosted log store under Portkey's plan terms. |
| Strict requirement that logs stay in your VPC | Self-hosted Helicone | Portkey's hybrid model keeps the control plane at Portkey, so confirm whether your policy allows that split before choosing it. Helicone runs entirely in your infrastructure. |
| Need prompt management or semantic caching on the open-source path | Portkey, or Helicone with its prompt versioning | Portkey lists prompt management and semantic caching as enterprise features outside its open-source gateway. Helicone's prompt versioning is deployed through its gateway, so confirm which caching behavior you need before committing. |
| Existing investment in Helicone | Self-hosted Helicone | Helicone's maintenance-mode status after the Mintlify acquisition announced on March 3, 2026 matters here. Confirm its roadmap and upgrade path with the vendor before expanding use. |
| Multi-provider routing with fallbacks only | Portkey Gateway (MIT licensed) or a self-hosted gateway | If you only need routing and fallbacks, Helicone's gateway covers that, but the open-source Portkey Gateway runs with a simpler footprint. Confirm which provider adapters you need. |
| No in-house Kubernetes or database operations | Portkey managed tiers | Self-hosted Helicone runs a Next.js frontend, Cloudflare Workers proxy, Supabase, ClickHouse and MinIO, which requires ongoing operations. Ask a partner or vendor to scope that work before deciding. |
Where logs and configuration live under each model
Portkey and Helicone split traffic, logs and configuration differently, and the split decides which network, residency and vendor reviews you must run. The cards below cover the placement under each option, the identity and evidence questions that follow, and the vendor risk of Helicone's current ownership.
Portkey hybrid deployment
The gateway, which is the data plane, runs in your VPC, while the control plane stays in Portkey's VPC. The gateway calls out over HTTPS to control.portkey.ai, so prompts, keys and configuration metadata cross that boundary. Confirm with Portkey exactly which fields reach the control plane, where logs are stored, and whether your egress rules can allow that endpoint.
Portkey fully managed
In the managed tiers, the gateway, configuration and logs all run in Portkey's infrastructure, and your team does not patch or scale any of it. Traffic to providers still originates from Portkey's side, so provider keys and request content sit in a third-party environment. Ask for the data region, retention settings and deletion process in writing before you send production prompts.
Self-hosted Helicone components
A full self-hosted Helicone deployment runs a Next.js web frontend, a Cloudflare Workers proxy for logging, the Jawn log collection server, Supabase for the application database and auth, ClickHouse for analytics and MinIO for log object storage. You own every one of these stores, so backups, encryption and access paths are your responsibility. Treat the Cloudflare Workers proxy in the logging path as a residency question to confirm, because it decides whether request bodies transit infrastructure outside your network.
Identity and SSO implications
Portkey's enterprise access controls and SSO depend on the plan you buy, so confirm which SSO and role features apply to your tier and whether they cover both the gateway console and API key administration. Self-hosted Helicone authenticates users through Supabase, which means your identity integration, session lifetime and admin roles are configured in that stack. Map who can read logs, who can rotate provider keys and who can change routing rules under each model before you choose.
Compliance evidence responsibilities
Under a self-hosted model, your team produces the access records, change history, backup tests and data flow diagrams that an auditor will request. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications, and independent auditors do that work. Under the managed model, ask Portkey which reports it can provide and which controls remain your responsibility.
Helicone maintenance mode and vendor risk
Mintlify announced on March 3, 2026 that it is acquiring Helicone, and both companies say Helicone will continue in maintenance mode, with security updates, bug fixes and new models still shipping. Mintlify has offered to help customers move to another platform. Treat this as a roadmap and continuity question: the most recent tagged GitHub release is v2025.08.21-1, published August 21, 2025, so confirm current release activity before you commit to a self-hosted stack.
What running Helicone's stack involves day to day
A self-hosted Helicone deployment is not one service. The README describes a Next.js web frontend, a Cloudflare Workers proxy that handles logging, the Jawn log collection server, Supabase for the application database and authentication, ClickHouse for analytics, and MinIO for log object storage. Your team owns every one of these components once they run in your infrastructure. Setup is documented with Docker Compose, and the README says a production Helm chart for enterprise workloads is available by contacting Helicone. Ask for that chart in writing and confirm its supported Kubernetes versions and upgrade path before you plan a cluster-based deployment.
Each component creates recurring work. Supabase holds the application database and user accounts, so you need backup and restore procedures for it and a plan for how sign-in is secured and who administers it. ClickHouse holds the analytics data, and its storage grows with request volume and retention settings, so set a retention policy and monitor disk usage from the start. MinIO stores log objects, which means bucket backup, capacity planning and access policies sit with your storage team. Confirm how the Cloudflare Workers proxy is deployed and whether it can run entirely inside your network, since that determines where request data passes.
Upgrades and security patching are the largest ongoing cost. The latest tagged release on the Helicone GitHub releases page is v2025.08.21-1, published on August 21, 2025. Before you commit, check current release activity on the repository, because the Mintlify acquisition announced on March 3, 2026 says Helicone will continue in maintenance mode, with security updates and bug fixes still shipping. Ask Helicone or Mintlify to confirm the support commitments for self-hosted users, the patch process for each component, and whether the enterprise Helm chart receives updates on the same schedule as the Docker Compose setup.
Cost components on the managed and self-hosted sides
Buying Portkey and self-hosting Helicone spread cost across different line items, and only some of them are license fees. Each card below names one component, whether it is one-time or recurring, what moves it, and what to request in a written quote so the comparison is made on like-for-like terms.
Portkey plan and enterprise contract
On the managed side, the recurring cost is the Portkey plan or enterprise contract, which is set by the commercial terms you agree with Portkey, not by anything in this page. Ask which features sit in each tier, including logs, prompt management, semantic caching, access control and PII redaction, since Portkey's repository lists several of these as enterprise features outside its open-source gateway. Confirm whether a hybrid deployment changes the contract, and whether the quote is per log, per seat or per committed volume.
Log volume effects
Log volume is the variable most likely to change the total. On a hosted gateway, the number of requests you send can change the plan tier or the overage charges. On a self-hosted Helicone, the same volume drives ClickHouse storage, MinIO object storage and the Jawn and Workers capacity needed to keep up. Model expected requests per day, average payload size and retention period before you ask for quotes, and request pricing at your projected volume plus a higher tier.
Helicone software licensing
Helicone's GitHub repository is licensed under Apache-2.0, so using the software itself carries no license fee. Recurring costs still exist around it, and the Helicone project is in maintenance mode following Mintlify's announced acquisition on March 3, 2026. Confirm with Mintlify and Helicone what support, security updates and migration help remain available before you commit, because that affects how much internal effort you should plan to carry.
Infrastructure for the self-hosted stack
Self-hosting Helicone is a recurring infrastructure cost for compute, storage and backups across the components the README lists: the Next.js frontend, the Jawn log server, Supabase, ClickHouse and MinIO, plus the Cloudflare Workers proxy used for logging. Costs rise with log volume, retention, redundancy and the number of environments. Ask your cloud or data center team to estimate each component separately, and confirm where the Workers proxy runs if you need all traffic to stay inside your network.
Staff time for operations
Operating Helicone is largely a staffing cost. Your team owns upgrades, database maintenance, ClickHouse capacity, backup and restore tests, monitoring and on-call response for a stack with several stateful services. This cost recurs for as long as the service runs, and it rises with the number of environments and the frequency of upstream changes. Record the hours your platform team expects to spend each month, and compare that figure with the hosted option's operating effort.
Helm chart or support from Helicone
The README says a production Helm chart for enterprise workloads is available by contacting Helicone, so the terms are not public. Treat this as a separate line item that may be one-time, annual or per-incident, depending on what you agree. Ask in writing whether the chart is included, what version support covers, what the response targets are, and whether support continues under Mintlify's ownership.
DeployOpen implementation and retainer work
If you use an outside partner, DeployOpen scopes, implements, hardens, backs up, upgrades and documents a self-hosted platform inside your infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. The implementation is one-time, while a retainer recurs. DeployOpen does not publish a price list, so request a quote built from your written scope.
How a move from Portkey to self-hosted Helicone unfolds
This sequence takes a team from an inventory of Portkey usage to a self-hosted Helicone gateway that carries live traffic, with Portkey retired only after the new path has been checked against real requests.
Inventory Portkey features in use
Your platform or gateway owner lists every Portkey feature that production traffic depends on: routing configs and fallbacks, virtual keys and budgets, prompt templates deployed through the gateway, caching, guardrails, and the log views your finance and security teams read. Mark which items Helicone covers directly (gateway routing with fallbacks, logging, cost and latency tracking, prompt versioning) and which you must replace or drop. The step is done when the list is signed off by the application owners who call the gateway, so nothing is discovered after cutover.
Export existing logs and configuration
Pull the history you need to keep before any traffic moves. Confirm with Portkey which export path your plan includes and in what format it delivers records, since export access depends on plan and contract. Save routing configs and prompt text as version-controlled files in your own repository. The step is done when you can open a sample of exported records and a copy of each config outside Portkey.
Stand up Helicone in a test environment
Deploy Helicone from its Docker Compose setup in an isolated environment inside your infrastructure. The stack includes a Next.js web frontend, a Cloudflare Workers proxy for logging, the Jawn log collection server, Supabase for the application database and auth, ClickHouse for analytics, and MinIO for log object storage. Your platform team owns sizing, secrets, backups and network rules. Ask Helicone for the production Helm chart and its support terms before choosing a Kubernetes target. The step is done when a test request appears in the Helicone dashboard with cost and latency recorded.
Repoint clients to the Helicone gateway
Choose the integration path for each application. The first option changes the client's base URL to the Helicone gateway, which gives routing with automatic fallbacks across the 100+ models the README describes. The second keeps existing calls and adds asynchronous logging through OpenLLMetry, which records traces without changing request routing. Apply the change in a non-production branch of each service and keep provider keys in your secrets store. The step is done when each service sends a test request through the chosen path and the trace shows the expected model and provider.
Rebuild prompts and routing rules
Recreate the routing configs and prompt templates from your inventory in Helicone. Helicone's prompt versioning is deployed through its gateway, so write down how each prompt is named, versioned and promoted to production, then map Portkey's equivalent behavior onto it. Recreate fallback order and retry settings, and check any feature with no Helicone equivalent against your inventory, such as semantic caching or Portkey-specific guardrails, which need a separate decision. The step is done when a side-by-side test shows the same prompt output and fallback behavior for a fixed set of requests.
Run Portkey and Helicone in parallel
Send a share of production or shadow traffic through Helicone while Portkey keeps serving the rest. Compare error rates, fallback triggers, latency, token counts and cost figures between the two paths for the same workloads. Watch logging completeness in the Helicone dashboard and confirm that log storage, retention and access rules match your data policy. The step is done when the gaps you found have fixes and the comparison covers the models and applications that matter most to your business.
Cut over traffic to Helicone
Move all applications to the Helicone path in one change window per service, with a documented rollback that re-points the base URL or logging configuration to Portkey. Keep the Portkey keys active until the rollback window closes. Ask Mintlify, which announced on March 3, 2026 that it is acquiring Helicone, whether it offers help moving customers to another platform, and get the answer in writing with the support terms before you commit to a new platform. The step is done when every application logs to Helicone and the owners confirm their dashboards and alerts work.
Retire Portkey and document the new setup
Once the rollback window has passed, revoke Portkey keys, disable the Portkey workspace and confirm with Portkey how your data is deleted or retained under your contract. Record the Helicone architecture, upgrade process and owner in your runbooks, and set a schedule to review Helicone's release notes, since its latest tagged release is v2025.08.21-1 and the project is in maintenance mode. The step is done when the runbook and the decommission record are filed and a named owner accepts ongoing patching.
Questions buyers ask before switching from Portkey to Helicone
How much effort does self-hosting Helicone take compared with buying Portkey's managed tiers?
Self-hosting Helicone is a real platform deployment, not a single container. The README describes a Docker Compose setup for evaluation, and a production Helm chart for enterprise workloads is available by contacting Helicone. A self-hosted deployment runs a Next.js web frontend, a Cloudflare Workers proxy for logging, the Jawn log collection server, Supabase for the application database and auth, ClickHouse for analytics and MinIO for log object storage. Your team owns upgrades, backups, capacity and monitoring for every one of those components. Portkey's managed tiers move that work to the vendor, so the trade is platform labor against subscription fees. Confirm the Helm chart terms and supported versions with Helicone before you plan.
Can our own team run a Helicone deployment without outside help?
It depends on your skills and how many services you already operate. Teams that already run Kubernetes, PostgreSQL-compatible databases, ClickHouse and S3-style object storage can usually take on the stack with internal staff. Teams without those skills should expect a learning curve in the first release cycle. Ask yourself who will handle a ClickHouse disk-full event at 2 a.m., how Supabase auth will be configured for your identity provider, and who approves a Helicone version update. Outside help can cover design, hardening, backup and upgrade runbooks, or ongoing support on a retainer, all agreed in writing.
How long does a move from Portkey to Helicone take, and what sets that timeline?
No reliable duration can be stated without a defined scope, so treat any single number you hear with caution. The timeline is set by the number of applications that call the gateway, how many provider keys and routing rules you must recreate, how much historical log data you need to keep, and whether Helicone must sit behind your SSO and network controls. Changing the base URL in client code is often the small part of the work. Ask any provider, including DeployOpen, to break the timeline into discovery, deployment, cutover and validation phases with agreed exit criteria.
Does Helicone's move into maintenance mode affect the decision?
Yes, it should be weighed explicitly. Mintlify announced on March 3, 2026 that it is acquiring Helicone, and both companies say Helicone will continue in maintenance mode, with security updates, bug fixes and new models still shipping. Mintlify has offered to help customers move to another platform. For a self-hosted deployment, this means you can still run the Apache-2.0 code, but you should not expect a large roadmap of new features. Factor in the release cadence: the latest tagged GitHub release is v2025.08.21-1, published on August 21, 2025, so confirm current release activity directly before committing. Plan an exit path in case your needs change.
Does Helicone have direct equivalents for Portkey's enterprise features?
Only some of them, and the match is not one to one. Helicone covers routing with automatic fallbacks across 100+ models through an OpenAI-compatible API, request logging, traces and sessions, cost and latency tracking, a prompt playground and prompt versioning deployed through the gateway. Portkey lists prompt management, semantic caching, advanced logging and tracing, access control and PII redaction as enterprise features outside its open-source gateway. Check each one against Helicone's current documentation and your own tests. Semantic caching, PII redaction and fine-grained access control need a specific check before you assume parity. Where gaps remain, plan replacements such as separate guardrail or key management services.
What does a DeployOpen engagement need from our side to get started?
DeployOpen works on a fixed scope that is agreed in writing before any work starts, and the written scope sets deliverables and timelines. To scope a Helicone or gateway project, we typically need an inventory of the applications and providers that call Portkey today, the logging and retention requirements you must meet, the identity provider and network model you use, the hosting target (your cloud account, data center or air-gapped network), and the compliance evidence your assessors will ask for. Named owners on your side for security review and change approval shorten the path to a quote. Ongoing support and upgrades are available as a separate retainer.
Do prompts, logs and keys stay inside our network with each option?
A self-hosted Helicone deployment keeps logs, prompts and analytics in the components you run, including ClickHouse, MinIO and Supabase, inside your infrastructure. Check the outbound paths carefully, because the logging proxy runs on Cloudflare Workers in the reference design, so confirm how that component is hosted in your setup. Portkey's hybrid deployment places the gateway in your VPC, but its control plane stays in Portkey's VPC, and the gateway calls control.portkey.ai over HTTPS. Under that model, configuration and some operational data leave your network by design. Confirm the exact data flows with each vendor in writing before you approve either option.
Four decisions to settle before choosing
Four questions shape the Portkey vs Helicone choice before any feature comparison matters. Each one changes which product fits, what you run yourself, and what you pay for. Answer them in order, because the first two decide whether a hosted option is even allowed.
Where logs and config may live
Portkey's hybrid model keeps the gateway in your VPC but sends control plane traffic to control.portkey.ai over HTTPS. Helicone can be self-hosted entirely, with request logs in your own ClickHouse and MinIO. Ask your data protection and security teams whether prompts, responses, API keys and user identifiers may leave your network, and whether that answer differs by data class. If the answer is no, the hybrid tier is out and the comparison becomes self-hosted Helicone against an open gateway.
Which enterprise features you need
Prompt management, semantic caching, advanced logging, access control and PII redaction sit outside Portkey's MIT-licensed gateway. Helicone's README lists prompt versioning and a playground, but confirm the access controls, SSO and audit features you need against the current Helicone docs and your own test instance. List the features your teams use every week, then ask each vendor which tier provides them in writing.
Tolerance for a product in maintenance mode
Mintlify announced on March 3, 2026 that it is acquiring Helicone, and both companies say Helicone will continue in maintenance mode, with security updates, bug fixes and new models still shipping. If you adopt Helicone, your roadmap risk rises and your upgrade path depends on a small maintainer group. Decide whether your team can carry patches for features you need, and ask Mintlify how migration help would work if you later move.
Staffing for Kubernetes, databases and upgrades
A self-hosted Helicone deployment runs a Next.js frontend, a Cloudflare Workers proxy, the Jawn log server, Supabase for the application database and auth, ClickHouse for analytics, and MinIO for log storage. Portkey's hosted tiers move that work to the vendor. Count the people who will run backups, upgrades, ClickHouse capacity and incident response, and confirm whether your cluster team already operates these components. The Helm chart for enterprise workloads is available by contacting Helicone, so ask about its support terms before you plan.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. We help teams decide whether a self-hosted Helicone deployment fits their gateway, logging and prompt versioning needs, and we build it when it does.
How we scope
- We map your current Portkey routing, fallback, logging and prompt versioning use before recommending any target.
- We confirm which Helicone features your teams need, including the gateway base URL change or OpenLLMetry logging path.
- Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
How we build
- We deploy the Helicone stack from Docker Compose for evaluation, with its Next.js frontend, Cloudflare Workers proxy, Jawn server, Supabase, ClickHouse and MinIO components.
- We plan the production Helm path for enterprise workloads, confirming availability directly with Helicone before committing to it.
- We test routing, fallbacks and log capture against your real provider keys, and document the results for your security review.
How we hand over
- You receive architecture diagrams, configuration records, runbooks for backup and restore, and a list of the components your team must patch.
- We document how each application switches its base URL and how logs are verified after cutover.
- We walk your platform and security teams through the operating model so ownership of upgrades and key rotation is explicit.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Because Helicone is moving into maintenance mode, we help you track security updates and plan any later move to another platform.
- We can run periodic security testing of the gateway and its log stores as part of a retainer or separate fixed-scope engagement.
