Apinto gates traffic by application, API and upstream rather than by URL

Policies are filtered on combinations, not on routes

Apinto's defining idea is that traffic governance is not a property of a URL. The README describes a fine grained traffic management scheme in which every caller request passes through the gateway, and traffic is selected by combinations of conditions on the application, the API, the upstream service, the request method, the IP, the request path and application defined custom tags. Those selected requests then get rate limits, access control, circuit breaking, canary releases and caching applied.

Read the feature table and this pattern repeats in every row. The blacklist and whitelist entry supports multi dimension filtering with black and white listed IPs. The access policy entry adds combinations of application and IP, application and API, application and upstream. The traffic policy entry limits request counts and request body size across the same combinations. Circuit breaking, canary and caching are each described the same way: filter by multiple dimensions first, then act.

The routing layer sits underneath. Dynamic routing matches a service by setting location, query, header, host and method parameters. Forward rewriting covers `scheme`, `uri` and `host`, plus adding or removing header values on the forwarded request. Parameter mapping moves client request parameters into the forwarded request, changing their position and name as needed, and an extra parameter option adds backend verification parameters such as an apikey on the way out.

So the gateway is not just a reverse proxy with a rate limiter bolted on. The unit of configuration is a filter expression, and the policy is what you attach to the expression.

Protocols and service discovery are the parts that decide fit

Two capability lists determine whether Apinto fits your estate.

The first is protocols. The README lists HTTP/HTTPS, Webservice, Restful, gRPC, Dubbo2 and SOAP. That list is what separates it from a plain HTTP gateway, and the repository backs it up structurally: there is a `dubbo-getty/` directory, a `grpc-descriptor/` directory, and example projects under `example/dubbo2/` and `example/grpc/`. The dependency list also includes `dubbogo/gost`, `jhump/protoreflect`, `fullstorydev/grpcurl` and `google.golang.org/grpc`.

The second is service discovery. Eureka, Nacos and Consul are all supported, and the dependency list includes `hashicorp/consul/api`, `nacos-group/nacos-sdk-go/v2` and `polarismesh/polaris-go`. Health checking of upstream nodes is also listed as a product feature, and the repository has `health-check-http/` and a `checker/` directory.

Load balancing is described in one line, round robin with weights. If you need consistent hashing or least connections, the README does not claim it.

Authentication is broader than most gateways in this category: anonymous, Basic, Apikey, JWT and AK/SK. The dependency list also includes `lestrrat-go/jwx` and `golang.org/x/oauth2`. Multiple SSL certificates can be managed, and an access domain can be set for the gateway itself.

On the runtime, `go.mod` declares `go 1.25.0`, and the module path is `github.com/eolinker/apinto`.

Plugin based, and the enterprise plugin module is described as forthcoming

The plugin model is stated twice: the repository description calls it a gateway built in Go with plugins that can be extended, plug and play, and the feature table describes a plugin architecture where the request flow is pluginised and modules are loaded on demand.

The plugin directory in the repository root matches that, alongside per concern directories: `plugin/`, `router/`, `strategy/`, `upstream/`, `discovery/`, `monitor-manager/`, `scope-manager/`, `output/`, `encoder/`, `certificates` as `certs/`, `drivers/`, `service/`, `application/`, `app/`, `node/`, `template/`, `entries/` and `ai-convert/`.

The interesting one is `ai-convert/`. The corresponding dependencies in `go.mod` are `sashabaranov/go-openai`, `pkoukk/tiktoken-go` and `ohler55/ojg`, a JSON path library. Token counting plus JSON manipulation plus an OpenAI client is what you would build on for converting structured documents, and the README does not describe the feature, so take the directory name as the only signal.

The console is a separate project. The README points at the Apinto Dashboard repository at github.com/eolinker/apinto-dashboard and describes the dashboard's four highlights as cluster management, application management, fine grained service governance and enterprise plugins.

