Fusio: a PHP API gateway that also exposes your endpoints to AI agents

The gap Fusio fills between internal services and a published API

Most teams do not start with an API product. They start with a database, a few internal services, and a growing set of consumers who each want a slightly different slice of the same data. The README frames the problem directly: Fusio "bridges the gap between your internal infrastructure and the outside world," whether that means exposing legacy SQL or NoSQL databases, orchestrating microservices, or writing custom logic. The target reader is a builder, not a platform team. If you already run a service mesh with a separate developer portal, an SDK pipeline and a billing system, Fusio overlaps with all of them and duplicates work. If you have none of those and one PHP codebase, it replaces the assembly job.

The scope claim is broad. The feature list covers a database gateway, a microservice gateway, custom logic in PHP or JavaScript, an MCP server, a developer portal, SDK generation, subscriptions with quotas and automated billing, and usage analytics. That is the shape of a commercial API management suite compressed into one self-hosted application. The honest question for an adopter is whether a single PHP project can carry all of those responsibilities at the quality level you need, and the answer will differ per feature.

Actions and Operations: the two objects that define everything

The mechanism is small enough to describe in full. You write an Action, which the README defines as a PHP class implementing Engine\ActionInterface with a single handle method. That method receives a request, a configuration object and a context, and returns a value. In the minimal example it returns an array with a hello key. You then bind the Action to an Operation, which fixes the HTTP method and path that triggers it. Routing, request parsing and response serialization sit outside your code.

Configuration is the second half of the design. By extending Engine\ActionAbstract instead of implementing the interface directly, an Action gains a configure method that adds form elements. The README example adds an input named message, and the backend then renders a generated form so a non-developer can change the returned value without touching code. This is the part of Fusio that is genuinely different from writing a plain controller. The same Action can be reused across Operations with different configuration, which is why the README calls the concept "highly reusable for both developers and non-technical users." The cost is that your business logic now depends on Fusio's engine interfaces, and the configuration surface lives in the database rather than in version control unless you export it.

MCP support sits on top of this. The README states that custom API logic can be used as Tools for autonomous agents, and that Fusio has "native support for the Model Context Protocol to expose APIs to AI ecosystems." The material does not describe the MCP transport, tool naming or authentication model, so treat the integration as a documented capability rather than a specified one until you read the MCP section of the docs.

Getting a Fusio instance running: Docker first, migrations second

The fastest path in the README is a docker-compose file with two services. The fusio service uses the fusio/fusio image, maps port 8080 to 80, and reads four environment variables: FUSIO_PROJECT_KEY, FUSIO_CONNECTION, FUSIO_BACKEND_USER, FUSIO_BACKEND_EMAIL and FUSIO_BACKEND_PW. The connection string in the example is pdo-mysql://fusio:61ad6c605975@mysql-fusio/fusio, pointing at a second service running mysql:8.0 with a named volume at ./db. Start it with docker compose up -d, then reach the backend at http://localhost:8080/apps/fusio and log in with the credentials you set.

The manual path is five commands and one config file. Clone the repository, then set APP_CONNECTION in .env. The README lists three supported forms: pdo-mysql://user:pass@host/db, pdo-pgsql://user:pass@host/db, and pdo-sqlite:///fusio.sqlite. It recommends also setting APP_URL, and this is not cosmetic. Without it, Fusio tries to detect the domain from the Host header, which breaks when the application lives in a subfolder such as https://my_domain.com/fusio. After configuration, run php bin/fusio migrate, then php bin/fusio adduser and choose Administrator as the account type, then php bin/fusio marketplace:install fusio to install the backend app. For local testing only, php -S 127.0.0.1:8080 -t public serves the public directory.

The README is explicit that the built-in server is not a production option and that you need Nginx, Apache or Docker instead. There is also a web installer at /install.php, with the recommendation to delete that script after installation. That last point matters: an install script left reachable on a public host is an obvious problem, and the README treats its removal as a recommendation rather than something the installer does for you.

The PHP dependency is the real adoption constraint

Actions are PHP classes. The README also mentions JavaScript as a language for custom logic, but every code example it gives is PHP, and the runtime is a PHP application. This shapes who can use Fusio. A team whose services are Go, Java or Node can still put Fusio in front of them and route traffic through the microservice gateway, but every piece of custom logic in the request path has to be written in PHP, and the operational burden of running a PHP application plus MySQL or PostgreSQL lands on whoever owns the deployment.

