DreamFactory: self-hosted REST and MCP APIs for existing databases

The gap DreamFactory fills: schema-first APIs over data you already have

Most teams that need an API over an existing database write the same layer again: models, controllers, validation, pagination, auth, docs. DreamFactory's pitch is that this layer is generated. The README describes it as "a secure, self-hosted enterprise data access platform that provides governed API access to any data source," and the intended audience is internal tools, mobile and web backends, legacy modernization, and AI workloads that need to read enterprise data. The AI angle is the newer part: the repository ships an MCP server so ChatGPT, Claude, or a local model can call database tables and stored procedures as tools, with the calls passing through the same role and audit machinery as a human user. If your problem is "our data is in SQL Server and our LLM cannot reach it safely," that framing is aimed directly at you. If your problem is "we need a general-purpose gateway in front of twenty microservices," it is not.

How the generation works: connect, introspect, expose

The mechanism described in the README is introspection, not code generation you commit. You install DreamFactory, connect a database (MySQL, PostgreSQL, SQL Server, MongoDB and others are named), and the platform reads the schema and publishes a REST API with CRUD operations, relationship handling, and stored procedure access. OpenAPI documentation is produced for every endpoint. Filtering, sorting, and pagination are server-side and built into each endpoint, and bulk insert, update, and delete are supported for higher-throughput paths. Everything runs behind a role model: permissions are assignable per table, endpoint, and HTTP verb, API keys can be issued and revoked per application, and audit logging records each call with user, timestamp, and payload. Field-level masking lets a role see a subset of columns. The codebase itself is a Laravel application; the top-level layout shows app/, config/, database/, routes/, and artisan, with a webpack.mix.js build for the admin console assets. That matters for upgrade planning: you are maintaining a PHP application, not a compiled binary.

Installing DreamFactory and calling your first generated endpoint

The README points at four install paths: Linux and Windows installers, Docker via the df-docker repository, and Kubernetes via df-helm. The repository also carries installer.sh and an installers/ directory, plus an .env-dist file that is copied to .env before configuration. A typical source install follows the Laravel convention, so you copy the environment template, install PHP dependencies, and run the bundled installer script.

cp .env-dist .env
composer install
bash installer.sh

After the installer finishes, the admin console is served from the public/ directory by the PHP server entry point in server.php. The README's quick start is the sequence to follow once you are logged in: connect a database, let DreamFactory generate the API, then configure roles and API keys before anything external calls it. For container deployments the README defers to the separate df-docker repository rather than documenting compose files here, so treat that repository as the source of truth for image tags and volumes. What you should see after a successful connect is a service entry for your database and a browsable list of endpoints with generated OpenAPI documentation.

Where DreamFactory is the wrong tool

The generated API is only as good as the schema underneath it. Point DreamFactory at a database with inconsistent naming, no foreign keys, or business rules encoded in application code, and you get a faithful REST surface over a messy model. The README does not describe any schema-migration or data-cleaning capability, so that work stays yours. Second, the platform is an access layer, not an application framework: the README lists server-side scripting in PHP, Python, or Node.js for custom behaviour, but anything beyond request and response transformation belongs in a real service. Third, the README does not document rollback or downgrade steps for a failed upgrade, and it does not state a support window for older releases. Teams that need a documented rollback path should confirm that with the vendor before upgrading in place. Finally, the MCP server is described as using structured API calls rather than raw SQL generation, which is a deliberate constraint: if you want a model to write arbitrary SQL, this is not the product.

DreamFactory compared with a code-first framework

The obvious alternative for a PHP team is writing the API yourself in Laravel, or using a code-first framework such as FastAPI or NestJS in another language. The difference in approach is when the schema binding happens. DreamFactory binds at runtime: you connect a database and the endpoints exist, and changing the schema changes the API surface without a deploy. A code-first framework binds at build time: your models are source files, the API shape is reviewable in a pull request, and you can unit test the handler logic. That build-time binding is why code-first wins when the API is the product, with bespoke validation and business rules. DreamFactory wins when the API is plumbing over many tables and you would rather configure roles than write controllers. The trade-off is real in both directions: DreamFactory gives you speed and a smaller codebase to own, and takes away the ability to diff an API change before it reaches production.

Licence, upgrades, and what maintenance costs

The repository is licensed Apache-2.0, and the README also links to a Commercial Licenses section, which implies a dual model where some deployments or support arrangements fall outside the open source grant. That is a question for your legal team, not something to infer from the licence file alone. On maintenance: the latest release in the repository is 7.7.0, dated 2026-08-18, following 7.6.0 in May and 7.5.0 in April, and the last push to the default branch was on 2026-08-18. That is a regular release cadence. Because DreamFactory is a Laravel application, each upgrade pulls in framework and dependency changes through composer.lock, so plan for a staging environment and a database backup rather than an in-place jump on production. The README does not describe a downgrade procedure, which is the main operational risk to price in.

Security posture: RBAC, identity passthrough, and audit

The access controls are the reason to pick DreamFactory over a quick CRUD scaffold. Permissions are granular per table, endpoint, and HTTP verb; API keys can be rate-limited per application; SSO covers SAML 2.0, OAuth 2.0, OpenID Connect, Azure AD, and LDAP or Active Directory. Audit logging captures user, timestamp, and payload for every call, and data masking restricts which columns a role sees. For AI workloads the same controls apply, which is the point of routing model calls through the MCP server instead of handing a model a database credential. The limitation to note is that the README describes these as features rather than documenting retention, rotation, or export formats for the audit log. If your compliance regime requires a specific log retention period or a SIEM export, verify that against the documentation before you commit.

Editorial conclusion

Adopt DreamFactory when you have databases whose schemas are stable and you need role-scoped REST endpoints plus an MCP server without writing a backend. Do not adopt it as a general API gateway or when you want a code-first framework that lives in your repository. Before rolling it out, verify that your database driver is in the supported list, that the licence covers your deployment model, and that the audit log retention matches what your compliance team requires.

Frequently asked questions

Official sources

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