Fusio: self-hosted API management in PHP, with MCP for AI agents

What Fusio solves, and who ends up running it

Most teams that expose internal data end up writing the same three things by hand: a routing layer that maps HTTP methods and paths to code, an authentication and quota layer, and a portal where other developers can read docs and pick up a key. Fusio bundles those into one PHP application. The README describes it as a self-hosted backend platform and API gateway that "bridges the gap between your internal infrastructure and the outside world", with database exposure, microservice routing and custom logic as the three entry points.

The audience is narrower than the feature list suggests. Because the runtime is PHP and the configuration is a database row rather than a YAML file, the person who benefits most is a PHP shop that already operates MySQL or PostgreSQL and wants an API product on top of existing tables without standing up a separate gateway written in Go or Java. The README also positions the project for AI work: actions can be used as tools for autonomous agents, and MCP integration is listed as a first-class feature. That matters if you want the same endpoint to serve a human-facing SDK and an agent runtime.

It is not a framework you embed. The repository ships a complete application with its own backend, so adopting Fusio means adopting an application you deploy and upgrade, not a library you call from an existing one.

Actions, operations and the request path through the gateway

The core abstraction is the Action. The README gives a minimal example: a PHP class implementing Engine\ActionInterface whose handle method receives a request, a configuration object and a context, and returns a value that becomes the response. An action on its own does nothing. It becomes reachable when it is bound to an Operation, which the README describes as the pairing of an HTTP method and path with an action. That binding is what turns a class into an endpoint.

Configuration is the second half of the design. By extending Engine\ActionAbstract instead of implementing the interface directly, an action can declare a configure method that adds form elements, in the documented example a text input named message. The backend renders those declarations as a generated form, so a non-developer can change the returned value without touching the class. This is the most interesting decision in the project: the action is both the logic and the schema for its own settings, which is what makes the same action reusable across several operations with different parameters.

Around that core sit the gateway concerns. Database API Gateway and Microservice Gateway are listed as separate capabilities, which implies routing and load balancing are handled at the Fusio layer rather than in your own code. Analytics and monitoring are described as real-time tracking of usage, performance and errors. The README does not document the internal routing implementation or how the gateway stores its configuration, so treat the request lifecycle beyond the action boundary as something to read up on in the linked documentation rather than infer from the feature list.

Installing Fusio with Docker and reaching the backend

The README calls Docker with docker-compose the fastest way to try Fusio locally. The compose file below is reproduced from the README; it defines the Fusio container and a MySQL 8.0 container, and passes the database credentials through FUSIO_CONNECTION. Note the project key and backend credentials, which you should replace before exposing anything.

services:
  fusio:
    image: fusio/fusio
    restart: always
    environment:
      FUSIO_PROJECT_KEY: "42eec18ffdbffc9fda6110dcc705d6ce"
      FUSIO_CONNECTION: "pdo-mysql://fusio:61ad6c605975@mysql-fusio/fusio"
      FUSIO_BACKEND_USER: "test"
      FUSIO_BACKEND_EMAIL: "[email protected]"
      FUSIO_BACKEND_PW: "test1234"
    ports:
      - "8080:80"

Start it with the command the README gives:

docker compose up -d

After startup the README says the backend is available at http://localhost:8080/apps/fusio, and you log in with the credentials you configured in the compose file. From there the README points at the Getting Started guide to build a first action and wire it to an operation.

Manual installation is the alternative when you want the application on your own web server. The README says to download a release or clone the repository, then set APP_CONNECTION in .env. Three DSN schemes are documented: pdo-mysql, pdo-pgsql and pdo-sqlite. APP_URL is described as recommended and required when Fusio lives in a sub-folder, because otherwise the application tries to detect the domain from the Host header.

APP_CONNECTION=pdo-mysql://root:password@localhost/fusio
APP_URL=http://localhost:8080

Then run the migrations, create the administrator account, and install the backend app:

php bin/fusio migrate
php bin/fusio adduser
php bin/fusio marketplace:install fusio

The README says to choose Administrator as the account type during adduser. For a quick look you can serve the public folder with the PHP built-in server, which the README explicitly marks as testing-only:

