// the take
Apinto is a Go-based API gateway from eolinker, built around a plugin architecture with built-in support for HTTP/HTTPS, gRPC, Dubbo2 and SOAP. It's aimed at enterprises that need a self-hosted gateway with service discovery, auth, rate limiting, and circuit breaking, plus a surprisingly large set of AI-provider proxy plugins (OpenAI, Anthropic, Bedrock, Azure OpenAI, and a dozen+ others).
The plugin set for service discovery is genuinely broad — Eureka, Nacos, Consul, Kubernetes and Polaris are all first-class drivers, not just HTTP-only. Protocol support beyond REST (gRPC, Dubbo2, SOAP) is rare in gateways this size and matters if you're fronting legacy or Java-microservice backends. The driver/factory pattern used throughout (auth, discovery, output, ai-provider) keeps each integration isolated, so adding a new backend doesn't touch core routing code. Cluster management handles config distribution across nodes without a separate config-sync tool.
The actual admin dashboard and control plane live in a separate, closed-source-leaning repo (apinto-dashboard) — the OSS gateway by itself is config-file/CLI driven, so the 'open source' pitch is really 'open source data plane, proprietary-adjacent control plane.' Documentation, the community forum, and support channels (WeChat group, help.apinto.com) are Chinese-first; the English README is a translation afterthought, which will slow down non-Chinese-speaking teams hitting edge cases. Kubernetes deployment is listed as 'coming later' despite the cloud-native framing, so running this on k8s today means rolling your own manifests. At ~1.7k stars with most AI-provider plugins added recently, the breadth looks more like a feature checklist than battle-tested integrations — worth load-testing the specific plugins you need rather than trusting the full list.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →