Model or dataset
fizzgate/fizz-gateway-node avatar
fizzgate/fizz-gateway-node

FizzGate: a Java API gateway that covers the whole API lifecycle

API聚合网关 An Aggregation API Gateway 大模型网关、API集成、API脱敏、API安全、API溯源、

1,079 stars293 forksJavaAGPL-3.0

At a glance

What is it?
fizz-gateway-node is the Java node component of FizzGate, a Chinese-built API aggregation gateway offering service orchestration, masking, tracing, rate limiting and an LLM routing layer, distributed as a Docker Compose stack with MySQL and Redis. It suits teams standardising on a self-hosted gateway, and the AGPL-3.0 licence plus the split between a community node and a paid console is what to weigh first.
Who is it for?
FizzGate is worth evaluating if your organisation wants a self-hosted gateway covering API integration, masking, tracing and LLM routing in one Java stack, since the feature set in the README is unusually broad and the deployment is a single Compose file.
Can I use it commercially?
Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?
Yes. The repository last received commits 113 days ago.
What is it written in?
Mainly Java, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The repository is only the node half of a two-part product

fizz-gateway-node is the node component of FizzGate, and the README is explicit that it is one of a matched pair. The version comparison table lines up fizz-gateway-node with fizz-manager-professional across versions from v1.3.0 up to v3.6.0, and the note under it says that versions before 3.0.0 have stopped being maintained and that you should download the console version matching your node version. The console is a separate downloadable package, fizz-manager-professional, which the README describes as the management backend. This is not a minor packaging detail. The node is the data path and the console is where configuration happens, so a mismatch is not a cosmetic problem. The node here is AGPL-3.0.

What the gateway actually does spans five areas

The feature list is grouped by the stage of the API lifecycle rather than by component. On API management there is application management, API definition with backend service configuration, full request logging, grouping, service authentication through chained interception plugins, cluster management, built-in key-auth, JWT and basic-auth, round-robin load balancing, circuit breaking per service or address, service discovery from Eureka or Nacos, Apollo as a configuration centre, HTTP reverse proxying, access policies, black and white lists, custom plugins, a management console, callback management with subscription, replay and logs, and multi-level rate limiting by service, interface, APP_ID and IP. The masking area covers classification and grading of sensitive data, masking of structured and unstructured data, visual policy configuration, and detection of sensitive data. The tracing area adds visible watermarks to proxied pages and leak tracing back to context and terminal information.

The sidecar security analysis is passive, with a blocking option

The security section is labelled as sidecar analysis, and that label describes the design. Asset analysis generates an API Spec to help detect potential risks, sensitive data detection finds leaks in API traffic in real time, threat detection spots abnormal access behaviour, and vulnerability scanning produces reports on API interfaces. What separates this from pure observation is the blocking capability, which supports automatically or manually blocking API access when an anomaly is found, to stop an attack from spreading. The watermark support covers HTML, Word, Excel, PowerPoint and PDF, plus PNG, JPEG and TIFF, and the leak tracing area supports the same set of formats for JSON and HTML content. This is a compliance-flavoured feature set, aimed at organisations that have to answer questions about who accessed which data.

The AI layer routes across providers and pools of accounts

A separate API AI section covers a gateway in front of large language models. Global intelligent node scheduling is described for multi-region cluster deployments, automatically choosing an optimal AI node path for cross-region and cross-provider high availability access. Multi-channel and multi-account load balancing covers account pools, per-provider strategy weights and automatic failover on failure, so requests keep flowing. The billing and quota system is described as compatible with balance-based billing, token billing and card-based billing, with per-call detail, cost tracking and visualised usage records. On the agent side it claims native support for MCP tool calls, conversation-level memory management and external knowledge base retrieval.

The published benchmark compares against Kong, Spring Cloud Gateway and ShenYu

The README includes a benchmark table with a stated setup: an Intel Xeon E5-2650 v3 at 2.30 GHz times four, Linux 3.10.0, 8 GB of RAM, a single node, and a mock backend simulating 20 ms of latency with payloads of roughly 2 KB. At 600 concurrent requests, direct access to the backend gives 23540 QPS and 32.19 ms at 90th percentile latency, Kong v2.4.1 gives 15662 QPS and 50.87 ms, fizz-gateway-node v3.0.0 gives 12206 QPS and 65.76 ms, spring-cloud-gateway v2.2.9 gives 11323 QPS and 68.57 ms, and shenyu v2.3.0 gives 9284 QPS and 92.98 ms. At 1000 concurrent the same ordering holds. These are the vendor's own figures on one machine with a mock backend, so treat the relative ordering as a data point rather than a verdict.