php -S 127.0.0.1:8080 -t public

For production the README directs you to a classical Nginx or Apache setup or to Docker. There is also a web installer at /install.php, and the README recommends deleting that script once installation completes.

Where Fusio stops being the right tool

The manual install path has more steps than the feature list implies, and each one can fail independently. Migrations run before the administrator exists, the backend app is installed from the marketplace as a separate step, and the development server is explicitly not for production. If you skip the APP_URL configuration while hosting under a sub-folder, the README states that Fusio falls back to detecting the domain from the Host header, which is a behaviour you do not want behind a proxy that rewrites headers.

The bigger constraint is the deployment model. Fusio is a full application with a backend UI, a database schema and a marketplace, so upgrading means running migrations and keeping the backend app in step with the core. The repository carries an UPGRADE.md file at the top level, which tells you the maintainers treat version transitions as a documented procedure rather than a drop-in replacement. Teams that cannot schedule database migrations against a production API gateway should look elsewhere.

Finally, the action model is PHP or Javascript classes. If your team has no PHP runtime and no appetite for one, the custom logic path is closed, and you are left with the database and microservice gateway features only. The README does not present a plugin system for other languages, so do not assume one. And if you need a hosted control plane with a vendor handling availability, a self-hosted application is the wrong shape regardless of features.

How Fusio differs from Kong and Tyk

The closest alternatives in the API gateway space are Kong and Tyk, and the difference is where the business logic lives. Kong and Tyk are written in Lua and Go respectively and are typically deployed as a proxy in front of services that already exist; you configure routes, plugins and policies, and the upstream service does the work. Fusio is a PHP application that expects to host the logic itself, as an action bound to an operation. The README's own framing supports this: it lists Custom API Logic as a feature alongside the gateway features rather than as an external concern.

That changes the operational picture. With a proxy-style gateway you keep your application and add a hop. With Fusio you may be replacing part of the application, which is why the developer portal, SDK generation and monetization features make sense here and less so in a pure proxy. Fusio also carries MCP integration natively, which the README presents as a bridge to the AI ecosystem; if exposing the same actions to agents is on your roadmap, that is a capability a generic proxy would require extra work to match.

The trade-off is ecosystem maturity. Kong and Tyk have plugin marketplaces and years of third-party integrations; Fusio's extension surface, as far as the README shows, is actions and a marketplace command for installing apps. If your requirement is a broad set of off-the-shelf policies, the proxy model wins. If your requirement is owning the whole API product in one PHP deployment, Fusio is the more direct fit.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-06. The most recent release listed is v7.1.1 on 2026-08-16, following v7.1.0 in July 2026 and v7.0.0 in May 2026. That is a steady release cadence across the last few months, and the presence of a CHANGELOG.md and an UPGRADE.md at the top level means version transitions are documented rather than left to the reader.

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It does not impose copyleft obligations on your own code, so bundling Fusio into a commercial API product is not blocked by the licence itself. This is a summary of what the licence identifier means, not legal advice; if you are redistributing a modified Fusio, read the LICENSE file in the repository and get your own counsel.

The practical upgrade cost comes from the database. Fusio stores its configuration in the database you point APP_CONNECTION at, and the documented install path runs php bin/fusio migrate. Any major version bump therefore implies a migration against your production schema. The marketplace:install step for the backend app adds a second moving part: the backend UI is installed as an app, so it can lag the core if you upgrade one without the other. Budget for a staging environment that mirrors the production database before you move a major version.

Editorial conclusion

Adopt Fusio if you run PHP infrastructure and want the gateway, developer portal, SDK generation and MCP endpoint in one self-hosted deployment, and you are willing to own the database, the web server and the upgrade path. Do not adopt it if you need a managed control plane, if your stack has no PHP runtime, or if you expect the gateway to be configured entirely from a UI without writing an action class. Verify first that your target database is one of the three documented DSN schemes, that APP_URL is set when Fusio sits in a sub-folder, and that the install.php script is deleted after the web installer finishes.

Frequently asked questions

Official sources

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