Side by Side
At a Glance
14 dimensions of comparison between Naftiko and Kong — 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
Kong
Category
Naftiko
Spec-driven integration platform
Kong
API gateway + Konnect SaaS control plane + AI Gateway + Agent Gateway + Event Gateway + Mesh
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Kong
Augusto Marietti + Marco Palladino, 2009 (as Mashape) — rebranded Kong Inc., 2017
Primary primitive
Naftiko
Capability — consumes APIs, exposes REST / MCP / Skills / A2A
Kong
Service / Route / Plugin / Consumer — Lua/Nginx-runtime entities at the gateway
Layer in the stack
Naftiko
Build-time + ship-time + runtime engine that creates the artifact
Kong
Runtime data-plane gateway + SaaS control plane — governs traffic to artifacts
Core artifact
Naftiko
YAML capability spec (declarative, alpha2)
Kong
decK declarative config + Konnect API Products + Plugins + 20+ Konnect sub-APIs
Open source posture
Naftiko
Apache 2.0 Framework, free Fleet community edition, paid Standard / Enterprise
Kong
Apache 2.0 Kong Gateway + Insomnia + Mesh (Kuma); Konnect, AI Gateway, Agent Gateway, Event Gateway are paid SaaS
Multi-protocol exposure
Naftiko
REST + MCP + Skills + A2A (roadmap) — same capability, all protocols
Kong
HTTP/1/2/3, gRPC, WebSocket, TCP, UDP, Kafka (Event Gateway), MCP (AI Gateway), A2A (Agent Gateway)
Governance scope
Naftiko
Design-time (Spectral lint), admission (Kyverno / OPA), runtime engine
Kong
Runtime: 100+ plugins (rate-limit, JWT, OAuth2, OIDC, mTLS, PKI, transforms, OpenTelemetry, Prometheus); AI plugins (semantic cache, token budget, prompt firewall, PII guardrails)
Discovery surface
Naftiko
Backstage capability catalog + scorecards
Kong
Konnect Service Catalog (with scorecards) + Developer Portal + API Products + MCP Registry + Context Mesh (auto-discover APIs → MCP)
Audit / observability
Naftiko
OpenTelemetry + Prometheus + structured logs
Kong
OpenTelemetry tracing + Prometheus + per-token observability + per-agent cost allocation + audit logs (Konnect)
Identity / OAuth
Naftiko
Runtime secret injection (env, ExternalSecrets); Keycloak / OpenFGA roadmap
Kong
API Key, Basic, Digest, JWT, OAuth2, OIDC, mTLS/PKI, ACLs; agent identity (Agent Gateway); OIDC-aware ACLs (Event Gateway)
AI / MCP posture
Naftiko
Builds MCP servers, REST APIs, Agent Skills from existing APIs
Kong
Routes traffic to LLMs (universal LLM API across OpenAI / Anthropic / Gemini / Bedrock / Azure / Mistral / HuggingFace) + governs MCP traffic + discovers MCPs (MCP Registry, Context Mesh)
Cost / FinOps
Naftiko
Cost-center labels propagated to K8s; Kubecost integration
Kong
Per-gateway-month + per-1M-request overage + per-LLM-model add-on + per-portal + per-published-API metering
Founder framing
Naftiko
“Capability fleet” — many ships, one navy
Kong
“The AI Connectivity Company” — “In the Context Economy, Context is King”
Common Ground
Where They Overlap
Both Naftiko and Kong 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 AI/MCP as governed first-class traffic
Kong AI Gateway 3.14 ships a universal LLM API across OpenAI / Anthropic / Gemini / Bedrock / Azure / Mistral / HuggingFace with semantic caching, token budgets, prompt firewalls, PII guardrails, and per-agent cost allocation. Kong MCP Registry (Feb 2026) catalogs MCP servers with governance gates. Naftiko exposes capabilities as MCP servers and routes LLM calls through governed adapters. Same outcome from opposite ends of the wire.
2
Both ship a developer-portal / discovery surface
Kong Konnect ships Developer Portals + API Products + Service Catalog + MCP Registry + Context Mesh (auto-discovers APIs and turns them into MCP). Naftiko Fleet integrates Backstage with capability scorecards and a fabric explorer. Both want developers and machines to find what is shippable in one place.
3
Both apply governance through declarative policy chains
Kong runs ordered Plugins attached to Service / Route / Consumer scopes (rate-limit, jwt, oauth2, oidc, transforms, OpenTelemetry, etc.) — 100+ in the catalog. Naftiko applies Spectral rules + OPA + runtime checks per consume / expose. Different syntax, similar shape: declarative policy chains, not imperative code.
4
Both support OpenTelemetry + Prometheus out of the box
Naftiko emits OTel events from every capability container. Kong exports OpenTelemetry tracing + Prometheus metrics + structured access logs from the gateway data plane and Konnect control plane. Audit and metric signals can land in the same downstream observability stack without rework.
5
Both ship multi-cluster / multi-environment governance
Kong Konnect aggregates Control Planes and Runtime Groups across regions and clusters, with hybrid-cloud data planes governed by a single SaaS control plane. Naftiko Fleet’s NaftikoFabricExplorerPage aggregates capability dependency graphs across fabrics. Both target the same enterprise pain.
6
Both treat Kafka / event streams as governed first-class traffic
Kong Event Gateway (April 2026) governs Kafka with virtual clusters, identity-aware ACLs, per-topic quotas, mTLS, and schema-registry integration. Naftiko's roadmap includes async / event-driven exposes for skill invocation and result streaming. Both refuse to treat Kafka as “just plumbing”.
7
Both have a service-mesh / runtime-fabric story
Kong Mesh (built on Kuma + Envoy) provides zero-trust mTLS, multi-zone service discovery, and traffic policies across services. Naftiko's capability runtime — when deployed on Kubernetes — sits on the same fabric layer as a service mesh and benefits from one. Different products, complementary primitives.
8
Both are aggressively positioning against ungoverned vendor MCPs
Kong MCP Registry exists because vendors’ raw MCP endpoints aren’t enterprise-shaped — no identity, no audit, no token caps, no approval gates. Naftiko’s entire wedge is “vendor MCPs are too generic for context-engineering.” Different solutions, identical thesis.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Naftiko builds the MCP servers, REST APIs, and Agent Skills that Kong governs, routes, registers, and meters. Naftiko is the artifact factory; Kong is the AI-connectivity runtime. They sit on the same release path, not the same shelf.
1
Build-the-artifact vs govern-the-artifact
Naftiko
Take an existing API (Bloomberg AIM, GitHub, SAP) and ship it as a governed MCP server / REST API / Skill. The capability YAML is the new endpoint.
Kong
Govern HTTP / gRPC / Kafka / MCP / LLM / A2A traffic to backend services that already exist. The Service + Route + Plugin chain describes the policed path to an existing endpoint.
Naftiko has no gateway story; Kong has no API-builder story. Two different layers of the same release.
2
Multi-protocol exposure vs multi-protocol mediation
Naftiko
A single capability serves REST (humans + tools), MCP (AI agents), Agent Skills (skill-bundle agents), and A2A (roadmap) from one YAML and one container.
Kong
Konnect mediates HTTP, gRPC, Kafka, MCP, LLM, and A2A — but those protocols are destinations for traffic, not outputs of an authored spec.
3
Capabilities as the primitive vs Service / Route / Plugin / Consumer as the primitives
Naftiko
Primary identity is “the thing that does X” — a functional unit with declared consumes and exposes.
Kong
Primary identities are gateway-shaped routing entities and policy chains over backend Services.
Naftiko reasons in business-domain capabilities; Kong reasons in network-shaped routing primitives.
4
Source-side governance vs gateway-side governance
Naftiko
Governs the consume side — HTTPS enforcement, PII detection on consumed APIs, credential governance, retry safety per upstream. Owns the supply chain.
Kong
Governs the gateway — JWT / OAuth2 / OIDC / mTLS, rate-limit, transforms, AI guardrails, semantic cache, token budgets, prompt firewall, A2A policy. Owns the regulated boundary.
5
Capability YAML vs decK + 20+ Konnect sub-APIs as the source of truth
Naftiko
One declarative YAML spec drives the engine, the validation pipeline, the operator, the governance, and the runtime topology — same file from author to ops.
Kong
decK declarative config for the gateway data plane plus a ~1.9MB Konnect OpenAPI 3.1 spec stitching 20+ sub-APIs (Catalog, Control Plane, API Products, Dev Portal, Identity, Analytics, Audit, Event Gateway, MCP Registry, Mesh, Metering, Notifications, Search) — composable but operationally chunkier.
6
Builds Agent Skills as a first-class output vs builds nothing, governs everything
Naftiko
exposes: skill ships an Agent Skills bundle alongside the capability’s MCP and REST surface — same spec, three artifacts.Kong
MCP Registry catalogs MCPs, AI Gateway brokers LLM calls, Agent Gateway governs A2A — but doesn’t produce skill bundles, MCP servers, or REST APIs from spec. Kong assumes the artifacts already exist.
7
Discovery as authoring (Naftiko) vs discovery as transformation (Kong Context Mesh)
Naftiko
OpenAPI / AsyncAPI / Postman / HAR ingest → Naftiko capability YAML → MCP + REST + Skill output. Spec-driven authoring, deterministic compile.
Kong
Kong Context Mesh (Feb 2026, tech preview) auto-discovers enterprise APIs and transforms them into agent-consumable MCP definitions with inherited Konnect access controls. Discovery-driven transformation, runtime-side.
Both turn APIs into MCP, but from opposite ends — Naftiko at author-time from a spec, Kong at runtime from network discovery.
8
Open-source-first vs OSS-gateway-with-commercial-Konnect
Naftiko
Apache 2.0 Framework, intended to land in CNCF, with paid Fleet editions on top. Open-source is the engine; commercial wraps governance + ops around it.
Kong
Apache 2.0 Kong Gateway + Insomnia + Mesh / Kuma (very deep). Konnect, AI Gateway, Agent Gateway, Event Gateway, MCP Registry, Context Mesh, Service Catalog are SaaS-only. Open-source is the data plane; commercial is the AI / agent / portal / catalog layer.
Partnership Thesis
Service Partnership
Naftiko is the artifact factory. Kong is the AI-connectivity runtime. A Naftiko capability that ships a REST or MCP expose is the natural upstream service for a Kong Service + Route + Plugin chain, an MCP Registry entry, an AI Gateway backend, an API Product in a Konnect Developer Portal, and an Agent Gateway-registered agent — all on the same release. The capability map below wires the Naftiko-built artifact into every Kong surface it can plug into.
“Naftiko ships the MCP servers, REST APIs, and Agent Skills your enterprise needs. Kong governs the gateway, brokers the LLM tokens, registers the MCPs, governs the A2A messages, manages the consumer identities, and meters every call. Together: the artifact-and-AI-connectivity stack for the agentic era.”
Two First-Meeting Questions
Q1. Naftiko-built MCP behind Kong MCP Registry
Would Kong include a “register a Naftiko-built MCP” quickstart in the MCP Registry docs — pointing at the Naftiko exposes:mcp adapter as the canonical way to put a new governed MCP server behind the registry, with approval gates and per-tool observability inherited automatically? Naftiko produces MCPs from spec; Kong governs MCP discovery, identity, and AI token spend; the join point is a one-page docs section.
Q2. Naftiko-as-API-source for Kong Konnect
Would Kong consider a documented “Naftiko as the upstream API source” pattern in Konnect — where every Naftiko-built REST capability lands automatically as a Kong Service + Route, gets a Konnect API Product, ships into a Developer Portal, and joins the Service Catalog with maturity scorecards on the same release? The capability map below treats every Konnect surface as a Naftiko-publishable target for exactly this reason.
Integration Kit
Partnership Capability Map
11 Naftiko capabilities authored to integrate with Kong as a service partner. Each one consumes a specific Kong 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.
Kong Services Discovery
kong-services-discovery
Pull live Service, Route, Upstream, and Target inventory from a running Kong Gateway via the Admin API into Naftiko Fleet — Backstage sees what the gateway is currently routing to alongside Naftiko-declared capabilities.
Kong Routes Publish
kong-routes-publish
When a Naftiko capability ships a REST expose, publish the matching Kong Service + Route via the Admin API so the gateway starts routing traffic to the new capability on the same release.
Kong Plugins Management
kong-plugins-management
Author and manage Kong Gateway Plugins (rate-limit, JWT, OAuth2, OIDC, transforms, OpenTelemetry, Prometheus) attached at global / Service / Route / Consumer scope from Naftiko's declarative spec layer — one spec, two systems wired up.
Kong Consumers Management
kong-consumers-management
Manage Kong Consumers (the consumer-side identity surface — API keys, JWT credentials, OAuth2 clients, basic-auth users, ACL groups) from Naftiko spec, in lockstep with the Service / Route / Plugin chain Naftiko ships.
Kong AI Gateway Bridge
kong-ai-gateway-bridge
Route Naftiko-side LLM calls through Kong AI Gateway's universal LLM API (OpenAI / Anthropic / Gemini / Bedrock / Azure / Mistral / HuggingFace) — automatic semantic caching, token budgets, prompt firewalls, PII guardrails, RAG injection, per-token observability.
Kong MCP Registry Publish
kong-mcp-registry-publish
Publish Naftiko-built MCP servers and tools into Kong MCP Registry so Kong governs discovery, approval gates, and per-tool usage observability on agent-to-MCP traffic in front of them.
Kong Service Catalog Publish
kong-service-catalog-publish
Publish Naftiko-built capabilities into the Kong Konnect Service Catalog with resources, scorecards, and API mappings — every Naftiko capability appears in the same catalog Konnect uses to track maturity and ownership across the API estate.
Kong Dev Portal Publish
kong-dev-portal-publish
Publish Naftiko-built REST exposes into a Kong Konnect Developer Portal as API Products with versioning, plans, and branded developer-facing surfaces — Naftiko's spec becomes a discoverable, subscribable API in the same portal Konnect uses for the rest of the estate.
Kong Event Gateway Bridge
kong-event-gateway-bridge
Manage Kong Event Gateway virtual Kafka clusters, listener policies, identity-aware ACLs, and per-topic quotas from Naftiko spec — Naftiko-side event-driven workflows pick up Kong's Kafka governance (mTLS, OIDC ACLs, schema-registry validation) without per-capability Kafka wiring.
Kong Agent Gateway Bridge
kong-agent-gateway-bridge
Register Naftiko-built capabilities and agents with Kong Agent Gateway for A2A governance — agent identity verification, real-time prompt-injection inspection, per-agent policy enforcement, per-agent cost allocation, A2A observability across MCP and message traffic.
Kong FinOps Bridge
kong-finops-bridge
Pull Kong Konnect analytics — request counts, latency percentiles, error rates, AI token consumption, per-agent cost allocation, audit events — into Naftiko's per-call cost attribution model so every capability call carries its real Kong-measured cost.
