Side by Side
At a Glance
14 dimensions of comparison between Naftiko and Zuplo — 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
Zuplo
Category
Naftiko
Spec-driven integration platform
Zuplo
Programmable code-first API gateway — TypeScript/Deno route handlers, edge-native, with API key management + monetization + dev portal + MCP built in
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Zuplo
Zuplo, 2021 — founded as ‘the API management platform for developers’; modern stack alternative to Apigee / Mulesoft / Kong
Primary primitive
Naftiko
Capability — declared in YAML; consumes + exposes
Zuplo
Route handler (TypeScript/Deno) + Bucket + Consumer + Key + Deployment + Tunnel
Layer in the stack
Naftiko
Build-time + ship-time + runtime engine that authors integrations
Zuplo
Runtime edge gateway with built-in developer portal, key management, metering, and policy enforcement
Core artifact
Naftiko
YAML capability spec (declarative, multi-protocol)
Zuplo
TypeScript route handler + zuplo.yaml + OpenAPI spec, deployed as a Project to Zuplo's managed edge
Open source posture
Naftiko
Apache 2.0 Framework, free Fleet community, paid Standard / Enterprise
Zuplo
Closed-source SaaS. Adjacent OSS: Zudoku (docs framework) + Rate My OpenAPI (lint scorer). No self-host option.
Multi-protocol exposure
Naftiko
REST + MCP + Skills + Webhooks + A2A — same capability, all protocols
Zuplo
REST + MCP — the Zuplo MCP server (POST /mcp/docs) ships with the platform; SSE/HTTP transport for agent consumers
AI gateway posture
Naftiko
exposes: mcp on any capability; LLM access via consumed APIs
Zuplo
Rate-limit-by-tokens (not requests), gated MCP endpoints by plan, AI-aware monetization, API keys for AI agents as a documented use case
Deployment model
Naftiko
Customer infra — Docker / Kubernetes / VPC
Zuplo
Zuplo-managed edge across global regions; no self-host. Tunnels for connecting Zuplo's edge to private VPC backends.
Governance scope
Naftiko
Design-time (Spectral lint), admission (Kyverno / OPA), runtime engine
Zuplo
Runtime — TypeScript policies + API key buckets + rate limit policies + audit logs + signed deployments via GitOps
Discovery surface
Naftiko
Backstage capability catalog + scorecards + apis.io
Zuplo
Auto-generated developer portal from OpenAPI specs — self-serve API key signup, plan management, consumption analytics
API key management
Naftiko
Runtime secret injection (env, ExternalSecrets); Keycloak / OpenFGA roadmap
Zuplo
Native hierarchy — Account → Bucket → Consumer → Key, with bulk creation, key rolling, tagging, expiration, scoped permissions, manager delegation
Cost / FinOps
Naftiko
Cost-center labels propagated to K8s; Kubecost integration
Zuplo
FOCUS-aligned metering (requests + data egress + compute seconds) + plan-based monetization + per-consumer chargeback baked into the developer portal
Founder framing
Naftiko
“Capability fleet” — many ships, one navy
Zuplo
“The API management platform for developers” — programmable, edge-native, MCP-first
Common Ground
Where They Overlap
Both Naftiko and Zuplo 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
Zuplo ships its own MCP server endpoint (POST /mcp/docs) exposing search-zuplo-docs + ask-question-about-zuplo tools, and frames MCP as the doorway to API-based business. Naftiko exposes any capability as MCP via
exposes: mcp. Both refuse to bolt MCP on as an afterthought.2
Both treat the OpenAPI spec as the entry point
Zuplo auto-imports OpenAPI to generate the developer portal, key management surface, and route handlers. Naftiko consumes any API via the consume block backed by OpenAPI; the spec drives the engine. Both refuse the ‘OpenAPI is documentation, not infrastructure’ default.
3
Both treat the developer portal as a first-class concern
Zuplo auto-generates a developer portal with self-serve key signup, consumption analytics, and plan management — Zudoku is the open-source docs framework powering it. Naftiko Fleet ships a Backstage capability catalog with scorecards. Both refuse to make discovery a slide-deck problem.
4
Both publish operational signals as machine-readable data
Zuplo's plans, rate-limits, and FOCUS-aligned FinOps files are API Commons specs — diffable, automatable. Naftiko ships OpenTelemetry + Prometheus from every capability container. Both refuse to make ops a screenshot-and-PDF affair.
5
Both target the post-Apigee modernization wave
Zuplo's blog explicitly positions against Apigee Edge end-of-life and Azure APIM tier limits, targeting enterprises migrating off legacy gateways. Naftiko targets the same enterprises with a capability-spec abstraction over their API sprawl. Different wedges, same modernization moment.
6
Both ship FOCUS-aligned FinOps metering
Zuplo meters api_requests + data_egress + compute_seconds with cost allocation by api / endpoint / tier / region / consumer. Naftiko propagates cost-center labels into Kubecost for per-call attribution. Both refuse the ‘no per-call cost visibility’ anti-pattern.
7
Both author config-as-code via Git workflows
Zuplo deploys TypeScript route handlers via GitOps — pull request, preview, deploy. Naftiko capabilities are YAML committed to Git and reconciled by the Fleet operator. Both refuse the ‘click-ops console’ default that legacy API management leans on.
8
Both ship API key rotation as a first-class concern
Zuplo's POST /key-buckets/{bucket}/consumers/{consumer}/roll-key rolls a consumer's keys; Tunnel rotate-token does the same for tunnels. Naftiko's roadmap toward Keycloak / OpenFGA targets the same posture — keys live at the boundary, rotate by design. Both refuse the ‘static long-lived credential’ default.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Zuplo runs a closed-source, edge-managed, code-first programmable API gateway with native key management + monetization + developer portal + MCP server bundled in. Naftiko is an open-source spec-driven engine that authors integration capabilities and exposes them through any of REST / MCP / Skills / Webhooks / A2A. Different bets — Zuplo for managed-edge developer experience; Naftiko for spec-driven authoring and self-hosted multi-protocol exposure.
1
Spec-driven YAML vs code-first TypeScript handlers
Naftiko
Author capabilities as declarative YAML. The spec is the artifact; the engine reads it. Same spec, multiple protocols.
Zuplo
Author route handlers as TypeScript/Deno functions. The code is the artifact; Zuplo deploys it to the edge.
Same direction (code-as-config) at different altitudes — Naftiko declarative at the integration spec layer; Zuplo imperative at the route handler layer.
2
Open-source-self-hosted engine vs closed-source SaaS-only
Naftiko
Apache 2.0 Framework runs in your container, your Kubernetes, your VPC. Open-source is the engine.
Zuplo
Closed-source managed SaaS at the edge — no self-host option. Adjacent OSS projects (Zudoku, Rate My OpenAPI) but the gateway itself is proprietary.
3
Multi-protocol expose vs REST + MCP
Naftiko
One capability YAML exposes REST + MCP + Skills + Webhooks + A2A simultaneously from a single spec.
Zuplo
Edge gateway exposes REST + a built-in MCP server endpoint for docs/support. Agent Skills + Webhooks + A2A are not first-class adapters.
4
Capability primitive vs route-handler + bucket + consumer + key primitives
Naftiko
Primary identity is ‘the thing that does X’ — composed from consumes and exposes, versioned as a YAML artifact.
Zuplo
Primary identities are Bucket → Consumer → Key (key management hierarchy), Deployment (project shipped to edge), Tunnel (private backend bridge), Route Handler (TypeScript function). Gateway-shaped, monetization-shaped.
5
Three governance altitudes vs runtime + GitOps governance
Naftiko
Spectral rulesets at design time (IDE + CI), Kyverno / OPA at admission time, runtime checks in the engine. Lifecycle-shaped governance.
Zuplo
Governance is GitOps + runtime — TypeScript policies enforced at the edge + audit logs for account mutations + signed deployments. No spec-layer design-time policy layer for the integration spec itself.
6
Bring-your-own infra vs managed edge
Naftiko
Customer runs the engine on their infra; controls the data plane, network egress, secrets, storage.
Zuplo
Zuplo runs the edge globally; customer ships TypeScript + zuplo.yaml + OpenAPI to Zuplo's managed regions. Tunnels bridge to private backends without exposing inbound firewall rules.
7
Enterprise integration team vs developer-experience-led API team
Naftiko
Sally the Integration Engineer at a regulated enterprise — many APIs, many domains, many cost centers, governance is the load-bearing concern.
Zuplo
Developer-led API team at modern SaaS / fintech / AI startup — API product, monetization, self-serve key signup, and time-to-first-call are the load-bearing concerns.
8
Capability composition vs API monetization built-in
Naftiko
Capabilities compose — applied capabilities consume source capabilities following DDD aggregate patterns. The spec layer makes composition declarative.
Zuplo
Monetization, plans, quotas, and consumer chargeback are built into the gateway runtime. Native rate-limit-by-tokens for LLM-priced APIs. The gateway is the monetization layer.
Partnership Thesis
Service Partnership
Naftiko is the spec-driven authoring engine. Zuplo is the managed edge gateway with first-class API key management + monetization + developer portal + MCP server bundled in. The capability map treats every Zuplo API surface — key buckets, consumers, keys, tunnels, deployments, custom domains, audit logs, MCP servers, variables — as Naftiko-consumable so Naftiko writes the capability, then publishes the matching Zuplo resources (consumer + key + monetization plan + deployment) from the spec layer. Naftiko authors; Zuplo runs the edge.
“Naftiko brings the spec layer, the multi-protocol exposure, and the open-source authoring engine. Zuplo brings the managed edge runtime, the native API key hierarchy, the auto-generated developer portal, monetization, and the bundled MCP server. Together: a Naftiko capability YAML becomes a monetized, key-gated, portal-listed, edge-deployed integration on Zuplo's runtime — without the customer hand-writing TypeScript route handlers.”
Two First-Meeting Questions
Q1. Naftiko capability YAMLs as Zuplo route handlers
Would Zuplo support a documented ‘wrap me as a Zuplo project’ pattern — where every Naftiko
exposes: rest capability auto-generates the matching Zuplo route handlers + zuplo.yaml + monetization plan, deployable to Zuplo's edge with one command? The capability map below treats the Zuplo deployment API as a Naftiko-publishable target; codifying that pattern would mean every Naftiko-authored integration ships with a turnkey edge deployment + portal + key management surface — without TypeScript boilerplate.Q2. Naftiko-built MCP servers federated into Zuplo's MCP catalog
Would Zuplo open a path for Naftiko-built MCP servers to land alongside Zuplo's docs MCP server — turning the Zuplo developer portal into a federated MCP catalog where every customer-built capability is a discoverable, plan-gated MCP endpoint? Today Zuplo's /mcp/docs is Zuplo-curated; opening the catalog to Naftiko-authored entries would compound the MCP-first positioning and give every API monetization play an agent-callable surface from day one.
Integration Kit
Partnership Capability Map
12 Naftiko capabilities authored to integrate with Zuplo as a service partner. Each one consumes a specific Zuplo 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.
Zuplo General
zuplo-general
Top-of-tree metadata access for the Zuplo Developer API — OpenAPI spec + Who Am I — the read-only surface for capability bootstrapping.
Zuplo API Key Buckets
zuplo-api-keys-buckets
CRUD over Zuplo Buckets — the top of the API key hierarchy (Account → Bucket → Consumer → Key). Naftiko-declared monetization tiers land here.
Zuplo API Key Consumers
zuplo-api-keys-consumers
CRUD over Consumers (the per-customer slot inside a Bucket) with key rolling — the unit Naftiko maps to a Fleet customer.
Zuplo API Keys
zuplo-api-keys-keys
CRUD over Keys themselves, including bulk creation — the credentials Naftiko issues from its capability spec layer for every Zuplo-gated integration.
Zuplo API Key Managers
zuplo-api-keys-managers
List/create/delete Managers within a Consumer — delegated key management roles for the customer side of a Naftiko-issued integration.
Zuplo Audit Logs
zuplo-audit-logs
Query Zuplo audit logs — the governance trail Naftiko Fleet pulls into its OTel pipeline to give every gateway-routed capability a full lineage.
Zuplo Custom Domains
zuplo-custom-domains
CRUD over custom domains — the public hostname Naftiko-authored capabilities live under once Zuplo routes their edge traffic.
Zuplo Deployments
zuplo-deployments
Deployment lifecycle (upload, get, delete, redeploy) — the operation Naftiko triggers to ship a capability-derived Zuplo project to the edge.
Zuplo MCP Servers
zuplo-mcp-servers
Wrap Zuplo's bundled MCP server (POST /mcp/docs) as a Naftiko consume so Naftiko-authored agents can search Zuplo docs + ask configuration questions through the gateway's own MCP.
Zuplo Tunnel Services
zuplo-tunnel-services
Tunnel service provisioning + config — the bridge Naftiko uses to expose private-backend capabilities through Zuplo's edge without inbound firewall rules.
Zuplo Tunnels
zuplo-tunnels
CRUD over Tunnels + token rotation + teardown status — the underlying surface that connects Zuplo's edge to a Naftiko-running VPC backend.
Zuplo Variables
zuplo-variables
Manage environment variables for a Zuplo Project so Naftiko-issued secrets and configuration land in the runtime where the gateway needs them.
