DreamFactory: A Self-Hosted API Gateway That Turns Database Schemas Into Governed REST Endpoints
DreamFactory is a secure, self-hosted enterprise data access platform that provides governed API access to any data source, connecting enterprise applications and on-prem LLMs with role-based access and identity passthrough.
At a glance
- What is it?
- DreamFactory is an Apache-2.0, Laravel-based platform that introspects a database and generates CRUD REST endpoints with OpenAPI docs, RBAC and an MCP server for LLM access. The useful question is not whether generation works, but whether a schema-driven gateway beats the ORM code you would otherwise write.
- Who is it for?
- Adopt DreamFactory when the data sources are already fixed and you need one governed HTTP surface over many of them, with role and key management that you would otherwise build yourself. Skip it when your API contract is the product: hand-written endpoints with bespoke semantics will fight the generator.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem DreamFactory Targets: Schema Drift Between Databases and HTTP
Most internal tools start the same way. A database exists. An application needs to read and write it over HTTP. Someone writes controllers, serializers, validation, pagination, filtering, and an OpenAPI file that is accurate for about two weeks. DreamFactory's answer is to skip that layer: it connects to the database, introspects the schema, and generates the REST API from what it finds. The README states that this covers full CRUD operations, relationship handling, stored procedure access, and OpenAPI/Swagger documentation, and that it happens in minutes. The audience is narrow and identifiable. Teams with an existing SQL Server, Oracle, MySQL, PostgreSQL or MongoDB instance who need an API surface without owning a backend framework. Teams modernizing legacy databases, where the README names stored procedures and mainframe data as targets. And teams wiring on-prem LLMs to internal data, where the selling point is that the model calls structured endpoints rather than writing raw SQL. If your data model is still moving weekly, generation from a schema is a liability, not a feature.
How the Generation Actually Works: Introspection, Not Code Generation
The mechanism described in the README is runtime introspection rather than a one-time scaffold. You connect a database as a service inside DreamFactory, and the platform reads the schema and exposes endpoints derived from it. That distinction matters for maintenance. There is no generated source tree to check into Git and no drift between the checked-in code and the live schema, because the schema is the source. The trade-off is equally clear: the API changes when the table changes, and any hand edits you want in the response shape have to live in the platform's own extension points rather than in application code. Those extension points are server-side scripts in PHP, Python or Node.js, attached as pre-process and post-process events on an endpoint, plus custom service registration. Related data retrieval is handled at the gateway, so a parent and its children can come back in one call instead of a client-side join. Filtering, sorting and pagination are server-side and built into every generated endpoint, and bulk insert, update and delete are listed for high-throughput paths. The README also describes deterministic database queries for the AI path: the model selects a tool, and the gateway executes a structured call rather than accepting generated SQL. That is the design decision worth noting, because it moves the correctness problem from prompt engineering to tool definition.
Getting an Instance Running: Installers, Docker, and Helm
The README points at four installation routes and does not print a single install command in the extracted text, so treat the buttons as the entry points rather than a script. Linux and Windows have installers under the installers directory in the repository. Docker is handled by the separate dreamfactorysoftware/df-docker repository, and Kubernetes by dreamfactorysoftware/df-helm. The getting started guide lives at guide.dreamfactory.com and the reference documentation at docs.dreamfactory.com. The repository's primary language is Shell, which is consistent with an installer-and-container distribution model rather than a library you pull into an existing PHP project. Configuration happens after install, in the web admin console: connect a data source, then define roles, API keys and access controls. The README's quick start lists exactly that sequence, and it is the sequence to follow on a throwaway instance before pointing it at anything real. What the supplied material does not give is the required PHP version, the database DreamFactory uses for its own metadata, or the environment variables the container expects. Those live in the linked documentation, and they are the first thing to read before you size a host.
Where the Access Control Model Sits, and What It Costs You
DreamFactory places authorization at the gateway rather than in each consuming application. Roles carry granular permissions per table, per endpoint and per HTTP verb, and field-level security plus data masking control which columns a role can see. API keys are issued, revoked and rate-limited per application, and requests can be throttled per user, role or service. Audit logging records every API call with user, timestamp and payload. Identity can come from SAML 2.0, OAuth 2.0, OpenID Connect, Azure AD, or LDAP and Active Directory, and the README's phrase for the overall posture is role-based access with identity passthrough. This is the part that is genuinely hard to replicate with a hand-rolled CRUD layer, and it is the reason a gateway can be worth the extra hop. The cost is that your permission model now lives in DreamFactory's configuration, not in your repository. Role definitions, field masks and key policies are operational state. If they are not exported and version-controlled somewhere, they are the kind of configuration that drifts between staging and production and is discovered only during an incident. The README does not describe a configuration export path, so verify that before you build a workflow on top of it.
The MCP Server Is the Newest Bet, and the Least Proven
The feature that distinguishes the current release line from a conventional API gateway is the built-in MCP server. It exposes database tables and stored procedures as MCP tools so that ChatGPT, Claude or a local model can query enterprise data through the same RBAC and audit logging as any other client. The claim in the README is deterministic database queries: the AI uses structured API calls instead of generating SQL. That is a defensible position. It means the model's blast radius is bounded by the tool definitions and the role attached to the credential, not by how well a prompt resists injection. It also means the quality of the integration depends on how you shape the tools, and the README does not describe tool granularity, result size limits, or what happens when a tool returns a large result set to a model with a small context window. Those are the questions to answer in a pilot. A second limitation is structural: MCP tooling moves quickly, and a gateway that ships its own MCP server inherits the cost of tracking that specification. The release cadence visible here (7.5.0 in April, 7.6.0 in May, 7.7.0 in August 2026) suggests active maintenance, but it also means the MCP surface is a moving target.
When a Schema-Driven Gateway Is the Wrong Tool
The failure mode is easiest to state plainly. If your API is a product with its own contract, semantics and versioning guarantees, generating endpoints from tables inverts the dependency you want. Your consumers would be coupled to column names, and a rename in the database becomes a breaking API change. DreamFactory's own extension path, pre-process and post-process scripts, can paper over the difference, but at that point you are writing and maintaining the translation layer anyway, just in a scripting runtime attached to a gateway instead of in an application. Two other cases deserve caution. First, high-frequency transactional workloads where an extra network hop and a generic query builder sit between the client and the database: the README lists bulk operations, but it does not publish latency figures, and none should be assumed. Second, regulated environments that require the data path to be auditable at the code level. A generated endpoint is harder to review line by line than a controller you wrote. The README's audit logging addresses observability of calls, not reviewability of the query logic itself.
PostgREST and Hasura as the Comparison Points
The closest alternatives are PostgREST and Hasura, and the difference is scope rather than quality. PostgREST reflects a single PostgreSQL schema directly into a REST API and does essentially nothing else: no admin console, no multi-database connector list, no MCP server, no role editor. If you are on PostgreSQL only and want the thinnest possible layer, PostgREST is a smaller thing to operate and to reason about. Hasura takes the opposite approach to the AI question: it exposes GraphQL over multiple databases with a permission model expressed as declarative metadata, and its ecosystem leans on GraphQL clients rather than REST plus OpenAPI. DreamFactory sits between them and widens further: SQL and NoSQL sources, stored procedures, file storage services, SSO through SAML and LDAP, and an MCP server aimed at LLM clients. The practical decision rule is the number of heterogeneous sources you have to unify. One PostgreSQL database favors PostgREST. A GraphQL-first frontend favors Hasura. Several databases plus an identity provider plus an AI access requirement is the shape DreamFactory is built for, and it is also the shape where you are buying a platform rather than a library.
Licence, Release Cadence, and What to Verify Before You Commit
The repository is Apache-2.0, which permits commercial use and modification of the core, and the README also has a section on commercial licences. The two coexist, so the boundary between what the Apache-2.0 grant covers and what requires a commercial licence is a question for your own legal review, not something to infer from the repository description. On maintenance: releases 7.5.0, 7.6.0 and 7.7.0 landed in April, May and August 2026, and the last push to master was 2026-08-18, the same day as 7.7.0. That is a steady cadence with no long gap, which is the useful signal here. Upgrading a self-hosted gateway is not a library bump: it touches the service, the admin console, the stored role and key configuration, and any server-side scripts you attached to endpoints. Budget for a staging upgrade and a script-compatibility pass on each minor version rather than treating it as routine. Before adopting, confirm three things against the linked documentation: the connector list for your exact database and version, the SSO path for your identity provider, and whether role and field-mask configuration can be exported and diffed. If that third item has no answer, plan for the configuration to be managed by hand.
Editorial conclusion
Adopt DreamFactory when the data sources are already fixed and you need one governed HTTP surface over many of them, with role and key management that you would otherwise build yourself. Skip it when your API contract is the product: hand-written endpoints with bespoke semantics will fight the generator. Before committing, verify three things in a staging instance: that the connector for your specific database and version is listed in the supported data sources, that your SSO provider works through the documented SAML 2.0 or OpenID Connect path, and that the role matrix can express your field-level restrictions. The Apache-2.0 core is the part you can read and modify; the commercial licences in the same repository are the part you cannot assume is free.
Community notes