Which open-source LLM gateway fits your team
Choose LiteLLM if you need per-key and per-team budgets on infrastructure you run yourself. Its LiteLLM virtual keys documentation describes keys that require a PostgreSQL database and support per-key, per-user and per-team budgets, TPM and RPM limits, and restriction to specific models. Once more than one proxy instance runs, LiteLLM's production guide calls for Redis 7.0 or newer for shared rate limits and router state. The MIT license covers everything outside the enterprise/ directory, but SSO beyond five users (from v1.76.0), SCIM, audit logs and organization RBAC sit under the Enterprise license. Map your SSO and audit requirements against that line before you commit.
Choose Portkey if you want a thin routing layer with fewer moving parts and can decide between self-running it and using the managed service. The gateway is MIT licensed, runs locally on port 8787 through npx or the portkeyai/gateway Docker image, and has a Cloudflare Workers deployment path. Fallbacks, retries and load balancing are defined in JSON configs attached to the client, which suits teams whose applications already own their routing logic. Secure key management with RBAC, PII redaction and caching are listed in its enterprise deployment, and Palo Alto Networks announced on May 29, 2026 that it had closed its acquisition of Portkey. Ask Portkey how the Gateway 2.0 pre-release, which merges enterprise gateway features into open source, will change your upgrade path, and which keys and budget controls work without a managed account.
Choose Kong AI Gateway if your team already operates Kong Gateway and wants LLM routing under the same control plane, policies and deployment tooling. The AI Proxy plugin ships in the Apache-2.0 open-source repository and needs Kong Gateway 3.6 or later. Load balancing across models, semantic routing and failover belong to AI Proxy Advanced, which is documented only in the enterprise offering and needs 3.8 or later. Platform teams that run Kubernetes without Kong should confirm the current name, scope and maturity of Envoy AI Gateway with the project before choosing it. In every option, the open-source line lacks some controls you may need for SSO, audit or failover, so price that gap into the decision.
Which LLM gateway fits each situation
This table matches common team situations to the gateway that fits best, with the reason and the check to run before choosing. Read it as a starting point, since several answers depend on your Kubernetes setup, database and whether you need paid features. The main takeaway is that for most gateways, enterprise controls such as SSO, audit logs and advanced routing are sold separately, so confirm the edition against each requirement.
| Scenario | Best fit | Why | What to confirm |
|---|---|---|---|
| Small team needing virtual keys and budgets quickly | LiteLLM (open source) | Virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits and model restrictions, but they need PostgreSQL. | Confirm you can run PostgreSQL, and whether your user count stays within the free SSO limit of 5 users. |
| Team that already runs Kong Gateway | Kong AI Gateway with the AI Proxy plugin | AI Proxy is open source and needs Kong Gateway 3.6 or later, so it reuses your existing gateway operations. | Confirm your Kong version. AI Proxy Advanced needs 3.8 or later and is available only in the Enterprise offering. |
| Team wanting a lightweight routing layer with minimal state | Portkey AI Gateway (open source) | MIT-licensed and runs locally or in Docker, with routing, retries and fallbacks set in JSON configs attached to the client. | Confirm whether you need virtual keys or budgets, since the open-source README does not list them. |
| Kubernetes platform team standardizing on Envoy-based routing | Envoy AI Gateway (now Agent Router), assessed separately | This page has no supplied facts on its features or licensing, so it cannot be ranked here against the other gateways. | Review its current documentation and license. If you already run Kong on Kubernetes, compare with its Ingress Controller. |
| Regulated team needing SSO, audit logs or RBAC | A paid tier: LiteLLM Enterprise or Kong AI Gateway Enterprise | LiteLLM Enterprise lists SSO and SCIM, audit logs, organization and team RBAC and IP allowlisting. Kong's advanced features are Enterprise-only. | Confirm which controls each edition includes, the identity providers supported and the audit log format before you request a quote. |
LLM gateway capabilities side by side
This table compares LiteLLM, Portkey AI Gateway, Kong AI Gateway and Envoy AI Gateway on license, provider coverage, keys and budgets, rate limits, failover, identity, observability and deployment. Read enterprise-only items as paid add-ons, and treat any cell marked for confirmation as an open question to put to the project or vendor before you commit.
| Capability | LiteLLM | Portkey AI Gateway | Kong AI Gateway | Envoy AI Gateway |
|---|---|---|---|---|
| License | MIT, except content under the enterprise/ directory, which has its own license | MIT licensed; Gateway 2.0 pre-release is merging the core enterprise gateway into open source | Kong Gateway open-source repository is Apache-2.0; AI Proxy Advanced is Enterprise only | Confirm the license and release status with the Envoy AI Gateway project |
| Provider coverage | More than 100 providers through the OpenAI request format, including OpenAI, Anthropic, Gemini, Bedrock and Azure | 1600+ language, vision, audio and image models through one API | AI Proxy covers OpenAI, Azure OpenAI, Bedrock, Anthropic, Gemini, Vertex AI, Cohere, Mistral, Hugging Face, Ollama and vLLM | Confirm the provider list and API format with the project |
| Virtual keys and budgets | Virtual keys per user, team or project with budgets; keys need PostgreSQL | Secure key management with role-based access control is listed in the enterprise deployment | Handled through Kong plugins and Konnect; confirm the exact key and budget features for your setup | Confirm whether key and budget management is included |
| Rate limits | Per-key, per-user and per-team TPM and RPM limits | Confirm rate-limit controls in the open-source gateway with Portkey | Rate limiting is a standard Kong plugin capability; confirm AI-specific token limits for your version | Confirm rate-limit support with the project |
| Fallbacks and retries | Retries, cooldowns and priority ordering for failover | Automatic retries and fallbacks configured through JSON configs | AI Proxy supports failover in AI Proxy Advanced (enterprise only) | Confirm failover behavior with the project |
| Load balancing | Simple-shuffle, usage-based, latency-based, least-busy and cost-based routing | Load balancing and conditional routing in JSON configs | AI Proxy Advanced adds round-robin, consistent-hashing, least-connections, lowest-latency, lowest-usage, semantic and priority balancing (enterprise only) | Confirm load-balancing options with the project |
| SSO and audit logs | SSO with Google, Entra ID, Okta and OIDC is free up to 5 users from v1.76.0; SCIM, audit logs and RBAC are Enterprise | Enterprise deployment adds RBAC and IP and geo rules; confirm SSO and audit logging for the open-source edition | Enterprise tier; confirm SSO and audit options in your Kong edition | Confirm identity and audit integration with the project |
| Observability hooks | Logging and team-level guardrails; team logging is Enterprise | Gateway Console for local logs; guardrails and caching listed in the README | Kong analytics and plugin logging; Konnect provides managed analytics | Confirm tracing and metrics export with the project |
| Minimum version for AI Proxy and AI Proxy Advanced | Not applicable | Not applicable | AI Proxy needs Kong Gateway 3.6 or later; AI Proxy Advanced needs 3.8 or later | Not applicable |
| Deployment modes | Python proxy on Kubernetes or VMs; one Uvicorn worker per pod recommended | npx locally, Docker, Node.js, Cloudflare Workers, Docker Compose or Portkey Cloud | DB-less, hybrid control and data planes, or PostgreSQL-backed; Kubernetes Ingress Controller available | Designed for Kubernetes platform teams; confirm installation and supported versions |
What each gateway is and how it is licensed
The four options differ less in what they route than in what they license as open source and what they keep behind a paid tier. Read each card for the license of the core, the latest supplied release, and the trade-off that most often changes the decision for a platform team.
LiteLLM
LiteLLM is both a Python SDK and a proxy server that exposes one OpenAI-compatible endpoint across more than 100 providers. The core is MIT licensed, but content under the enterprise/ directory uses its own license, so check which directories your deployment pulls in. Virtual keys, budgets and rate limits need PostgreSQL, and SSO is free only up to 5 users from v1.76.0, so confirm your user count before you plan around the free tier. Ask the vendor which features in your build sit under the enterprise license.
Portkey AI Gateway
The open-source gateway repository is MIT licensed and routes to 1600+ models through one API, configured with JSON attached to the client. Its latest tagged release is v1.15.2, published January 12, 2026. A Gateway 2.0 pre-release sits on a 2.0.0 branch, where Portkey's core enterprise gateway is merging into open source. On May 29, 2026, Palo Alto Networks announced it had closed its acquisition of Portkey, and that announcement does not address the open-source gateway, so ask Portkey how the 2.0 merge and the acquisition affect the repository you deploy.
Kong AI Gateway
Kong Gateway's open-source repository is Apache-2.0 licensed, and the AI Proxy plugin ships in that repository and needs Kong Gateway 3.6 or later. AI Proxy Advanced, which adds semantic routing, lowest-latency balancing and failover, is available only in Kong's AI Gateway Enterprise offering and needs 3.8 or later. Konnect, the managed platform, is a separate subscription. Teams already running Kong for APIs gain the most, provided they accept that the advanced routing features are paid.
Envoy AI Gateway (Agent Router)
Envoy AI Gateway is aimed at Kubernetes platform teams that already operate Envoy-based ingress and want LLM traffic handled in the same layer. This page does not hold a supplied license, version or release date for it, so confirm the current name (the project is listed here as now Agent Router), the license of its core, and its release cadence directly with the project before you shortlist it. Its strongest case is fit with an existing Envoy and Kubernetes estate, and its main risk is the naming change itself.
Where the open-source line sits in each gateway
LiteLLM is MIT licensed everywhere except its enterprise/ directory, which carries its own license in enterprise/LICENSE. That split matters for procurement: the enterprise directory is not OSI open source, so a team that deploys the proxy from the main repository is running MIT code, while any feature built from enterprise/ falls under a commercial term. Before you design a control around LiteLLM, check which code path supplies it. The admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and from v1.76.0 SSO is free for up to 5 users, with an Enterprise license needed beyond that. Confirm the user count you expect to reach, because a company-wide rollout crosses that line quickly.
Beyond the five-user SSO allowance, the LiteLLM Enterprise documentation places SCIM provisioning, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations (AWS, Azure, Google, HashiCorp Vault and CyberArk) and team-level guardrails and logging behind the paid license. Several of these are the controls a security reviewer asks for first, including audit trails and central deprovisioning. Ask the vendor for a written list of which of these are included in your edition and whether the LITELLM_MASTER_KEY handling and secret manager integration need the Enterprise tier.
Kong splits its gateway along a different line. The Kong Gateway repository is Apache-2.0, and the AI Proxy plugin ships in it and needs Kong Gateway 3.6 or later. AI Proxy Advanced, which adds load balancing modes such as lowest-latency and semantic routing and failover, is documented only in Kong's AI Gateway Enterprise offering and needs 3.8 or later. Konnect, Kong's managed analytics, service catalog and developer portal platform, is a subscription SaaS, so it is a separate operating decision from the self-hosted gateway. If your design depends on failover or semantic routing, treat AI Proxy Advanced as a paid dependency. Get the current enterprise entitlement list in writing from Kong and from LiteLLM before you commit to an architecture, because packaging changes between releases and this section reflects only the documented boundaries.
What each gateway needs to run in your environment
LiteLLM becomes the most stateful of the four gateways once you turn on virtual keys, budgets and rate limits. The platform team operates a PostgreSQL database, adds a Redis service once more than one proxy instance runs, and manages the master key. Plan these as standing services with backups, patching and on-call coverage. The LiteLLM production guide describes the recommended baseline.
- PostgreSQL as the primary database: Virtual keys require PostgreSQL, so keys, budgets and spend records live there. Back it up and test restores as you would for any system of record.
- Redis 7.0 or newer for multiple instances: Once more than one proxy runs, Redis holds shared rate limits, router state and cache. A single instance is simpler to run, but it does not share that state across proxies.
- One Uvicorn worker per pod: LiteLLM recommends one worker per pod on Kubernetes and horizontal scaling. The documented starting point is 1 vCPU and 4 GiB of memory per worker, which you should validate against your own traffic.
- Master key in a secret manager:
LITELLM_MASTER_KEYmust start withsk-. Keep it in a secret manager so it never lands in compose files or images, and write your own rotation procedure. - Spend batching at scale: At scale, LiteLLM batches spend updates to the database every 60 seconds. Ask how that delay affects budget enforcement for your traffic pattern.
Confirm the PostgreSQL and Redis versions, the high availability design for each, and the named owner for master key rotation before you choose a deployment model.
Portkey's open-source gateway is the lightest of the group to start. A local run needs Node.js tooling and a port, while shared deployments use Docker, Node.js or Cloudflare Workers. The enterprise deployment is where key management, role-based access control and PII redaction are described, so decide early which of those features you need and which edition includes them.
- Local start with npx: Running
npx @portkey-ai/gatewaystarts the gateway on port 8787 with a Gateway Console for local logs. This suits evaluation, and a shared service needs a deployment your team runs and monitors. - Docker and Docker Compose: The portkeyai/gateway image and Compose setup make the team responsible for the container host, TLS termination and the upgrade cadence.
- Node.js, Bun or Cloudflare Workers: Each listed path changes where the process runs and which platform team owns the layer underneath it.
- Enterprise key management and RBAC: The enterprise deployment adds secure key management with role-based access control, along with simple and semantic caching and IP and geo inbound rules.
- PII redaction and professional support: The enterprise deployment lists PII redaction and professional support. Confirm how redaction applies to logs and traces before you rely on it for regulated data.
Confirm which deployment path your security team will approve, which features your edition includes, and where the Gateway Console logs are stored. The deployment guide lists the supported paths.
Kong AI Gateway runs on Kong Gateway, so the platform team inherits Kong's deployment modes. The mode you choose decides whether you run PostgreSQL, split control and data planes, or neither. The AI plugins sit on top of that choice, and plugin support depends on the Kong Gateway release you pin. The Kong Gateway repository is the starting point for the release line.
- DB-less mode: Configuration is declarative and no database is required. It fits GitOps-managed clusters, but the team owns the configuration files and the rollout order.
- Hybrid mode: Control and data planes run separately. The team operates both planes, the connection between them and the certificates that secure it.
- PostgreSQL-backed mode: Kong stores configuration in PostgreSQL, so backups, upgrades and database capacity become part of the gateway runbook.
- Kubernetes Ingress Controller: Kong offers an Ingress Controller for Kubernetes. Confirm which controller version matches your cluster and your Kong Gateway release.
- Plugin version floors: AI Proxy needs Kong Gateway 3.6 or later. AI Proxy Advanced needs 3.8 or later and is documented only in the enterprise offering. The current open-source release line is 3.9, so pin the line you plan to run.
Confirm the deployment mode your platform team will operate, the Kong Gateway version you will pin, and whether your edition includes AI Proxy Advanced before you plan the upgrade path.
Envoy AI Gateway is included here for Kubernetes platform teams, but this comparison does not have verified operating details for it. Treat the list below as questions to settle with the project and with your own cluster team before you size anything. The project may appear under the name Agent Router, so confirm the current name and documentation first.
- Current name and release status: Confirm whether the project is published as Envoy AI Gateway, Agent Router or both, and which release line you would adopt.
- License and support terms: Confirm the license, whether a paid tier exists, and who provides support for the version you run.
- Stateful dependencies: Confirm whether the gateway needs a database or cache, and where keys, budgets and rate limits are stored.
- Cluster prerequisites: Confirm the supported Kubernetes versions, any Envoy-related controllers, and the ingress and certificate setup the project expects.
- Provider and telemetry coverage: Confirm which model providers are supported and which metrics, logs and traces the gateway exports to your existing monitoring stack.
Ask the project for its current deployment guide and a written list of prerequisites before your platform team commits to a sizing plan.
How to pilot a gateway before you commit
This sequence turns the comparison into a tested decision: you map your model traffic, define how keys and budgets work, prove failover and logging on two shortlisted gateways, and leave with written evidence for procurement and a clear choice between a managed and a self-run path.
Inventory providers, models and traffic patterns
List every model provider, model and application that will send requests through the gateway, along with expected request types (chat, embeddings, audio or image) and the teams that own each one. The platform or AI engineering lead compiles the list with application owners. Done means you have a table that shows which providers must be supported on day one and which request types the gateway must handle, so you can check each candidate against it rather than against a generic provider count.
Define the keys and budgets model
Write down how access will be granted and capped: who receives a key, whether keys attach to users, teams or projects, which models each key may call, and what spend, token and request limits apply. Security and finance sign off together. Confirm which of these features are free in each candidate and which sit behind an enterprise tier, because LiteLLM virtual keys need a PostgreSQL database and some governance features are enterprise-only. Done means a one-page policy that both candidates can be tested against.
Shortlist two gateways and record their licenses
Pick two candidates from LiteLLM, Portkey AI Gateway and Kong AI Gateway, based on the inventory and key model. For each, record the license of the code you will deploy, the edition that contains the features you need, and the release line you will pin. Kong's AI Proxy Advanced and LiteLLM's enterprise features are documented as paid, so note which ones your policy requires. Done means a signed-off comparison sheet with the license text reference and the pinned version for each candidate.
Run a pilot with failover and rate-limit tests
Deploy both candidates in a non-production environment in your own infrastructure, connect at least two providers, and test the behaviors that matter: a forced provider error to confirm fallback, a burst that exceeds a rate limit to confirm the cap holds, and a key that tries a model it is not allowed to call. Measure whether retries and cooldowns behave as the vendor documents. Done means a test log with request IDs, expected and observed results, and any gaps you must close with configuration or a workaround.
Check logging and observability hooks
Route test traffic into your existing logging and tracing stack and confirm that each request shows the key, team, model, provider, latency and error code, without storing prompt content you have not approved. Check that spend records can be exported and reconciled against provider invoices. Ask the vendor or maintainer to confirm the supported callback or export mechanisms for your stack, since these are not fully described in the supplied facts. Done means a screenshot or export for each candidate and a note on any fields you had to add yourself.
Test a migration from LiteLLM to Portkey
If LiteLLM is already in use or is a candidate, test how much work a move to Portkey would be. Portkey publishes a migrate-litellm-to-portkey skill that maps LiteLLM completion calls, Router, Proxy, fallbacks, retries and caching to Portkey client configs, and its checklist starts with a Portkey API key and providers configured in the Model Catalog. Use it as the reference: convert one representative route, rerun the failover tests from the previous step, and log every construct that does not map cleanly. Done means a migration diff and a list of manual changes, which is the true switching cost you will carry into any quote.
Confirm enterprise features in writing
For every capability your policy depends on, such as SSO, SCIM, audit logs, RBAC, secret manager integrations or semantic load balancing, obtain written confirmation from the vendor of which edition includes it, the minimum version, and the terms that apply to your deployment. Public documentation can change, so do not rely on a pilot screenshot alone. Done means a dated vendor statement attached to the decision record.
Estimate run cost and choose managed or self-run
List the cost components for each candidate: software license or subscription, the infrastructure it needs (for example PostgreSQL and Redis for LiteLLM at more than one proxy instance, per its production guide), staff time to operate upgrades and incidents, provider model spend, and any enterprise or managed fees. Separate one-time setup from recurring costs, and ask each vendor or partner for a quote built from this written scope. Then decide whether a managed service or a self-run deployment fits your team, and record the reason. Done means a cost sheet and a signed decision record that names the chosen gateway, the path, and the evidence supporting both.
What an open-source LLM gateway costs to run and who runs it
What does LiteLLM cost to license, and what does the paid tier add?
The core LiteLLM proxy and SDK are MIT licensed, so the software itself carries no license fee. Content under the enterprise/ directory uses its own license, and the enterprise documentation lists SSO and SCIM beyond the free limit, JWT authentication, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations and team-level guardrails. Per the LiteLLM admin UI documentation, SSO is free for up to 5 users from v1.76.0 and an Enterprise license is needed beyond that. Confirm current enterprise pricing directly with the vendor, because it is quoted per contract and is not in the sources reviewed here. Kong and Portkey follow different models: Kong's AI Proxy Advanced is only in its AI Gateway Enterprise offering, and Portkey's enterprise deployment adds key management, caching, PII redaction and professional support.
Can a small team run LiteLLM alone without outside help?
A small team with container and database experience can run LiteLLM alone for a single proxy instance, but the work grows once shared state and multiple instances enter the picture. LiteLLM's production guide names PostgreSQL as the primary supported database, and virtual keys need PostgreSQL. Once more than one proxy instance runs, the same guide requires Redis 7.0 or newer for shared rate limits, router state and cache. The team also has to manage the master key, which must start with sk- and belongs in a secret manager, and handle upgrades, since LiteLLM maintains support for the four most recent stable minor versions. Decide up front whether a named engineer owns on-call, upgrades and provider credential rotation, because those tasks recur long after the first deployment.
What do Redis and PostgreSQL add to day-to-day operations?
PostgreSQL stores virtual keys, budgets and spend records, so it becomes a stateful service that needs backups, restore testing, patching and capacity planning. Redis holds shared rate limits, router state and cache once you run more than one proxy instance, which means it becomes a dependency on the request path. LiteLLM's production guide recommends batching spend updates to the database every 60 seconds at scale, so spend reporting can lag behind real traffic. Ask your provider or internal platform team to define high availability for both services, failover behavior, and who restores them after an incident. These components are usually the largest recurring operating cost after staff time, and they are often already run by the platform team, which lowers the marginal cost.
How hard is it to migrate from LiteLLM to another gateway?
The effort depends mainly on how much of your traffic relies on LiteLLM-specific features such as virtual keys, budgets, router configuration and fallbacks. Portkey publishes a migrate-litellm-to-portkey skill that maps completion calls, Router, Proxy, fallbacks, retries and caching to Portkey client configs, and its checklist starts with a Portkey API key and providers set up in its Model Catalog. Kong's AI Proxy plugin works through Kong Gateway configuration, so a move there also changes how keys and routes are managed. Budgets, per-team keys and spend history rarely map one to one, so plan a parallel run, export spend data before cutover and test fallback behavior against each provider you use. Ask any vendor for a written migration plan that lists these mappings.
What does a DeployOpen gateway engagement cover?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a gateway, a typical written scope would define the platform version, provider connections, virtual key and budget model, identity integration, the PostgreSQL and Redis topology, observability hooks, backup and restore tests, and runbooks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. DeployOpen does not publish a price list, so a quote follows from the written scope.
What should I ask for in a written quote for a gateway deployment?
Ask for a quote that separates one-time work from recurring costs. The one-time items usually include architecture design, installation, provider and identity configuration, hardening, migration of existing keys or configs, and documentation. The recurring items usually include upgrades, monitoring, backups, on-call coverage and provider or license renewals. Request the license tier you assume, the number of proxy instances, the database and Redis hosting model, and which environments are covered. Ask which test cases are included for fallbacks, rate limits and budget enforcement, and what acceptance criteria close the work. Confirm which costs sit outside the quote, such as cloud hosting, provider token spend and any vendor enterprise license.
What drives the time for a gateway pilot?
No supplied fact gives a pilot duration, so the timing depends on the factors you control. The main drivers are how many providers you connect, whether identity and SSO integration are required on day one, how many teams need separate virtual keys and budgets, and whether PostgreSQL and Redis already exist in your platform. Security review, change approval and access to provider accounts often take longer than the technical setup. Provider contracts and data handling terms can also delay the first live request. Ask any implementation partner to state the pilot's entry criteria, the environments involved and the approvals they depend on, then agree the timeline in writing before work starts.
How DeployOpen scopes gateway selection and rollout
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For LLM gateways, that means starting from your provider mix, key and budget model, and identity setup, then agreeing the written scope before any build work begins.
How we scope
- Inventory the model providers, teams and applications that will send traffic through the gateway.
- Decide the key model: virtual keys per user, team or project, and where budgets and rate limits sit.
- Record which license tier your identity, audit and guardrail requirements need, and confirm it with the vendor in writing.
- Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy the chosen gateway in your environment, including its database and cache dependencies for shared state.
- Configure provider connections, fallbacks, retries and routing rules, and test failover behavior against your own workloads.
- Wire gateway logs and metrics into your existing observability stack and verify that keys and secrets stay in your secret manager.
- Run security testing on the gateway endpoints, including key handling, authentication paths and access controls, before go-live.
How we hand over
- Document the architecture, configuration, key lifecycle and budget policies so your team can operate the gateway without us.
- Provide runbooks for upgrades, backups, scaling and the license-specific features you chose to use or avoid.
- Deliver compliance-readiness evidence, such as configuration records and access logs, for your own auditors to assess.
- Walk your operators through the handover and confirm the gateway version and support window your team will maintain.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Retainers can cover version upgrades when new gateway releases change routing, authentication or license terms.
- Re-run security testing after provider, key or identity changes so access controls keep matching the approved design.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