Installation is a Compose stack with MySQL and Redis

The one-click path is a single shell command that fetches an install script and runs it.

bash
wget https://gitee.com/fizzgate/fizz-gateway-node/raw/master/install.sh && bash install.sh

The README explains that the one-click package uses docker-compose and that the yml file already embeds a mirror, and asks you to add a proxy mirror address before installing by configuring the Docker daemon.

bash
sudo tee /etc/docker/daemon.json <<EOF
{
    "registry-mirrors": ["https://hub.fizzgateway.com"]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

For a manual install, the dependencies are Redis v2.8 or above, MySQL v5.7 or above, and optionally Apollo as a configuration centre and either Eureka v1.10.17 or Nacos v2.0.4 or above for service discovery. The compose file in the repository root shows the shape of the stack, with a fizz-mysql service on 3306, a fizz-redis service on 6379, and the gateway community container publishing 8803 to 8600, configured with a redis host, port, empty password and database 9.

Java 8 is the target, and the deployment targets Chinese datacentres

The Dockerfile gives the runtime away. It builds FROM openjdk:8u342, sets an application home at /opt/fizz-gateway-community, copies the fizz-bootstrap jar and the log4j2-spring.xml configuration, adds the boot.sh and docker-entrypoint.sh scripts, and exposes port 8600. A Java 8 base image in 2026 is a deliberate choice rather than an oversight, and it is consistent with the stated support for arm64, amd64, x86 and x86_64 on Mac, Windows and Linux, plus support for domestic Chinese infrastructure including Kylin V10 and Dameng V8. The Maven wrapper at the repository root and the multi-module layout with fizz-core, fizz-common, fizz-plugin, fizz-bootstrap and a Spring Boot starter show a conventional Java project structure behind the gateway.

A community build with no support, and a paid console

The README is blunt about the commercial framing. It asks readers to buy or contact them, and states that the community version is provided for testing only with no technical consultation offered, and that a commercial version is needed for support through the enterprise WeChat channel. The demo environment comes with the same framing, noting that FizzGate is paid software and offering a free trial through the same contact route. The README also flags a health check address under an admin path and advises restricting external access to that path in production, which is a reasonable but manual instruction for something that ships in a public demo. The upstream gates are also present, with the repository, the vendor site, a demo site, and mirrors on GitCode and Gitee.

Editorial conclusion

FizzGate is worth evaluating if your organisation wants a self-hosted gateway covering API integration, masking, tracing and LLM routing in one Java stack, since the feature set in the README is unusually broad and the deployment is a single Compose file. It is a poor fit for a team that needs a permissively licensed gateway, because the node is AGPL-3.0, and a poor fit if you expect a fully functional community edition, since the README states the community build is for testing only and that support comes with the commercial version. Verify first the version pairing between the node and the fizz-manager-professional console, since the node and console ship as matched releases and older than 3.0.0 is no longer maintained.

Frequently asked questions

What is FizzGate and what is fizz-gateway-node?

FizzGate is an API aggregation gateway written in Java, and fizz-gateway-node is its node component. The README describes the node as the data path side, paired with a separate management console, fizz-manager-professional, with the two versions required to match.

How do you install FizzGate?

The one-click path is a wget of install.sh from Gitee followed by running it, and it uses docker-compose with a mirror already configured. The manual path needs Redis v2.8 or above and MySQL v5.7 or above, with Apollo and either Eureka or Nacos optional.

What licence does fizz-gateway-node use?

The repository is licensed under AGPL-3.0, and the README badge for the license states AGPL-3.0. For a gateway that sits in front of internal services, that is a term worth reviewing before deployment.

Which functions does FizzGate provide besides proxying?

Beyond routing and reverse proxying, the README lists service orchestration over HTTP, Dubbo, gRPC and SOAP, API masking, webpage watermarking and leak tracing, sidecar-style threat and sensitive data detection with blocking, multi-level rate limiting by service, interface, APP_ID and IP, circuit breaking, and a separate LLM routing layer with account pools and token billing.

Official sources

  1. fizzgate/fizz-gateway-node on GitHub
  2. License: AGPL-3.0
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/fizzgate-fizz-gateway-node.svg)](https://hysenlabs.com/projects/fizzgate-fizz-gateway-node)

Was this useful?