That fourth item comes with a caveat. The enterprise plugin section says the module is about to be released, and lists what it will eventually provide: user role permissions, monitoring and alerting, logs, API documentation, an open platform, security protection, data analysis, call chains, mock, online debugging, security testing, national cryptography standards and multiple protocols. It also says custom enterprise plugins are supported and can be deployed independently. The verb tense matters. Treat that list as roadmap rather than shipped capability, and note that several of those names also appear in the feature table as available, so the boundary is not clean.

Open API support is listed as a way to configure the gateway programmatically, and there is a CLI for operating it, including one command plugin installation and download and starting or stopping the gateway. The dependency list also includes `urfave/cli/v2` and `soheilhy/cmux`.

Starting from a tarball, with two generated config files

The startup instructions are concrete, and they are old enough that the version number in them has moved on.

The README shows downloading and extracting a release tarball, using v0.12.1 as the example:

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

It then states that Apinto runs on arm64 and amd64, so you download the package matching your architecture and OS from the releases page. Releases are produced with `.goreleaser.yaml` at the repository root, which is why the archive naming is predictable.

Installation is a shell script inside the archive:

./install.sh install

That step generates two configuration files, `/etc/apinto/apinto.yml` and `/etc/apinto/config.yml`, which you can edit as needed. Startup is a single command, `apinto start`.

Two deployment routes are documented: a Docker image at hub.docker.com/r/eolinker/apinto-gateway and direct or source compilation guides on the help site. Kubernetes deployment is listed as coming later, which is the one line in that section that should stop a Kubernetes shop.

The README also claims a five minute deployment and simple configuration, and that is a marketing sentence rather than a measurement. What you can verify is the shape: one tarball, one install script, two YAML files, one start command. There is no configuration example in the README itself, so the two generated files are where you learn the schema.

A demo is available at demo-dashboard.apinto.com with three shared accounts, apinto-1, apinto-2 and apinto-3, each with the password 12345678, provided so that visitors do not evict each other. Shared credentials on a public demo mean you should treat anything you type there as public.

Release pace, licensing and what the docs do not cover

The release history is thin but regular: v0.22.17 on 2025-12-10, v0.22.18 on 2025-12-19, and v0.22.19 on 2026-01-16. Three patch releases in about five weeks, then nothing visible for the rest of the interval up to the last push on 2026-10-14.

That gap is worth noting rather than reading as abandonment. The repository is not archived and the default branch is `main`, and the README describes an iteration plan that is delivered as an image rather than a roadmap in text, so release activity and development activity are not the same signal here. The safe operational conclusion is simple: pin a version, and expect to do so deliberately.

The latest listed release is still in the 0.22 line, so upgrades and plugin compatibility should be evaluated carefully.

Documentation is the real gap. Almost every operational question routes to help.apinto.com, and the README itself is Chinese only for most of its content, with a separate `README_EN.md` in the repository root. The benchmark section is a single image, so the numbers behind it are not inspectable from the repository. Contributor guidance is split between two code of conduct files, `CODE_OF_CONDUCT.md` and `CODE_OF_CONDUCT_EN.md`, both carrying a Contributor Covenant 2.1 badge, plus a `CONTRIBUTING.md`.

The licence is Apache-2.0, with a `LICENSE` file at the root. That is permissive and includes an explicit patent grant, which matters for a gateway that sits in front of paid APIs. This is a statement about the licence text, not advice about your deployment.

Two features deserve a second look for compliance work. The flow mirroring entry copies live traffic or request content to a mirror service, and the mock entry simulates a web server API response. Both are standard gateway capabilities and both duplicate real request data somewhere else, so they belong in your data handling review rather than in a features list.

Editorial conclusion

Adopt Apinto if you run Go services behind a gateway and want routing, service discovery, auth and governance policies configured once and pushed across a cluster, and you read Chinese documentation comfortably. Do not adopt it if you need Kubernetes deployment today, since the README marks that as later support, or if your team cannot work with documentation hosted at help.apinto.com. Verify first that release binaries exist for your architecture, since the README shows a linux amd64 tarball and mentions arm64, and pin v0.22.19 or newer rather than tracking the main branch.

Frequently asked questions

Official sources

1. eolinker/apinto on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases