Apinto is an open-source, cloud-native API gateway written in Go and released under the Apache-2.0 licence, built for teams that need to manage API services and raise their stability and security.

What it is

Apinto is a gateway developed in Go with a modular architecture, described by its maintainers as high-performance, extensible and easy to maintain. It sits at the entry point of business traffic, where it handles dynamic routing, load balancing, service discovery, circuit breaking, identity authentication, monitoring and alerting. It is not tied to any cloud platform, and the project ships a separate management console, Apinto Dashboard, maintained in its own repository at eolinker/apinto-dashboard. The registry entry lists it under Developer Tools / API Development & Testing, with topics covering api-gateway, microservice, grpc, dubbo2, goku and loadbalancer.

The concrete problem it addresses is configuration sprawl across clusters. When business configuration has to be maintained as separate sets for each cluster, operations cost rises and the chance of configuration mistakes rises with it. Apinto's cluster management lets a team configure business once and publish it to the relevant clusters, so gateway nodes can be freely added or removed without rewriting the configuration per cluster. A second problem is service governance: rather than pushing rate limiting, circuit breaking, caching and canary releases into individual services, Apinto applies those rules at the gateway by filtering traffic on combinations of application, API, upstream, request method, IP, request path and custom application labels.

Key capabilities

• Dynamic routing matches services on location, query, header, host and method parameters.
• Service discovery integrates with Eureka, Nacos and Consul.
• Protocol support covers HTTP/HTTPS, Webservice, Restful, gRPC, Dubbo2 and SOAP.
• User authentication supports anonymous access plus Basic, Apikey, JWT and AK/SK schemes.
• Traffic policy features include blacklists and whitelists by application and IP, request count and payload size limits, circuit breaking, canary releases by percentage or advanced rules, response caching and traffic mirroring.
• Request transformation covers parameter mapping, extra backend parameters, and rewriting of scheme, uri and host along with adding or deleting forwarded headers.
• Request logs can be sent to receivers such as file, nsq and kafka, and the CLI installs and downloads plugins and starts or stops the gateway.
• API documentation can be synchronised through OpenAPI using Swagger 3.0 json or yaml files.

Who uses it and how

• Operations teams running several gateway clusters, who configure a business once and publish it to the appropriate clusters instead of duplicating configuration sets.
• Platform teams that need application-level lifecycle management, where the application is treated as the initiator of business communication and is authenticated and governed across the whole call chain.
• Teams exposing gRPC or Dubbo2 backends behind a single HTTP/HTTPS entry point, with health checks on load-balanced nodes and SSL certificate management for multiple certificates.
• Teams needing canary releases and traffic mirroring without changing application code, filtering live requests by application, API, upstream, method, IP or path.
• Enterprise users who intend to build custom enterprise plugins, since the project supports user-defined enterprise plugins and independent deployment.

Getting started

The README documents direct deployment, compiling from source, and Docker deployment through the published image eolinker/apinto-gateway on Docker Hub. A release archive such as apinto_v0.12.1_linux_amd64.tar.gz can be downloaded and extracted, and a hosted console is available at demo-dashboard.apinto.com with trial accounts apinto-1 through apinto-3.

How it compares

This registry entry provides no list of paid products that Apinto replaces, and the README names no directly comparable gateway projects, so the page cannot draw a contrast with named commercial alternatives. The only tools the facts place alongside it are integration targets rather than competitors: Eureka, Nacos and Consul for service discovery. On the evidence available, it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate one or more gateway nodes and, if request logs are centralised, the receiving infrastructure behind the file, nsq or kafka outputs. Kubernetes deployment is listed as planned rather than supported, and the enterprise plugin module is described as forthcoming, so teams needing either today should wait or expect to build it themselves. The README excerpt is cut off mid-command during the startup instructions, and the enterprise plugin list — user role permissions, monitoring, API documentation, security testing, national cryptography and more — is a roadmap rather than shipped functionality.

wget https://github.com/eolinker/apinto/releases/download/v0.12.1/apinto_v0.12.1_linux_amd64.tar.gz && tar -zxvf apinto_v0.12.1_linux_amd64.tar.gz && cd apinto

./install.sh install

apinto start