Kong vs Bruno
Bruno wins · 13–17 (7 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round drawnA live probe confirms Kong serves a working llms.txt at developer.konghq.com/llms.txt (HTTP 200) describing its documentation set for Gateway, Konnect, AI Gateway, and Mesh, directly matching the story of pointing an agent at an agent-oriented docs entrypoint. Missing for 10: no evidence of a more extensive llms-full.txt or additional per-product agent-doc indexes, and no independent (non-probe) commentary confirming real-world agent usage of this file.
- [probe] “PROBE llms.txt: HTTP 200 at https://developer.konghq.com/llms.txt # developer.konghq.com > Kong's developer documentation for Kong Gateway,…”
Direct probe evidence confirms Bruno docs serve a working llms.txt at docs.usebruno.com/llms.txt with structured links to docs pages, which is exactly the agent-oriented docs entry point the story asks for. Missing for 10: no independent/community confirmation of agents actually consuming it, and no broader agent-specific documentation format beyond the single llms.txt file.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to BrunoKong Gateway supports headless/CI operation via DB-less declarative config, decK and kongctl CLI tools for API Lifecycle Automation (APIOps), a RESTful Admin API, and Docker-based deployment—all enabling fully automated, non-interactive pipelines. missing for 10: independent hands-on CI pipeline example or third-party case study demonstrating actual CI/CD integration in production.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”
Bruno CLI is well-documented for running collections headlessly with JSON/JUnit/HTML reports, explicit CI/CD integration, official Docker images, and GitHub Actions support — directly enabling headless/CI automation. Missing for 10: independent hands-on CI pipeline reports beyond vendor docs.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round to KongKong's AI Gateway positions itself as an 'MCP Traffic Gateway' that can govern, secure, and observe traffic to/from MCP servers, and its Catalog can inventory MCP servers alongside APIs and agents (kong-docs-65, kong-docs-22, kong-gh-6). However, the evidence centers on Kong auto-generating/exposing MCP servers from REST APIs and proxying/governing MCP traffic between agents and servers, not on Kong itself acting as an MCP client that plugs in external MCP servers to consume their tools directly. Missing for 10: clear documentation of Kong itself invoking/using tools from a connected MCP server (client-side tool use), independent/hands-on confirmation of this workflow, and detail on how a user 'plugs in' an arbitrary third-party MCP server for Kong's own use.
- [claimed-docs] “MCP Traffic Gateway”
- [claimed-docs] “Catalog as one inventory across APIs, API packages, AI Models, MCP servers, and agents”
- [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
- [claimed-docs] “Auto-discover APIs and compose endpoints into MCP tools”
- [claimed-docs] “Auto-generate MCP servers that leverage composed MCP tools. One-click deploy to Kong AI Gateway infrastructure.”
- [claimed-docs] “AI Gateway acts as a control and observability layer for A2A traffic, enabling you to route agent-to-agent requests, extract task metadata, …”
ai-native userConnect an agent via an official MCP server
weight 3 · round to KongKong documents an official Kong Konnect MCP Server (kong-docs-66, kong-probe-3) plus dedicated MCP gateway docs for connecting agents (kong-docs-3, kong-docs-65) and MCP auto-generation/tool composition (kong-docs-53, kong-docs-54). This is first-party documentation of an official MCP server, not just client-side MCP consumption. missing for 10: independent/hands-on third-party verification of the MCP server working end-to-end, and more detail on setup/connection steps beyond marketing copy.
- [claimed-docs] “Kong Konnect MCP Server”
- [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”
- [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
- [claimed-docs] “MCP Traffic Gateway”
- [claimed-docs] “Auto-discover APIs and compose endpoints into MCP tools”
- [claimed-docs] “Auto-generate MCP servers that leverage composed MCP tools. One-click deploy to Kong AI Gateway infrastructure.”
- [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
Brunonone0/10Bruno is an API client/CLI product where an official MCP server is a plausible feature (e.g., for AI agents to run collections), but no evidence pack item mentions an MCP server, MCP protocol, or agent-connection endpoint — only AI-assisted scripting/chat features (BYOK) are documented, which is a different capability.
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
- [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
ai-native userUse an official CLI
weight 2 · round to BrunoKong ships official CLIs (decK for declarative APIOps and kongctl for Konnect/Gateway management) documented at developer.konghq.com/deck and /kongctl, which can be scripted/automated by AI-native or agentic workflows. However, there's no evidence these CLIs are explicitly designed or marketed for AI-native/agentic use (e.g., no agent-specific CLI features, no mention of LLM/agent integration in the CLI docs themselves — that capability is described separately for AI Gateway proxying other tools' CLI traffic, not Kong's own CLI being agent-oriented). missing for 10: explicit agentic/AI-native design goals for decK/kongctl, independent hands-on verification of CLI use by AI agents.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [probe] “official CLI documented at https://developer.konghq.com/deck/”
Bruno ships an official CLI (`bru`) documented for running collections via simple commands, generating JSON/JUnit/HTML reports, and integrating into CI/CD and Docker pipelines — all features an AI agent or automated workflow could invoke non-interactively. Missing for 10: explicit documentation or examples of AI agents/automation frameworks directly invoking the CLI, and independent hands-on validation of its scripting robustness.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
ai-native userDrive the product through a documented public API
weight 3 · round to KongKong exposes a documented public Admin API for configuring the gateway (kong-gh-5, kong-gh-10), a directory of OpenAPI specs for Kong's APIs (kong-docs-9), and RESTful proxying of any API with extensibility via plugins (kong-docs-44), giving AI-native users a clear, documented programmatic surface to drive the product. missing for 10: a live discoverable OpenAPI/swagger machine-readable spec at the docs root (probe found 404s at common openapi.json paths), and independent/hands-on confirmation of API-driven automation beyond vendor docs.
- [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “Kong Gateway runs in front of any RESTful API and can be extended through modules and plugins.”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
- [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
Bruno ships a well-documented CLI (bru) that lets automation/AI agents run collections, generate reports, and integrate into CI/CD pipelines, and there is a docs llms.txt for AI consumption, but there is no true public HTTP/REST API or OpenAPI spec (probe confirms 404 on all openapi endpoints) that an AI agent could call directly. missing for 10: a documented HTTP/REST API or SDK beyond the CLI, official OpenAPI/swagger spec, and evidence of programmatic access outside the CLI wrapper.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to KongKong Gateway's core auth plugins (JWT, OAuth2, ACLs, API keys) and Vaults for secret storage provide the building blocks for scoped, least-privilege credentials per consumer, and AI Gateway/Konnect docs mention defining entitlements for agent/MCP/tool consumption, suggesting credential scoping applies to agent traffic too. However, there is no dedicated, documented workflow specifically for 'issuing scoped credentials to an AI agent' — the evidence is generic auth/authz plus general entitlement language rather than a concrete agent-credential-issuance feature or example. missing for 10: a first-party doc/example showing scoped API-key/OAuth-scope issuance specifically for an agent identity, and independent/hands-on confirmation of least-privilege enforcement in agent/MCP contexts.
- [github] “Authentication and authorization for APIs using methods like JWT, basic auth, OAuth, ACLs and more.”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
- [claimed-docs] “Define entitlements, meter, and bill against agent context consumption for everything from the agent to the LLM to the MCP server to MCP too…”
- [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
- [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”
Brunonone0/10Bruno documents secret management (vaults, GCP/Azure Key Vault integration) and a BYOK model for its own AI assistant, but there is no evidence of a feature to mint or scope least-privilege API credentials/tokens specifically for an external AI agent's use. missing for 10: any credential-issuance or scoping mechanism aimed at agents, documentation of granular permission scopes, or evidence of restricting an agent's API access via generated tokens.
- [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”
- [claimed-docs] “Azure CLI authentication feature allows you to authenticate with Azure Key Vault using your existing Azure CLI session, without requiring ma…”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
ai-native userBuild against official SDKs
weight 2 · round drawnKongnone0/10Evidence shows Kong offers CLIs (decK, kongctl), Admin/OpenAPI API directories, and Kong Manager UI, but no evidence of official client SDKs (e.g., language-specific libraries) for building against Kong Gateway/AI Gateway/Konnect APIs.
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round to BrunoKongnone0/10Kong's evidence focuses on AI Gateway/MCP traffic management (routing LLM calls, semantic security, observability plugins) but none of it shows Kong itself analyzing a user's own API/traffic data to generate AI insights or suggestions inside the product (e.g., an AI copilot summarizing gateway usage or recommending config changes). This is a plausible feature for a management platform like Konnect, so the axis applies, but no evidence supports it.
- [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
- [claimed-docs] “AI Gateway addresses these challenges with a high-performance control plane that secures, governs, and observes AI-native systems end to end…”
- [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
- [claimed-docs] “Konnect lets you catalog, connect to, and monitor the status of all API Gateway control planes (CPs) and data plane nodes (DPs) in one place…”
Bruno's docs describe multiple in-product AI features: ghost-text script suggestions, an AI icon that generates scripts from descriptions, an AI chat sidebar for workspace-wide questions, and AI generation of collections from backend code or full apps — all clearly 'AI-generated insights/suggestions inside the product'. However, all evidence is first-party documentation with no independent/hands-on corroboration of quality or reliability, and it's a BYOK add-on rather than a fully vetted core capability. Missing for 10: independent/community validation of AI feature quality, and evidence of AI 'insights on data' (e.g., response analysis) beyond scripting/chat/generation use cases.
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
- [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
- [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
- [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round to BrunoKongnone0/10Kong's evidence describes AI Gateway/MCP governance features for routing and securing AI traffic, but nothing shows Kong itself embedding a built-in assistant that a user delegates tasks to within the product UI (e.g., Konnect). Missing for 10: any documented in-product AI assistant/chat feature, evidence of task delegation to it, and independent confirmation of its use.
- [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
- [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
- [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
Bruno AI offers in-app AI assistance: script generation, ghost-text suggestions, an AI chat sidebar, and generating collections/apps from context, all documented first-party (bruno-docs-37 to 42). However this is BYOK-only, largely scoped to scripts/collections/UI generation rather than broad task delegation, and there is no independent/hands-on corroboration of its effectiveness. missing for 10: independent verification of AI assistant quality, evidence of broader agentic task delegation beyond scripting/UI generation, and confirmation this isn't a limited/beta feature.
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
- [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
- [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
- [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”
ai-native userOperate the product with natural-language commands
weight 2 · round drawnKong ships an official Konnect MCP Server (kong-docs-66, kong-probe-3), which lets AI-native users operate Kong Konnect via natural-language commands through an MCP client, and Kong also documents AI Gateway support for AI CLIs/agent traffic (kong-docs-58). However, this NL control is scoped to Konnect cloud management rather than the core Gateway, documentation is thin (a one-line stub), and there's no independent/hands-on evidence of the breadth or reliability of natural-language operation. Missing for 10: detailed docs on supported commands/scope, independent user validation, and NL support for the open-source Gateway itself (not just Konnect).
- [claimed-docs] “Kong Konnect MCP Server”
- [probe] “official MCP server documented at https://developer.konghq.com/konnect-platform/konnect-mcp/”
- [claimed-docs] “AI Gateway can proxy requests from AI command-line tools to LLM providers. This gives you centralized control over AI traffic: log all reque…”
Bruno AI lets users describe what they need in natural language to generate scripts, chat with an AI sidebar, and generate full collections/apps from descriptions, which is genuine natural-language operation of parts of the product. However this is scoped to scripts/collections/app generation rather than full natural-language control of all core workflows (running requests, git operations, environment management still require GUI/CLI, not NL commands). missing for 10: evidence of natural-language control over core request execution/CLI operations, independent hands-on validation of Bruno AI's NL features, and confirmation this isn't limited to a paid/BYOK tier.
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “The AI Chat Sidebar lets you ask questions and get AI assistance directly from anywhere in your workspace, without needing to open a specifi…”
- [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
- [claimed-docs] “Bruno AI understands the context of your open request or collection and can generate a complete working App for you. You don't need to write…”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to KongKong provides a Dev Portal that lets users browse/search API documentation and try API operations, and has an OpenAPI directory for its own APIs, which supports interactive exploration with runnable examples; however, the probe for standard OpenAPI/Swagger UI endpoints on the docs site 404'd, and there's no direct evidence of a live 'try it out' interactive console with runnable examples specifically for AI-native users. missing for 10: independent/hands-on confirmation of a runnable 'try it now' console, explicit AI-native tailoring of the interactive reference, and successful OpenAPI/swagger endpoint discovery.
- [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
Bruno lets users write documentation alongside their collections and publish it as shareable HTML, and requests/collections are inherently runnable examples (bruno-docs-20, bruno-docs-27), which is the closest match to an 'interactive reference with runnable examples.' However, there is no evidence of an actual interactive API explorer (e.g., OpenAPI/Swagger-style try-it-out UI) — a probe for OpenAPI/Swagger endpoints on Bruno's own docs returned 404s (bruno-probe-2), and no community or hands-on evidence confirms the published HTML docs are truly interactive/executable rather than static. Missing for 10: evidence of a live interactive reference UI, independent confirmation that published docs are runnable (not just readable), and AI-specific tooling around this reference.
- [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
- [claimed-docs] “Embed a button in your README so anyone can open your workspace or collection in Bruno.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to KongKong docs explicitly reference a 'Directory of OpenAPI specifications for various Kong APIs' (developer.konghq.com/api/), and Dev Portal supports publishing OpenAPI/AsyncAPI specs, indicating machine-readable specs exist and are downloadable. However, a direct probe for standard OpenAPI file locations (openapi.json, swagger.json, etc.) returned 404s, showing the spec isn't trivially discoverable at conventional endpoints. Missing for 10: a confirmed, directly downloadable OpenAPI/AsyncAPI file link or independent verification that the /api/ directory serves raw machine-readable spec files.
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
Brunonone0/10Bruno is a desktop/CLI API client with no public web API of its own, but the axis is still fair to ask (e.g., an OpenAPI export/spec for AI agents to consume). Direct probing found no OpenAPI/Swagger spec (all candidate paths 404) — only an llms.txt docs index exists, which is not a machine-readable API spec. Missing for 10: any OpenAPI/Swagger JSON or equivalent structured spec, first-party docs describing one, and community confirmation of its existence.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.usebruno.com/llms.txt # Bruno Docs - [Getting Started](https://docs.usebruno.com/introduction/gett…”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to BrunoKongnone0/10Kong's evidence covers DB-less/declarative deployments, Konnect control-plane/data-plane separation, and a Docker quickstart script, but none of this documents a dedicated 'sandbox environment' or test/staging mode explicitly isolated from production data for AI-native testing — the closest hint is Dev Portal's 'try API operations' feature (kong-docs-21), which is not framed as a sandbox against production. Missing for 10: explicit sandbox/staging environment documentation, mock/test data isolation for AI agent calls, and any first-party guidance on safely testing AI Gateway/MCP flows without touching production traffic.
- [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
- [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”
- [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
Bruno supports environment variables, global env overrides, and mock responses, which let users point requests at different (e.g. sandbox) environments and separate them from production, and its offline-first, no-cloud-sync design (bruno-docs-8, bruno-docs-9) keeps data local rather than sent to a vendor. However, there is no explicit documentation of a dedicated 'sandbox mode' or built-in safeguards preventing accidental production calls, and no AI-agent-specific sandbox testing workflow is described. Missing for 10: explicit sandbox/staging environment isolation feature, guardrails against hitting production endpoints, and AI-agent-specific evidence of sandboxed test execution.
- [claimed-docs] “Serve realistic mock responses while you build.”
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “add --global-env-var to override global environment variables at runtime”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnKongnone0/10While Kong publishes OpenAPI spec directories for its various APIs (kong-docs-9) and has extensive product documentation, no evidence in the pack describes API versioning conventions or any documented deprecation policy for Kong's own APIs (Admin API, Konnect API, AI Gateway API, etc.). The OpenAPI probe even returned 404s, and no changelog/deprecation-notice pages are cited.
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [probe] “PROBE openapi: all candidate paths 404 (https://developer.konghq.com/openapi.json, https://developer.konghq.com/swagger.json, https://develo…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to BrunodecK and kongctl provide declarative, bulk configuration management (sync entire API/gateway state from files) and the Admin API allows scripted bulk changes, which supports AI-native automation across many entities (routes, services, plugins) at once. However, evidence doesn't show bulk operations specifically framed for AI-native workflows (e.g., bulk operations on AI Models, MCP tools, or catalog entries) beyond general declarative config sync. missing for 10: explicit bulk operation APIs/examples for AI-specific entities (LLMs, MCP servers, agents), independent hands-on validation of bulk operation performance/reliability at scale.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
Bruno CLI lets you run entire collections (many requests) from the command line with data-driven testing, generate consolidated reports, and integrate into CI/CD pipelines or Docker/GitHub Actions, which is a clear bulk-automation workflow across many API items at once. Missing for 10: independent/hands-on evidence of bulk operations at scale (e.g., large collection performance) and explicit documentation of bulk editing/manipulation of items beyond running them.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to KongKong's plugin architecture (rate-limiting, DLP/safety policies, logging, transformations) lets users define declarative rules that automatically trigger actions on gateway request/response events, and AI Gateway policies (e.g., blocking toxic content) act as automated triggers on AI traffic events. However, there's no evidence of a generic, user-authored event-trigger/automation framework (e.g., 'when X happens do Y' rules across arbitrary events) beyond the fixed set of built-in plugins/policies. Missing for 10: a flexible custom event-trigger rule engine, documentation of arbitrary event types beyond traffic/API-call lifecycle, and independent evidence of this automation working end-to-end.
- [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
- [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
- [claimed-docs] “Rate Limiting - Plugin”
- [claimed-docs] “The core of AI Gateway is the ability to serve AI Models from various AI Model Providers via a provider-agnostic API.”
Bruno supports pre-request and post-response JavaScript that runs automatically on those request lifecycle events, and CI/CD integration lets test suites run automatically on pipeline events, but there is no general-purpose rule/trigger engine for arbitrary events. missing for 10: a configurable rules/event system beyond request/response scripts, support for custom triggers or webhooks, and any evidence of broader automation orchestration.
- [claimed-docs] “Pre-request and post-response JavaScript — the `bru` API, request chaining, and libraries.”
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
ai-native userVersion, review, and roll back my automations
weight 1 · round to BrunoKong's decK tool is described as enabling 'API Lifecycle Automation (APIOps)' with a toolkit to 'orchestrate and automate' configuration processes, which implies config-as-code that could be version-controlled and reapplied, but the evidence never explicitly describes diffing, review workflows, or rollback of automations. kongctl is also mentioned only by name with no detail. missing for 10: explicit documentation of versioning/diff review, rollback commands or history, and confirmation this applies to AI agent 'automations' rather than just gateway config.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
Bruno stores collections/scripts as plain-text files and ships a native Git UI (init, diff, pull, clone, commit) letting users version and review changes to their API automations like code, with community confirmation of the git-collaboration workflow. Explicit rollback is implied via standard git operations (checkout/revert) rather than a dedicated in-app 'rollback' feature. Missing for 10: explicit documented rollback/undo UI beyond generic git commands, independent evidence of reviewing/rolling back script changes specifically.
- [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
- [claimed-docs] “Core Git UI features (init, view diffs, check for updates, pull, clone) are now available in the free version.”
- [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
- [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
- [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
- [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”
Ci scripting — stories about ci scripting in this arenaCi scripting
Stories about ci scripting in this arena
Scripting
developerScript pre-request and post-response logic to chain requests and massage data
weight 2 · round to BrunoKong's plugin architecture includes request/response transformation plugins (kong-gh-3) that let developers modify ('massage') request and response data, which partially supports the scripting/data-massaging part of the story. However, there is no evidence of an explicit scripting mechanism (e.g., pre-function/post-function or serverless script plugins) or of chaining multiple requests together in sequence. Missing for 10: documented custom-script (pre/post function) plugin capability, explicit request-chaining support, and independent confirmation of these features in practice.
- [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
- [claimed-docs] “Rate Limiting - Plugin”
Bruno documents pre-request and post-response JavaScript scripting with a `bru` API for request chaining and data manipulation, plus test suites and data-driven testing to automate runs. Missing for 10: independent hands-on community corroboration specifically validating scripting/chaining behavior (community evidence focuses on other features like git/cookies) and more detail on complex chaining edge cases.
- [claimed-docs] “Pre-request and post-response JavaScript — the `bru` API, request chaining, and libraries.”
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”
Collaboration — working as a team — sharing, comments, roles, simultaneous editingCollaboration
Working as a team — sharing, comments, roles, simultaneous editing
Access control
platform-engineerControl who can view or edit APIs and collections with roles and permissions
weight 2 · round drawnKongnone0/10The evidence covers Dev Portal visibility settings (public/private), Vaults for secrets, and Catalog for API inventory, but nowhere describes role-based access control or granular view/edit permissions for APIs or collections. No mention of teams, roles, or RBAC constructs in Konnect or Gateway for collaborative access management.
Api catalog
platform-engineerPublish an internal catalog or portal where teams discover and consume our APIs
weight 2 · round to KongKong ships a dedicated Dev Portal for publishing API docs (OpenAPI/AsyncAPI, Markdown) with public or authenticated visibility so teams can browse, try operations and self-manage credentials, plus a Catalog feature that acts as a platform-level inventory across APIs, API packages, AI Models, MCP servers and agents for org-wide discovery. This directly matches the platform-engineer story of publishing an internal catalog/portal for API discovery and consumption. missing for 10: independent/hands-on evidence of the Dev Portal or Catalog in real use (only first-party docs), and more detail on cross-team governance/workflow beyond the docs descriptions.
- [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
- [claimed-docs] “Catalog as one inventory across APIs, API packages, AI Models, MCP servers, and agents”
- [claimed-docs] “Catalog gives you a platform-level home for creating, describing, and governing them.”
- [claimed-docs] “You need to know every API, AI Model, agent, and MCP server your org has built, without checking each team's tools individually”
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “Public visibility without authentication”
- [claimed-docs] “Private visibility with authentication enabled”
- [claimed-docs] “Catalog is where these interfaces live instead: APIs, AI Models, and more. Instead of digging through individual products to find what alrea…”
- [claimed-docs] “Compose API packages from existing operations to serve specific partners or use cases.”
Bruno lets teams write and publish collection docs as shareable HTML and embed 'open in Bruno' buttons in READMEs, and its Git-native storage enables shared, discoverable collections across a repo/monorepo — a lightweight substitute for a catalog. However there is no dedicated internal developer-portal, no searchable catalog UI, and no cloud-hosted discovery surface (explicitly no cloud sync/account). missing for 10: a true portal/catalog UI, cross-team search/discovery beyond Git repos, hosted publishing beyond static HTML docs.
- [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
- [claimed-docs] “Embed a button in your README so anyone can open your workspace or collection in Bruno.”
- [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
- [claimed-docs] “open multiple collections from a monorepo”
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
Collections workspaces — stories about collections workspaces in this arenaCollections workspaces
Stories about collections workspaces in this arena
Collections
developerStore collections as plain text files in my repo and version them with git
weight 3 · round to BrunoKong's decK tool supports declarative configuration files (YAML/JSON) that represent Kong's gateway config as plain text, enabling APIOps-style workflows and 'Declarative Databaseless Deployment' which is commonly stored and versioned in git repos. However, the evidence never explicitly shows a 'collections' concept (like Postman-style API collections) or an explicit git-based workflow/example — it's inferred from decK's declarative config model. Missing for 10: explicit documentation of a 'collections' artifact, an explicit git-versioning workflow/example, and confirmation this applies beyond gateway config to broader workspace collections.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “decK | Kong Docs”
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
Bruno stores collections as plain-text .bru files on the filesystem, explicitly designed for git versioning, with native Git UI support and CLI/terminal workflows; this is strongly corroborated by first-party docs and independent community testimonials confirming real-world use.
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
- [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
- [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
- [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
- [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”
- [claimed-docs] “Switched from Postman to @use_bruno and I'm not going back. Collections are plain text files in Git.”
Offline
developerWork fully offline in a local workspace without a cloud account
weight 2 · round to BrunoKong Gateway supports declarative, DB-less deployment and Docker installation that can run entirely locally without Konnect (kong-gh-4, kong-gh-7, kong-gh-20), and decK/kongctl let you manage configuration as local files (kong-docs-67, kong-docs-68). However, the documented quickstart path explicitly creates a Konnect cloud control plane and ties licensing to it (kong-docs-45), and there's no dedicated 'local workspace' concept or explicit confirmation that all features work fully offline without any Konnect account. Missing for 10: a documented fully offline quickstart/workflow that never touches Konnect, and independent confirmation of offline usage without a cloud account.
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”
- [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
Bruno explicitly markets itself as offline-only with no account/cloud sync required, storing collections as plain text on the local filesystem, corroborated by community users praising the offline-first design after moving from cloud-first tools like Postman/Insomnia. missing for 10: independent audit confirming zero network calls beyond user-initiated ones.
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
Environments secrets — stories about environments secrets in this arenaEnvironments secrets
Stories about environments secrets in this arena
Environments
developerSwitch requests between dev, staging, and prod using environment variable sets
weight 3 · round to BrunoKongnone0/10Kong's evidence covers secrets storage via Vaults (including environment-variable-backed secrets) and multi-control-plane management via Konnect/decK, but there is no documented feature for developers to define and switch between named 'dev/staging/prod' environment variable sets when making requests, as in a client-testing workflow. Missing for 10: explicit environment/variable-set switching UI or config, evidence of per-environment variable collections, and any workflow tying such sets to request execution.
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
- [claimed-docs] “You can add secrets to Vaults in one of the following ways: * Environment variables * Konnect Config Store * Supported third-party backend v…”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “The script creates a Control Plane in Konnect and deploys a local Data Plane using Docker. All licensing is handled automatically by Konnect…”
Docs confirm Bruno has an environment selector with search filtering, drag-and-drop variable management, and CLI overrides via --global-env-var, all indicating a working environment/variable-set system for switching contexts. However, no evidence explicitly documents a dev/staging/prod workflow or environment creation/management UI in depth. Missing for 10: explicit documentation of creating and switching between multiple named environments (e.g. dev/staging/prod), and independent hands-on confirmation of environment-switching UX.
- [claimed-docs] “add --global-env-var to override global environment variables at runtime”
- [claimed-docs] “adding search filter to environment selector dropdown”
- [claimed-docs] “support drag-and-drop and alphabetical sorting for variables”
Secrets
platform-engineerKeep credentials out of shared files with masked secrets or an external vault integration
weight 2 · round drawnKong Gateway's Vaults feature explicitly lets platform engineers store secrets outside plaintext config and reference them via environment variables, Konnect Config Store, or third-party vault backends (e.g., HashiCorp Vault), ensuring secrets aren't visible in plaintext throughout the platform. This directly matches the story of masking secrets and integrating with external vaults. Missing for 10: independent/hands-on validation of the vault integration beyond first-party docs, and more detail on which third-party backends are supported.
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities. This ensures that secrets aren't visible in plaint…”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
- [claimed-docs] “You can add secrets to Vaults in one of the following ways: * Environment variables * Konnect Config Store * Supported third-party backend v…”
Bruno docs explicitly state you can 'keep credentials out of version control with secret variables and vaults' and detail concrete external vault integrations (GCP Secret Manager, Azure Key Vault CLI authentication), directly matching the platform-engineer story on masked secrets and vault integration. missing for 10: independent/hands-on confirmation that masked secrets actually hide values in the UI and broader vault provider coverage beyond GCP/Azure.
- [claimed-docs] “Keep credentials out of version control with secret variables and vaults.”
- [claimed-docs] “feat(secrets): add GCP Secret Manager support”
- [claimed-docs] “add GCP Secret Manager support”
- [claimed-docs] “Azure CLI authentication feature allows you to authenticate with Azure Key Vault using your existing Azure CLI session, without requiring ma…”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to KongKong Gateway's Admin API is the canonical configuration interface, with Kong Manager UI and decK/kongctl CLI explicitly built on top of it (kong-gh-10, kong-gh-11, kong-docs-67/68), implying API-UI parity by design, and Kong also publishes OpenAPI specs for its APIs (kong-docs-9). Missing for 10: an explicit first-party statement guaranteeing 100% UI/API feature parity (especially for Konnect SaaS UI features) and independent confirmation that no UI-only features exist.
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [github] “:8002 - access Kong's management Web UI ([Kong Manager](https://github.com/Kong/kong-manager)) on [localhost:8002](http://localhost:8002)”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
Bruno ships a genuine CLI (bru) that can run collections, generate JSON/JUnit/HTML reports, and integrate into CI/CD/Docker pipelines, and collections are stored as plain text files that can be edited/versioned outside the UI — a solid API-like automation path. However, there is no true HTTP/REST API (openapi probe returned only 404s) and many UI-only capabilities (AI script generation/chat, drag-and-drop editing, GUI-based Git diff/commit workflow, app-building) have no documented CLI/API equivalent, so full UI parity is not evidenced. missing for 10: a first-class programmatic API beyond the CLI, CLI equivalents for AI features and collection editing/Git UI actions, independent confirmation of CLI/UI feature parity.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
ai-native userExport all of my data in open formats and leave
weight 3 · round to BrunoKong's decK tool lets users declaratively dump and sync Gateway/Konnect configuration (routes, services, plugins) as open YAML/JSON files, and Kong explicitly touts 'databaseless deployment... without any vendor lock-in,' supporting a form of open, portable data export. However this only covers gateway configuration, not broader platform data (analytics, logs, catalog, dev-portal content), and there's no explicit documented full-account data export/deletion workflow. Missing for 10: a documented full data-export/account-closure process covering all Konnect/Catalog/Dev Portal data, and independent confirmation that decK exports are complete and lossless.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “decK | Kong Docs”
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
Bruno stores collections as plain-text .bru files directly on the local filesystem with no cloud lock-in, no account required, and offline-only by design, making export trivial — data is already in an open, human-readable format under user control and versionable via Git. Postman import/export is also supported for migration. missing for 10: no explicit one-click 'export all data' bulk command/tool is documented, and no independent hands-on confirmation of full data portability beyond community praise for the plain-text/git model.
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
- [claimed-docs] “Switched from Postman to @use_bruno and I'm not going back. Collections are plain text files in Git.”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
ai-native userRead the product's source under an open license
weight 2 · round to KongThe GitHub repo (Kong/kong) is publicly visible and used for docs, issues, and quickstart instructions, indicating the core gateway source is readable in the open, but no evidence pack item explicitly states the license (e.g., Apache-2.0) or confirms all components (AI Gateway, Konnect, plugins) are open-sourced rather than proprietary SaaS add-ons. missing for 10: explicit license statement/file, confirmation that AI Gateway/Konnect/enterprise pieces are also open-source, independent corroboration of license terms.
- [github] “Let’s test drive Kong by adding authentication to an API in under 5 minutes.”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
- [github] “Let's test drive Kong by adding authentication to an API in under 5 minutes.”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”
Evidence repeatedly references the public GitHub repo (usebruno/bruno) and its release history, implying the source is publicly readable, but no citation explicitly states an open-source license (e.g., MIT) or points to a LICENSE file. Missing for 10: explicit license statement/citation, confirmation of license type, and any independent corroboration of licensing terms.
- [claimed-docs] “feat: add preserve scripts option for Postman import/export”
- [claimed-docs] “add preserve scripts option for Postman import/export”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
ai-native userSelf-host the core product
weight 3 · round to KongKong Gateway is open-source (GitHub repo) and explicitly supports self-hosted deployment models including Docker, DB-less, and Hybrid deployments 'without any vendor lock-in', with admin API/decK for configuration and a quickstart script for local setup. This covers the core gateway/AI Gateway functionality, not just the SaaS Konnect offering. Missing for 10: no independent third-party confirmation of large-scale self-hosted production use, and some newer AI/MCP capabilities (Catalog, Konnect MCP Server) appear tied to the Konnect SaaS platform rather than self-hosted core.
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [claimed-docs] “Kong Gateway runs in front of any RESTful API and can be extended through modules and plugins.”
- [claimed-docs] “You can use the quickstart script to get an instance of Kong Gateway running almost instantly”
- [github] “Kong runs natively on Kubernetes thanks to its official Kubernetes Ingress Controller.”
Bruno is explicitly offline-first with no cloud sync, no account/login, and collections stored as plain text files on the local filesystem, and the CLI even ships as an official Docker image for local/CI use — meaning the entire core product runs under user control with no vendor-hosted dependency (bruno-docs-8, bruno-docs-9, bruno-docs-48, bruno-docs-18). Community reports corroborate the offline-first, git-based self-managed workflow. missing for 10: no explicit multi-user self-hosted 'server/sync' deployment guide since the product is architected as a local-only client rather than a hosted service, so there's nothing analogous to a self-hosted backend to document beyond what's given.
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Available for Windows, macOS and Linux.”
- [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to BrunoKongnone0/10Kong is self-hostable (Gateway can be deployed anywhere, giving implicit data-location control), but the evidence pack contains no explicit region/residency selection feature, no Konnect region options, and no documentation letting a user choose where data is stored.
Bruno's local-first architecture ("No cloud sync... stores your collections directly in a folder on your filesystem", "offline-only... no plans to add cloud-sync, ever") means data effectively stays wherever the user's machine/filesystem is located, giving implicit control over data location rather than an explicit region/residency selector. There is no documented feature letting users choose a specific cloud region or residency zone since no cloud storage exists at all. Missing for 10: explicit region-selection UI/settings, enterprise data-residency controls, or documentation addressing multi-region compliance for any hosted/team features.
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
ai-native userPrevent my data from being used to train AI models
weight 3 · round to BrunoKongnone0/10Kong's AI Gateway evidence covers traffic routing, semantic security/caching, observability, and MCP governance, but nothing in the pack addresses controlling or opting out of AI model training on user data. Missing for 10: any documented feature or policy for preventing data from being used in model training (e.g., zero-retention enforcement, provider opt-out headers, data-use contracts).
- [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
- [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
- [github] “advanced AI traffic capabilities with multi-LLM support, semantic security, MCP traffic security and analytics”
Bruno explicitly states it does not train AI models on user data, has no cloud sync/account, and its AI features use a Bring-Your-Own-Key model where no data is routed through Bruno servers, giving clear first-party assurance against AI training use. missing for 10: independent/hands-on confirmation specifically verifying the no-AI-training claim (community evidence corroborates offline/git-first posture but not this specific claim).
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
ai-native userControl data retention and deletion
weight 2 · round to BrunoKongnone0/10Kong's AI Gateway docs cover logging locations, DLP/PII redaction, and secrets vaulting, but there is no documented capability for AI-native users to set data retention windows or explicitly delete stored logs/request data. missing for 10: retention policy configuration, data deletion/purge mechanism, user-facing controls over stored AI traffic data.
- [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
- [claimed-docs] “By default, you can view AI Gateway logs at `/usr/local/kong/logs/error.log`. If you're running an AI Gateway data plane in Docker, you can …”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
Bruno's offline-first, no-cloud, no-account architecture (local filesystem storage, no telemetry on requests, no AI training on data, BYOK for AI features) inherently gives users full control over data retention since nothing is stored or synced by Bruno servers by default. However, there's no explicit deletion/retention control feature or policy documentation for cases like secret managers, sync features, or team/cloud add-ons. missing for 10: explicit data retention/deletion controls or settings, documentation on how synced/team-tier data (if any) is retained or purged, independent verification of the 'zero visibility' claim.
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round to BrunoKongnone0/10No evidence in the pack addresses telemetry opt-out or usage tracking controls for Kong products; nothing documents a privacy/telemetry setting.
Bruno's marketing emphasizes an offline-first, no-account, no-cloud-sync design with 'zero visibility into your requests' and no AI training on user data, implying no telemetry on API usage by design (bruno-docs-8, bruno-docs-48, bruno-docs-9). However, there is no explicit documentation of a telemetry/analytics toggle or opt-out setting for app-level usage tracking (e.g., crash reporting, feature analytics), so the claim is inferred from architecture rather than an explicit privacy control. missing for 10: explicit telemetry/analytics opt-out setting or documentation, independent verification of no background usage tracking.
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
Spec design — stories about spec design in this arenaSpec design
Stories about spec design in this arena
Docs generation
developerGenerate and publish API documentation from my collections or specs
weight 2 · round to KongKong's Dev Portal explicitly lets developers publish APIs using OpenAPI or AsyncAPI specifications plus Markdown documentation, with configurable public/private visibility, and lets consumers browse/search that documentation and manage credentials — directly matching the story of generating and publishing docs from specs. Missing for 10: explicit support for importing arbitrary 'collections' (e.g., Postman-style) rather than just OpenAPI/AsyncAPI specs, and independent/hands-on corroboration beyond first-party docs.
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
- [claimed-docs] “Public visibility without authentication”
- [claimed-docs] “Private visibility with authentication enabled”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
Bruno docs explicitly state you can 'Write docs with your collections; publish as shareable HTML' plus a rich text docs editor, directly matching the story of generating/publishing API documentation from collections. However this is a single doc-feature mention with no independent/community corroboration, no detail on hosting/sharing workflow, and no support for generating docs from external specs (e.g. OpenAPI import/export to docs). missing for 10: independent verification of the publish-as-HTML feature, detail on doc customization/publishing workflow, and spec-based (OpenAPI) doc generation.
- [claimed-docs] “Write docs with your collections; publish as shareable HTML.”
- [claimed-docs] “feat(docs): Rich text docs editor”
Spec import export
developerDesign an API spec-first and export it as OpenAPI
weight 2 · round drawnKongnone0/10Kong's docs show it can import/publish existing OpenAPI specs (e.g., Dev Portal publishing APIs using OpenAPI/AsyncAPI, decK declarative config) but there is no evidence of a spec-first design/authoring workflow or an OpenAPI export feature for specs created within Kong. missing for 10: a spec-design/editor capability, evidence of generating/exporting an OpenAPI document from a user-authored spec.
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
Brunonone0/10Evidence pack shows Bruno's collections are stored as plain-text .bru files, supports Postman import/export, CLI runs, and Git integration—but nothing about spec-first design workflows or generating/exporting OpenAPI specifications. The probe explicitly found no OpenAPI schema/documentation endpoints exposed.
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.usebruno.com/openapi.json, https://docs.usebruno.com/swagger.json, https://docs.usebrun…”
developerImport an OpenAPI spec to generate requests and collections
weight 3 · round to KongKong's Dev Portal can publish APIs from OpenAPI/AsyncAPI specs and lets developers 'browse and search API documentation, try API operations' (kong-docs-21, kong-docs-49), which is loosely analogous to generating requests from a spec, but there's no evidence of a Postman-like 'collections' concept or explicit request/collection generation workflow. missing for 10: explicit OpenAPI-import-to-request/collection generation feature, evidence of a collections concept, and any hands-on demonstration of this workflow.
- [claimed-docs] “It enables developers to browse and search API documentation, try API operations, and manage their own credentials.”
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
Brunonone0/10The evidence pack documents Postman collection import (bruno-docs-24, bruno-docs-25, bruno-docs-7) but contains no mention of importing OpenAPI/Swagger specs to generate requests or collections. This is a fair axis for an API client tool, but no supporting evidence exists in the pack.
Testing mocking — stories about testing mocking in this arenaTesting mocking
Stories about testing mocking in this arena
Contract testing
platform-engineerValidate live responses against the API contract to catch drift
weight 2 · round to BrunoKongnone0/10Kong is an API gateway/traffic management platform with plugins for routing, security, rate limiting, and AI/MCP governance, but there is no evidence of a contract-testing or response-validation-against-spec feature to catch API drift; this is a testing/mocking capability that a full lifecycle toolchain could offer but Kong's evidence pack shows no such capability.
Bruno documents general test assertions, data-driven test suites, and CI/CD integration for automated runs (bruno-docs-32, bruno-docs-3, bruno-docs-30), which teams could use to assert response shape/status manually, but there is no evidence of a dedicated schema/contract validation feature (e.g., importing/validating against an OpenAPI spec) to explicitly catch API drift. Missing for 10: explicit OpenAPI/contract schema validation capability, documented drift-detection workflow, and any first-party or community evidence of contract testing use.
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [claimed-docs] “create reports in multiple formats, including JSON, JUnit, and HTML”
Not comparable on these axes
ai-native userSubscribe to events via webhooks
weight 2 · not comparableKongnone0/10Kong is an API/AI gateway product; the evidence covers proxying, MCP, LLM routing, logging, and OpenTelemetry metrics, but there is no mention of webhook subscription or event-driven notification delivery to AI-native consumers.
ai-native userSet up automations that run autonomously in the background
weight 2 · not comparableKongn/aKong is an API/AI gateway and traffic-management platform (routing, security, observability for APIs, LLMs, MCP, A2A traffic) — it processes and governs requests, but it is not an automation/workflow engine and no evidence shows users can configure autonomous background-running automations within Kong itself; this axis is a category mismatch for a gateway product.
Bruno's CLI and CI/CD integration (bruno-docs-1,3,18,30) let you run collections unattended in pipelines like GitHub Actions or Docker, which is a form of background automation, but this is traditional scripted/CI automation rather than an AI-native agent autonomously deciding and scheduling actions. Bruno AI features (bruno-docs-37 to 42) are interactive, BYOK assistants for generating scripts/collections, not autonomous background agents. Missing for 10: evidence of scheduled/triggered autonomous runs initiated by AI, agent-driven decision loops, or any 'set it and forget it' automation beyond manual CI/CD wiring.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
ai-native userSchedule recurring jobs or workflows
weight 2 · not comparableKongn/aKong is an API/AI gateway and traffic management platform; scheduling recurring jobs or workflows is outside its product category (it manages request routing, security, and observability, not job/workflow scheduling). This is a category mismatch rather than a missing feature.
Bruno CLI can be run inside CI/CD pipelines (GitHub Actions, Docker) which could be scheduled externally via cron/CI triggers, but there is no evidence of a native scheduler or built-in recurring-job feature within Bruno itself. missing for 10: any built-in scheduling UI/feature, documentation of cron-like triggers within Bruno, independent confirmation of scheduled runs.
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
developerRun my API test collections in CI with a CLI and fail the build on regressions
weight 3 · not comparableKongn/aKong is an API gateway/management platform (plus decK/kongctl CLIs for config management), not an API testing tool; there's no evidence of test-collection running or CI regression-testing CLI functionality, which is a wrong axis for this product category.
Bruno CLI is well documented for running collections headlessly, generating JUnit/JSON/HTML reports for CI analysis, and integrating with CI/CD pipelines (Docker, GitHub Actions), which directly supports failing builds on test regressions. missing for 10: explicit documentation/example of exit-code-based build failure and independent hands-on CI usage report beyond vendor docs.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
developerSchedule collection runs as monitors that alert me when an API breaks
weight 2 · not comparableKongn/aKong is an API gateway/AI gateway platform, not a Postman-style API testing tool; scheduled collection runs as monitors that alert on API breakage is a Postman-specific ci-scripting concept with no analog in Kong's evidence (gateway health checks, observability, and rate limiting are not the same as request-collection monitors). This axis is a category error for a gateway product.
Brunonone0/10Bruno's docs show CLI runs, CI/CD pipeline integration, and JUnit/HTML/JSON reports, but there is no evidence of a built-in monitor/scheduler feature that runs collections on a schedule and alerts on failures — that requires wiring Bruno CLI into an external scheduler (e.g. cron/CI cron jobs) rather than a native monitoring product feature. missing for 10: a documented native scheduling/monitor feature, built-in alerting (email/Slack/webhook) on failed runs, any dashboard for monitor history.
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
developerShare collections with my team in a synced shared workspace
weight 3 · not comparableKongn/aKong is an API/AI gateway and traffic management platform, not a collaboration tool for sharing 'collections' (e.g., API request collections like Postman); this story's axis is a category error for this product type.
Bruno enables team sharing of collections via native Git integration (plain-text files, built-in Git UI, init/diff/pull/commit) rather than a cloud-synced workspace, and community reports confirm this works well in practice (bruno-comm-2, bruno-comm-7). However, Bruno explicitly states it has no cloud sync and never will, requiring git know-how instead of a true synced shared workspace experience. Missing for 10: real-time/automatic cloud sync, a dedicated shared-workspace UI independent of git, and conflict resolution beyond git merges.
- [claimed-docs] “Bruno's superpower is the ability to collaborate natively using version control systems like Git”
- [claimed-docs] “Core Git UI features (init, view diffs, check for updates, pull, clone) are now available in the free version.”
- [claimed-docs] “Bruno's built-in Git interface — init, diff, pull, commit, and more without leaving the app.”
- [claimed-docs] “There are two ways to collaborate via native Git in Bruno: 1. Using the terminal or command line to execute Git commands 2. Using Bruno's GU…”
- [claimed-docs] “Bruno is offline-only. There are no plans to add cloud-sync to Bruno, ever.”
- [claimed-docs] “No cloud sync. No account. No login. We have zero visibility into your requests, and we're not training AI models on your data.”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
- [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”
developerImport and export collections in portable formats to move between tools
weight 2 · not comparableKongn/aKong is an API gateway/management platform, not an API-client tool built around request 'collections' (like Postman/Insomnia). Its decK tool exports/imports declarative gateway *configuration* state, not portable request collections meant to move between different client tools, so this axis is a category mismatch for Kong's product type.
Bruno documents importing existing Postman collections and even a 'preserve scripts' option for Postman import/export, plus its own portable plain-text .bru format that lives on the filesystem for easy sharing/versioning. However, evidence only covers Postman interoperability and lacks documentation of exporting to other formats (e.g., OpenAPI, Insomnia) or independent confirmation of import fidelity. Missing for 10: explicit export-to-Postman/OpenAPI support, broader multi-tool interoperability, and hands-on community verification of import/export accuracy.
- [claimed-docs] “it also has a feature for importing your existing Postman collections to Bruno”
- [claimed-docs] “feat: add preserve scripts option for Postman import/export”
- [claimed-docs] “add preserve scripts option for Postman import/export”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
developerOrganize API requests into collections and folders and rerun them anytime
weight 3 · not comparableKongn/aKong is an API gateway/management platform, not an API client tool for testing requests; organizing requests into collections/folders for rerun is a Postman-like client feature, which is a category error for this product type.
Bruno stores collections as plain-text files/folders on the filesystem (supporting folder-based organization), integrates with Git for versioning, and provides a CLI plus GUI to rerun collections anytime, corroborated by community testimonials praising collection organization and git-based rerun workflows. missing for 10: explicit documentation of nested folder hierarchies/UI screenshots and independent hands-on verification of large/complex folder structures.
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem.”
- [claimed-docs] “Bruno stores your collections directly in a folder on your filesystem. We use a plain text markup language, Bru, to save information about A…”
- [claimed-docs] “Collections live as plain text files on your filesystem, so you can version them with Git and review API changes like code.”
- [claimed-docs] “you can run your API collections with ease using simple command line commands”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [community] “I've replaced Postman with Bruno (desktop app), works great so far! It's nice to put the collection folder in git so I can collaborate with …”
- [community] “Having version controlled api collections is a good enough idea that it makes all other ideas seem a little crazy.”
developerSend GraphQL, gRPC, WebSocket, and SSE requests, not just REST
weight 2 · not comparableKongn/aKong is an API gateway/proxy runtime, not an API client or request-testing tool with collections/workspaces; the story concerns a developer authoring and firing test requests (as in a REST client), which is not a role Kong fills. Evidence shows Kong routes/proxies REST, gRPC, and AI/LLM traffic as infrastructure, but nothing suggests a client UI for composing/sending GraphQL, gRPC, WebSocket, or SSE requests — this axis is a category mismatch for a gateway product.
Brunonone0/10No documentation in the evidence pack mentions GraphQL, gRPC, WebSocket, or SSE support; community feedback explicitly states Bruno lacks GraphQL, gRPC, and WebSocket support ('Only missing Websockets functionality', 'Doesn't seem to support advanced stuff like GraphQL, gRPC, WebSockets').
- [community] “I found Bruno after Insomnia adopted the Postman strategy of being cloud first, with a disastrous migration. I've been using it for a while …”
- [community] “Doesn't seem to support advanced stuff like GraphQL, gRPC, WebSockets...”
ai-native userProxy and govern LLM/MCP traffic (token limits, prompt guards, provider routing) through the platform
weight 2 · not comparableKong's AI Gateway explicitly proxies and governs LLM traffic (multi-provider routing, rate limiting, semantic security, DLP/prompt guards, cost control) and dedicated MCP Gateway capabilities cover MCP traffic governance, security, observability, and auto-generation, with docs on rate-limiting plugins, data governance/prompt safety, provider routing, and OTel metrics for GenAI/MCP/A2A traffic. Missing for 10: independent hands-on validation of the AI Gateway/MCP governance features specifically (community evidence only covers unrelated core gateway routing bugs).
- [claimed-docs] “Connectivity and governance layer for modern AI-native applications”
- [claimed-docs] “Gain control and visibility over AI agent infrastructure with AI Gateway-driven MCP capabilities”
- [claimed-docs] “The core of AI Gateway is the ability to serve AI Models from various AI Model Providers via a provider-agnostic API.”
- [claimed-docs] “AI Gateway can proxy requests from AI command-line tools to LLM providers. This gives you centralized control over AI traffic: log all reque…”
- [claimed-docs] “Apply safety and DLP policies to prevent toxic content and remove personally identifiable information. This can be an important part of best…”
- [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
- [github] “MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.”
- [github] “60+ AI features like AI observability, semantic security and caching, semantic routing and more.”
- [github] “advanced AI traffic capabilities with multi-LLM support, semantic security, MCP traffic security and analytics”
- [claimed-docs] “Rate Limiting - Plugin”
- [claimed-docs] “MCP Traffic Gateway”
Brunon/aBruno is an API client/collection tool for testing REST/GraphQL APIs; it is not an LLM/MCP gateway or proxy product. Nothing in the evidence relates to proxying or governing LLM/MCP traffic, token limits, prompt guards, or provider routing — this is a category mismatch, not a missing feature.
platform-engineerManage API infrastructure as declarative config and sync it from CI (GitOps/APIOps)
weight 2 · not comparabledecK and kongctl are dedicated CLIs for declarative APIOps, explicitly designed for CI-driven sync of Kong config (declarative databaseless deployment, Admin API/decK configuration), which directly matches the GitOps/APIOps story. missing for 10: no explicit worked CI pipeline example (e.g., GitHub Actions) or independent case study confirming production GitOps workflows.
- [claimed-docs] “decK is a command line tool that facilitates API Lifecycle Automation (APIOps) by offering a comprehensive toolkit of commands designed to o…”
- [claimed-docs] “Tools for managing Konnect and Kong Gateway”
- [claimed-docs] “decK | Kong Docs”
- [claimed-docs] “kongctl | Kong Docs”
- [github] “Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without…”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
- [github] “there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode”
Brunon/aBruno is an API client/testing tool (collections, requests, CLI) not an API gateway or infrastructure control-plane; it has no concept of managing routes, policies, or gateway configuration as declarative infra. The 'API infrastructure' GitOps/APIOps axis targeted at gateway-traffic products doesn't apply to this product category.
platform-engineerMonitor API traffic with metrics, logging, and tracing integrations
weight 2 · not comparableKong ships built-in plugins for traffic controls, logging, and monitoring (kong-gh-3), Konnect provides status monitoring of control/data planes (kong-docs-46), and AI Gateway explicitly supports OpenTelemetry (OTLP) metrics export for AI/MCP/A2A traffic plus file/docker logs (kong-docs-61, kong-docs-69). However, a community GitHub issue reports a real production case where Kong logging failed to surface 404 errors during cache rebuilding (kong-comm-1, kong-comm-2), showing logging gaps in practice, and the evidence pack lacks explicit documentation of a dedicated distributed-tracing integration (e.g., Zipkin/Jaeger) beyond OTel metrics. missing for 10: explicit tracing plugin/integration docs, and stronger independent confirmation that logging reliably surfaces all traffic issues.
- [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
- [claimed-docs] “Konnect lets you catalog, connect to, and monitor the status of all API Gateway control planes (CPs) and data plane nodes (DPs) in one place…”
- [claimed-docs] “AI Gateway can export OpenTelemetry (OTLP) metrics for generative AI, MCP, and A2A traffic through an OpenTelemetry AI Policy.”
- [claimed-docs] “By default, you can view AI Gateway logs at `/usr/local/kong/logs/error.log`. If you're running an AI Gateway data plane in Docker, you can …”
- [community] “We have noticed in our Kong Gateway nodes times when common endpoints throw 404 route not found on a % of API calls... nothing in Kong loggi…”
- [community] “To us the behavior points to cache rebuilding during new resource creation... production has not seen this issue with identical Kong configu…”
Brunon/aBruno is an API client/testing tool for building and running requests, not an API gateway or traffic-serving infrastructure; there is no evidence of it proxying or handling live API traffic that could be monitored with metrics/logging/tracing. This gateway-traffic observability story is a category mismatch for this product type.
platform-engineerEnforce authentication (API keys, OAuth2, JWT, mTLS) on upstream APIs via gateway plugins or policies
weight 3 · not comparableKong Gateway natively supports authentication plugins (JWT, basic auth, OAuth2, ACLs) as documented in its GitHub README and plugin hub, plus a quickstart demonstrating adding auth to an API in minutes; Vaults further support securing credentials/secrets referenced by these plugins. mTLS is a well-known Kong plugin capability implied by 'and more' but not explicitly cited in this pack. Missing for 10: explicit first-party documentation/example citing mTLS plugin configuration and independent hands-on validation of OAuth2/mTLS enforcement specifically.
- [github] “Authentication and authorization for APIs using methods like JWT, basic auth, OAuth, ACLs and more.”
- [github] “Let’s test drive Kong by adding authentication to an API in under 5 minutes.”
- [github] “Let's test drive Kong by adding authentication to an API in under 5 minutes.”
- [github] “providing functionality for proxying, routing, load balancing, health checking, authentication (and more)”
- [github] “By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central lay…”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities”
- [claimed-docs] “Vaults allow you to securely store and then reference secrets from within other entities, ensuring that secrets aren't visible in plaintext …”
- [claimed-docs] “You can add secrets to Vaults in one of the following ways: * Environment variables * Konnect Config Store * Supported third-party backend v…”
Brunon/aBruno is an API client/testing tool for developers to make and test API requests; it has no gateway/proxy or policy-enforcement layer to sit in front of upstream APIs. Enforcing authentication on upstream traffic via gateway plugins is a category error for this product type — Bruno's auth support (OAuth2, mTLS certs) is client-side for calling APIs, not for protecting them.
platform-engineerEnforce rate limits on API traffic per consumer or route
weight 3 · not comparableKong ships a dedicated Rate Limiting plugin (kong-docs-64) and its plugin architecture explicitly supports 'enforcing traffic controls, rate limiting' (kong-gh-3), configurable per consumer or route via Admin API/decK. This is a well-documented core gateway capability with first-party docs and consistent GitHub descriptions. Missing for 10: independent hands-on verification of per-consumer vs per-route configuration nuances.
- [claimed-docs] “Rate Limiting - Plugin”
- [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
- [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
- [github] “:8001 - configure Kong using Admin API or via [decK](https://github.com/kong/deck)”
platform-engineerRoute, load-balance, and transform requests between consumers and upstream services
weight 2 · not comparableKong Gateway is explicitly documented as providing advanced routing, load balancing, health checking, and request/response transformation plugins, configurable via Admin API or declarative config, positioning it as the central layer for orchestrating microservices traffic between consumers and upstreams. This is corroborated by both first-party docs and the GitHub README's feature list. missing for 10: independent hands-on benchmark or case study specifically validating load-balancing/transformation behavior at scale beyond vendor-provided descriptions.
- [github] “Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.”
- [github] “providing functionality for proxying, routing, load balancing, health checking, authentication (and more)”
- [github] “By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central lay…”
- [github] “Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.”
- [claimed-docs] “Kong Gateway is a lightweight, fast, and flexible cloud-native API gateway. An API gateway is a reverse proxy that lets you manage, co”
- [claimed-docs] “Rate Limiting - Plugin”
platform-engineerLint API specs against configurable style and governance rules
weight 3 · not comparableKongn/aKong is an API gateway/runtime and management platform for proxying, securing, and governing API traffic (and AI/MCP traffic); it manages APIs at runtime and via a catalog, but nothing in the evidence shows spec-linting or design-time governance rule enforcement against OpenAPI/AsyncAPI style rules. This capability belongs to a spec-design/linting tool category, not a gateway product, so the axis does not apply.
- [claimed-docs] “Kong Gateway is a lightweight, fast, and flexible cloud-native API gateway. An API gateway is a reverse proxy that lets you manage, co”
- [claimed-docs] “Directory of OpenAPI specifications for various Kong APIs.”
- [claimed-docs] “Dev Portal APIs allow you to publish APIs using OpenAPI or AsyncAPI specifications and Markdown documentation.”
- [claimed-docs] “Catalog is where these interfaces live instead: APIs, AI Models, and more. Instead of digging through individual products to find what alrea…”
Brunon/aBruno is an API client/collection tool focused on request execution, testing, and collaboration; it has no evidence of a spec-linting or governance-rules engine (e.g. Spectral-like style guides) for API specs, which is a distinct product category (API design/governance linter). This axis targets spec-design linting tools, not API clients.
ai-native userHave AI generate test cases or assertions for an endpoint from its spec or responses
weight 2 · not comparableKongn/aKong is an API/AI gateway and traffic management platform, not a testing/mocking tool; there is no evidence of any capability to generate test cases or assertions from an API spec or responses. This capability is outside Kong's product category (gateway/governance vs. test generation), so the axis does not apply.
Bruno AI can generate test/assertion scripts via the AI icon in a request's Scripts tab (bruno-docs-38) and can auto-generate whole collections—including tests—from backend source code (bruno-docs-41), which covers 'from spec' generation. However, there's no explicit documentation of generating assertions directly from example responses, and no independent/hands-on confirmation of this AI feature's real-world reliability. Missing for 10: evidence of generating tests specifically from response bodies/OpenAPI specs, and independent verification of output quality.
- [claimed-docs] “Open the Scripts tab on any request, folder, or collection. Click the AI icon, describe what you need, and Bruno generates a script.”
- [claimed-docs] “Generate Bruno collections – Create API collections from your backend source code with requests, tests, and documentation.”
- [claimed-docs] “Ghost-text suggestions appear as you type in Pre-Request, Post-Response, and Tests script editors.”
- [claimed-docs] “Bruno AI uses a Bring Your Own Key model. You connect your own provider account and Bruno uses it directly. No data is routed through Bruno …”
developerSpin up a mock server from saved examples or a spec so consumers can build before the API exists
weight 3 · not comparableKongn/aKong is an API gateway/management platform for proxying, securing, and governing real API traffic — it is not a mock-server or API-design tool for simulating not-yet-built APIs from examples/specs. This capability is a category error for Kong's product type, not a missing feature.
Bruno's marketing site claims it can 'serve realistic mock responses while you build' (bruno-docs-4), which directly supports a mock-server capability, but there is no further documentation on how mocks are configured (from saved examples, specs, or otherwise), no CLI/spec-based generation details, and no community corroboration of this feature in practice. missing for 10: detailed docs on mock configuration/spec-driven generation, independent/hands-on validation of the mocking feature, examples of using saved request examples as mock responses.
- [claimed-docs] “Serve realistic mock responses while you build.”
developerRun an entire collection as an automated test suite with a pass/fail report
weight 3 · not comparableKongn/aKong is an API gateway/AI gateway product, not an API client/testing tool with collections and test suites; running a 'collection' as an automated test suite with pass/fail reporting is a Postman/Insomnia-style feature, not applicable to a gateway's category.
Bruno CLI documented to run entire collections from command line, generate pass/fail-style test reports in JSON/JUnit/HTML formats, and integrate into CI/CD pipelines (Docker, GitHub Actions), plus native assertions/test suites with data-driven testing support. Missing for 10: independent hands-on report specifically confirming CLI test-run reporting in practice (community evidence focuses on desktop app, not CLI runs).
- [claimed-docs] “With Bruno CLI, you can run your API collections with ease using simple command line commands.”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”
- [claimed-docs] “CI/CD Integration: Effortlessly integrate with CI/CD pipelines for automated testing and validation.”
- [claimed-docs] “Official Docker images for the Bruno CLI let you run API collections in CI/CD pipelines and locally without installing Node.js or npm on the…”
- [claimed-docs] “Run your collections in Docker, GitHub Actions, and other pipelines.”
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [probe] “official CLI documented at https://docs.usebruno.com/bru-cli/overview”
developerWrite test assertions against response status, body, and headers
weight 3 · not comparableKongn/aKong is an API gateway/traffic management product, not a testing/mocking framework; there is no evidence of a test-assertion framework for response status, body, or headers. This story targets test-authoring tools, which is a different product category than a gateway.
Bruno's official docs state you can 'Write assertions and test suites, and automate runs with data-driven testing' and generate JSON/JUnit/HTML test reports, confirming built-in test/assertion functionality against API responses. However, the evidence never explicitly breaks down assertions by status code, body, and headers separately. missing for 10: explicit doc examples of status-code/body/header assertion syntax, independent hands-on confirmation of assertion granularity.
- [claimed-docs] “Write assertions and test suites, and automate runs with data-driven testing.”
- [claimed-docs] “create reports in multiple formats, including JSON, JUnit, and HTML”
- [claimed-docs] “Generate Test Reports : Easily create reports in multiple formats, including JSON, JUnit, and HTML, to analyze and share test results.”