The database gateway has a similar shape. Exposing a legacy SQL database as a REST API is a real capability, but it moves the API contract into Fusio's configuration. The README does not describe how schema changes in the underlying database propagate to the generated endpoints, and that is the question to answer before pointing it at a database that other teams still migrate. If the upstream schema moves and the Fusio side does not, you get runtime failures rather than a compile-time error.

There is a second, quieter limitation. The README presents a long feature list with no indication of which features are mature and which are recent. Version 7.0.0 landed in May 2026, with 7.1.0 and 7.1.1 following in July and August. A major version bump followed by two minor releases in three months suggests active development, and it also suggests that anything you build should be pinned to a specific version rather than tracking master. The repository does not publish upgrade notes in the material available here, so the cost of moving between major versions is unknown from the README alone.

Fusio against Kong or Tyk: code layer versus configuration layer

The closest comparison is a general-purpose API gateway such as Kong or Tyk. Those tools are primarily proxies. You declare routes, plugins and upstreams in configuration, and the gateway forwards requests to services you already run. Custom behaviour arrives through plugins written against the gateway's own extension model, often in Lua or Go. Fusio inverts the emphasis. The Action is the unit of work, and the gateway is where that work executes. Routing exists to bind an Action to a path, not to forward to an upstream that owns the logic.

That difference decides the choice. If you have a polyglot backend and you want a thin, fast layer for authentication, rate limiting and routing, a proxy-first gateway is the better fit, because it does not ask you to reimplement anything in PHP. If your logic already lives in PHP, or you are willing to write it there, Fusio gives you the portal, the SDK generation and the subscription and quota handling in the same deployment, which a plain proxy does not. The README's own phrasing, "turn your business logic into scalable API products," is accurate about the direction of the tool: it is a product layer that happens to include gateway functions, not a gateway that happens to include a portal.

One more distinction is worth naming. Fusio is self-hosted and Apache-2.0. That licence permits commercial use and modification, and it does not require you to publish changes you make to the software itself. It does not settle what happens to the API definitions, configuration and generated SDKs you produce, because those are your content rather than the licensed work. If you plan to redistribute generated SDKs or embed Fusio in a product you sell, read the licence text and the NOTICE file yourself rather than relying on a summary.

Maintenance cost and what to check before you commit

The upgrade surface is the application plus its database schema plus the installed marketplace apps. The README shows marketplace:install fusio as a required installation step, which means the backend you administer is itself a marketplace package and can be updated independently of the core. That is convenient and it also means an upgrade has more moving parts than a single composer update. The material does not describe a rollback path, a version compatibility matrix between core and marketplace packages, or a supported upgrade procedure between major versions. Run migrations against a copy of the production database first.

Operationally, the pieces you own are the PHP runtime, the database, and a web server. The README points at Nginx, Apache or Docker for production and rules out the built-in server. If you use the Docker image, the database service in the example uses a named volume, so backups are your responsibility. If you use SQLite, the pdo-sqlite:///fusio.sqlite form keeps everything in one file, which is simple to back up and a poor fit for concurrent write load.

Before adopting, verify the specific integrations you actually need rather than the feature list as a whole. Install the backend with php bin/fusio marketplace:install fusio against a database copy, create an Action with a configure method and confirm the generated form appears in the backend, then test one MCP tool end to end, since the README asserts native MCP support without describing how tools are named or authenticated. If those three checks pass on your infrastructure, the remaining risk is upgrade cost, and that is a question only the project's release notes can answer.

Editorial conclusion

Adopt Fusio if you have PHP developers, an existing MySQL, PostgreSQL or SQLite database, and you need a developer portal, SDK generation and quota handling in one deployable unit rather than three. Do not adopt it if your services are not PHP and you have no appetite for running a PHP application plus a database in production, or if you need a gateway that terminates traffic for polyglot backends without a code layer. Before committing, verify three things: that the marketplace:install fusio step completes against your database, that APP_URL is set correctly if you host under a subfolder, and that your intended production setup is Nginx or Apache rather than the built-in PHP development server.

Official sources

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