Side by Side
At a Glance
15 dimensions of comparison between Naftiko and Solo.io — same row, different layer of the stack. Scan top-to-bottom to see where each product makes a different choice on the same axis.
Dimension
Naftiko
Solo.io
Category
Naftiko
Spec-driven integration platform
Solo.io
AI-native networking platform — kgateway (API GW) + Istio (mesh) + agentgateway (AI GW + MCP) + kagent (agent runtime) + agentregistry (MCP catalog)
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Solo.io
Solo.io, 2017 — Envoy-native gateway pioneer; Idit Levine; donated agentgateway to Linux Foundation Aug 2025
Primary primitive
Naftiko
Capability — declared in YAML; consumes + exposes
Solo.io
CRD — 21+ Kubernetes CRDs across gateway.solo.io, gloo.solo.io, enterprise.gloo.solo.io, ratelimit.solo.io, agentgateway.dev, kagent.dev
Layer in the stack
Naftiko
Build-time + ship-time + runtime engine that authors integrations
Solo.io
Runtime data plane + control plane on Envoy — north-south (kgateway), east-west (Istio), AI traffic (agentgateway), agent runtime (kagent)
Core artifact
Naftiko
YAML capability spec (declarative, multi-protocol)
Solo.io
Kubernetes CRDs reconciled by Solo controllers into Envoy xDS
Open source posture
Naftiko
Apache 2.0 Framework, free Fleet community, paid Standard / Enterprise
Solo.io
Open-source foundation (Gloo, Istio contributions, Ambient Mesh, agentgateway donated to LF) + Solo Enterprise commercial layer (Gloo Mesh, advanced auth, rate limits, multi-cluster)
Multi-protocol exposure
Naftiko
REST + MCP + Skills + Webhooks + A2A — same capability, all protocols
Solo.io
kgateway brokers REST/gRPC/TCP via Envoy; agentgateway brokers MCP + OpenAI/Anthropic/Bedrock/Vertex/Ollama/vLLM; service mesh brokers internal HTTP/gRPC
AI gateway posture
Naftiko
exposes: mcp on any capability; LLM access via consumed APIs
Solo.io
agentgateway is a first-class CRD-driven AI gateway with native MCP + every major LLM provider as a Backend kind
MCP support
Naftiko
Every capability can expose MCP from a single spec
Solo.io
AgentgatewayBackend type=mcp + agentregistry catalog + agentgateway authorization patterns documented for multi-tenant scenarios
Governance scope
Naftiko
Design-time (Spectral lint), admission (Kyverno / OPA), runtime engine
Solo.io
Runtime — AuthConfig (OIDC/JWT/API key/OPA), RateLimitConfig (Envoy ratelimit service), AgentgatewayPolicy (guardrails/MCP ACLs), mTLS via Istio
Discovery surface
Naftiko
Backstage capability catalog + scorecards + apis.io
Solo.io
agentregistry (MCP server catalog) + Upstream CRDs as backend inventory; Solo Connect dev portal for API consumers
Audit / observability
Naftiko
OpenTelemetry + Prometheus + structured logs from every capability container
Solo.io
OpenTelemetry across kgateway, agentgateway, Istio mesh; Envoy access logs; per-agent OTel from kagent
Identity / OAuth
Naftiko
Runtime secret injection (env, ExternalSecrets); Keycloak / OpenFGA roadmap
Solo.io
AuthConfig CRD — OIDC, OAuth 2.0, JWT, API key, OPA, passthrough; mTLS for east-west via Istio
Cost / FinOps
Naftiko
Cost-center labels propagated to K8s; Kubecost integration
Solo.io
FOCUS-aligned metering (api_requests + data_egress + compute_seconds); cost allocation by team / environment / application / feature
Founder framing
Naftiko
“Capability fleet” — many ships, one navy
Solo.io
“The AI Native Networking Company”
Common Ground
Where They Overlap
Both Naftiko and Solo.io bet on the layer above per-vendor MCPs. Here are the 8 concrete places where those bets actually meet — same problem, sometimes the same shape, increasingly the same conversation.
1
Both treat MCP as a first-class protocol
Solo's agentgateway ships AgentgatewayBackend type=mcp + agentregistry as the catalog + documented authorization patterns for multi-tenant MCP. Naftiko exposes any capability as MCP via
exposes: mcp. Both refuse the ‘MCP is an afterthought’ default that legacy gateway vendors fell into.2
Both ship Envoy / Kubernetes-native infrastructure
kgateway routes ingress via Envoy and Kubernetes Gateway API; agentgateway uses Envoy for AI traffic. Naftiko Fleet ships a Kubernetes operator + NaftikoCapability CRD; the engine deploys as Kubernetes Deployments. Both target the cloud-native data plane, not the legacy VM gateway.
3
Both bet on the open-source-plus-enterprise model
Solo open-sourced Gloo, contributed to Istio, and donated agentgateway to Linux Foundation in Aug 2025. Naftiko Framework is Apache 2.0; Fleet community is free; Standard / Enterprise tiers layer on. Both refuse the closed-SaaS-only default.
4
Both have an AI-provider broker concept
Solo's AgentgatewayBackend supports OpenAI, Anthropic, Bedrock, Vertex, Ollama, and vLLM as first-class providers. Naftiko's capabilities consume any LLM via the consume block. Both refuse the ‘customers wire OAuth tokens per LLM in app code’ anti-pattern.
5
Both publish FinOps-aware metering
Solo's FinOps file meters api_requests + data_egress + compute_seconds with FOCUS-aligned cost allocation. Naftiko propagates cost-center labels into Kubecost for per-call attribution. Both refuse the ‘no per-call cost visibility’ anti-pattern.
6
Both have a delegated multi-team routing model
kgateway's RouteTable + RouteOption supports delegated routing where platform teams own the gateway and product teams own their routes. Naftiko Fleet composes capabilities across teams; capabilities compose via DDD aggregate patterns. Both refuse the ‘one team owns everything’ anti-pattern.
7
Both ship multi-cluster surface as a first-class concern
Solo Enterprise for Istio + Gloo Mesh is built for multi-cluster service connectivity with Ambient Mesh and unified policy. Naftiko Fleet treats capability deployment as cross-cluster topology with shared rules engine evaluated at IDE + CI + admission time. Both refuse the ‘one cluster fits all’ default.
8
Both publish standards-aligned artifacts upstream
Solo publishes OpenAPI + JSON Schema + JSON-LD via api-evangelist/solo + donated agentgateway to Linux Foundation. Naftiko publishes capability YAML + Spectral rulesets + capability catalog at apis.io. Both refuse to keep the contract layer proprietary.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Solo runs the AI-native data plane on Envoy + Kubernetes (kgateway routes APIs, agentgateway routes AI traffic, Istio routes east-west, kagent runs the agents, agentregistry catalogs MCP). Naftiko writes the artifact that lives on top of that data plane. Different bets — Solo for the networking substrate; Naftiko for the spec layer that authors and governs every adapter the substrate routes.
1
Spec-driven authoring vs CRD-driven runtime
Naftiko
Author capabilities as YAML — the spec is the artifact; the engine reads it and runs as a container. Same spec lands every protocol.
Solo.io
Author Kubernetes CRDs reconciled by Solo controllers into Envoy xDS. The CRD is the artifact; the data plane is the runtime.
Same direction (declarative) at different altitudes — Naftiko at the integration spec layer, Solo at the K8s data-plane layer.
2
Open-source-self-hosted engine vs OSS-foundation + commercial-enterprise
Naftiko
Apache 2.0 Framework runs in your container, your Kubernetes, your VPC. Open-source is the engine.
Solo.io
Open-source foundation projects (Gloo, Istio, Ambient Mesh, agentgateway) with Solo Enterprise commercial layer for multi-cluster, advanced auth, rate limits, dedicated support.
3
Multi-protocol expose via spec vs multi-product expose via CRD
Naftiko
One capability YAML exposes REST + MCP + Skills + Webhooks + A2A simultaneously from a single spec.
Solo.io
kgateway exposes REST/gRPC/TCP. agentgateway exposes MCP + LLM providers. Service mesh exposes east-west HTTP/gRPC. Three products, three CRD surfaces, three data planes.
4
Capability primitive vs CRD primitive
Naftiko
Primary identity is ‘the thing that does X’ — composed from consumes and exposes, versioned as a YAML artifact, deployed as a container.
Solo.io
Primary identities are CRDs (Gateway, VirtualService, Upstream, AuthConfig, RateLimitConfig, AgentgatewayBackend, AgentgatewayPolicy, Agent, Team) reconciled by Solo controllers into Envoy data plane.
5
Design-time + admission-time + runtime governance vs runtime-only governance
Naftiko
Spectral rulesets at design time (IDE + CI), Kyverno / OPA at admission time, runtime checks in the engine. Lifecycle-shaped governance.
Solo.io
Governance is runtime — AuthConfig + RateLimitConfig + AgentgatewayPolicy + mTLS enforced by Envoy at the data plane. No spec-layer design-time policy layer for the integration spec itself.
6
Capability container as runtime unit vs Envoy/Istio as runtime unit
Naftiko
Each capability runs as a Docker container with the engine — capability container is the unit of deployment, observability, and cost attribution.
Solo.io
Envoy sidecars / Ambient Mesh waypoint proxies are the runtime unit — Envoy is what runs, Solo controls it via xDS from a control plane.
7
Bring-your-own integration depth vs Envoy-native + AI-provider catalog
Naftiko
Author any integration as a capability — consume side is bring-your-own.
Solo.io
kgateway Upstream supports services + Lambda + AI providers as first-class backends; agentgateway ships OpenAI/Anthropic/Bedrock/Vertex/Ollama/vLLM as Backend kinds.
8
Enterprise integration team vs platform-engineering + cloud-native ops
Naftiko
Sally the Integration Engineer at a regulated enterprise — many APIs, many domains, many cost centers, governance is the load-bearing concern.
Solo.io
Platform engineering + SRE teams running Kubernetes at scale — many clusters, many namespaces, many services, networking + identity + mesh are the load-bearing concerns.
Partnership Thesis
Service Partnership
Naftiko is the spec-driven authoring engine. Solo.io is the AI-native networking data plane. The capability map below treats every Solo CRD surface as a Naftiko-consumable target: every VirtualService, Upstream, AuthConfig, RateLimitConfig, AgentgatewayBackend, AgentgatewayPolicy, agentregistry entry, and kagent Agent gets a matching Naftiko capability that publishes the Solo-shape artifact from the Naftiko spec layer. Naftiko authors; Solo routes.
“Naftiko brings the spec layer, the multi-protocol exposure, and the open-source authoring engine. Solo brings the Envoy + Kubernetes data plane that routes north-south (kgateway), east-west (Istio), AI traffic (agentgateway), agent workloads (kagent), and MCP discovery (agentregistry). Together: a Naftiko capability YAML becomes an end-to-end governed, observed, multi-protocol surface on Solo's Envoy-native runtime — without the customer authoring a single CRD.”
Two First-Meeting Questions
Q1. Agentgateway as the Naftiko MCP runtime
Would Solo support a documented ‘wrap me as an AgentgatewayBackend’ pattern — where every Naftiko
exposes: mcp capability auto-publishes the matching AgentgatewayBackend + AgentgatewayPolicy CRDs into a Solo cluster? The capability map below already includes that capability; codifying it would mean every Naftiko-authored MCP server lands as a Solo-governed MCP runtime without the customer authoring Kubernetes CRDs manually. Given agentgateway is now in Linux Foundation, the integration story extends across every adopter — not just Solo customers.Q2. agentregistry as the cross-fleet MCP catalog
Would Solo open agentregistry to Naftiko-authored MCP server registrations so the catalog includes capabilities authored anywhere a Naftiko engine runs — not only the ones running inside a Solo-managed cluster? Today agentregistry catalogs MCP servers Solo's data plane brokers; widening that to any Naftiko-exposed MCP would compound Solo's catalog breadth and give Naftiko Fleet a federated discovery surface across multi-cluster + multi-vendor topologies.
Integration Kit
Partnership Capability Map
11 Naftiko capabilities authored to integrate with Solo.io as a service partner. Each one consumes a specific Solo.io surface and exposes it as REST + MCP through the Naftiko engine — shipped as inline alpha2 YAML in the api-evangelist repository and published to the apis.io capability catalog.
Solo kgateway VirtualService Publish
solo-kgateway-virtualservice-publish
Publish Naftiko REST adapters as Solo kgateway VirtualService CRDs so the gateway routes ingress to the Naftiko adapter through Envoy with auth, rate limits, and transformations layered on top.
Solo kgateway Upstream Discovery
solo-kgateway-upstream-discovery
Walk Solo kgateway Upstream CRDs into Naftiko Fleet discovery so every K8s service, Lambda function, and AI provider backend lands in the Naftiko catalog.
Solo kgateway AuthConfig Sync
solo-kgateway-authconfig-sync
Sync Naftiko capability auth declarations (OIDC, API key, OPA) with Solo kgateway AuthConfig CRDs so the gateway enforces the same identity policies Naftiko declares at the spec layer.
Solo kgateway RateLimit Sync
solo-kgateway-ratelimit-sync
Sync Naftiko rate-limit policies with kgateway RateLimitConfig CRDs so Envoy enforces the same numbers Naftiko declares at the capability spec layer.
Solo kgateway Route Management
solo-kgateway-route-management
Manage kgateway RouteTable + RouteOption CRDs so Naftiko Fleet's multi-team composition lands as delegated routing trees with per-route policies attached.
Solo agentgateway Backend Publish
solo-agentgateway-backend-publish
Publish Naftiko-built MCP servers and LLM proxies as Solo agentgateway Backend CRDs so the AI gateway brokers, governs, and observes traffic with auth + guardrails + token tracking in place.
Solo agentgateway Policy Sync
solo-agentgateway-policy-sync
Sync Naftiko governance (guardrails, MCP tool ACLs, PII filters) with AgentgatewayPolicy CRDs so AI traffic governance enforces at the gateway what Naftiko declares at the spec.
Solo agentregistry MCP Publish
solo-agentregistry-mcp-publish
Publish Naftiko-built MCP servers + tools to Solo's agentregistry catalog so kagent + every other Solo-platform agent can discover and route to Naftiko MCP through the governed catalog.
Solo kagent Agent Deploy
solo-kagent-agent-deploy
Manage Solo kagent Agent + Team CRDs so Naftiko-authored agent capabilities deploy into Kubernetes as kagent workloads with OTel observability, RBAC, and connections to agentgateway.
Solo Istio Multi-Cluster Bridge
solo-istio-multicluster-bridge
Bridge Naftiko Fleet topology to Solo Enterprise for Istio / Gloo Mesh multi-cluster routing so east-west traffic to Naftiko-exposed adapters works across clusters and Ambient Mesh waypoints.
Solo FinOps Bridge
solo-finops-bridge
Pull Solo's FOCUS-aligned metering (api_requests + data_egress + compute_seconds) into Naftiko's per-call cost attribution so every gateway-routed capability carries unified cost labels through to Kubecost.
