Df Git Laravel Package

Product Decisions This Supports

Config-as-code for the API layer. If DreamFactory is the system that turns your databases and services into governed REST APIs, df-git is the piece that lets those API definitions, roles, and platform config live in a Git repository instead of being hand-clicked into an admin UI. That converts the API surface from an opaque runtime artifact into a reviewable, diffable, revertible asset — which is the single biggest unlock here.

Decisions this directly informs:

• Environment promotion model (dev → stage → prod). Do we promote API configuration via branches and merges, or via manual export/import between instances? df-git makes the former viable and is the deciding input for whether we can support more than one or two environments without drift.
• Build vs. buy for config management. The alternative is writing our own export/import synchronization against DreamFactory's platform API, or paying for a higher-tier/licensed capability. Buying here means "adopt a free Apache-2.0 module"; building means indefinite ownership of a bespoke sync tool. This package makes buy the cheaper default if we're already committed to DreamFactory.
• Rollback and incident-response posture. Can we answer "what changed in the API layer at 14:02, and can we revert it in under five minutes?" Git history answers that; nothing else in the DreamFactory admin surface does.
• Compliance and audit narrative. For SOC2/ISO-style controls, "all API and role configuration changes are committed, reviewed, and attributable" is a materially easier story than "an admin changed it in the UI." This affects whether we can sell into regulated buyers.
• Roadmap sequencing for multi-tenant / multi-instance deployments. Git-backed config is a prerequisite for repeatable instance provisioning. If the roadmap includes standing up per-tenant or per-region DreamFactory instances, this evaluation gates that work.
• Governance for LLM-facing APIs. Given DreamFactory's positioning around governed access for enterprise apps and local LLMs, versioned config is what lets you prove which data scopes an LLM-facing endpoint had at any point in time — relevant if AI features are on the roadmap.
• Use cases worth prototyping: seeded/templated instance provisioning, pull-request review of API exposure changes, disaster recovery of platform config, and promotion pipelines in CI.

Honest counterweight: the package has 1 GitHub star, 0 dependents, and a low overall health score. It should be treated as a capability enabler we may fork and own, not as a vendor-supported product we depend on casually. The decision isn't "is this good software" — it's "is this a cheaper starting point than building, given we'll own it either way."

When to Consider This Package

Consider it when:

• DreamFactory is already (or is about to become) a load-bearing part of the architecture. Outside that context this package has essentially no value — it is a platform module, not a general-purpose library.
• You run, or plan to run, more than one DreamFactory instance and are currently managing config by hand. Drift between environments is the pain it removes.
• You need change review, attribution, or rollback on API configuration — regulated industry, customer-facing SLAs, or a platform team that's tired of being the only people who know how prod is configured.
• You already have Git-based workflows (PR review, CI) and want the API layer to participate in them rather than sit outside.
• You have engineering capacity to fork, pin, and maintain a small PHP module, and you're comfortable treating its upstream as a starting point rather than a support contract.
• You're standardizing provisioning/DR and want the platform's own config to be reproducible from a repository.

Look elsewhere when:

• You are not on DreamFactory. There is no partial-adoption path here.
• You need a vendor-backed, SLA-covered configuration management story. Apache-2.0 with one maintainer org and a single star is not that. In that case, go to DreamFactory commercially and ask what's supported in the enterprise tier, or budget to own a fork with an internal maintainer named on paper.
• Your configuration surface is small and stable (one instance, few APIs, infrequent change). The operational overhead of Git-backed config exceeds the risk it mitigates; a documented export cadence is enough.
• You need GitOps across the whole stack, not just the API layer. This solves one slice; don't let it create the impression that platform-wide GitOps is handled.
• The team has no PHP/Laravel fluency and no appetite to acquire it. A forked module in a language nobody owns is a liability, not an asset.
• Release cadence and issue responsiveness don't meet your patching requirements — verify this directly before committing. The listed low adoption signal warrants a hands-on spike, not a docs review.

Adoption gate I'd apply: run a two-week spike — install against a non-production instance, round-trip a realistic config through Git, break something and roll it back, and confirm it survives an upgrade. Proceed only if the spike passes and a named engineer accepts ownership of the fork.

How to Pitch It (Stakeholders)

For executives (one paragraph): DreamFactory is how we expose our data as governed APIs. Today, the configuration of those APIs — what's exposed, to whom, under what rules — lives only inside the running platform. df-git lets us store and manage that configuration in Git, the same way we manage source code. The business outcome is straightforward: faster, safer changes to our API surface, a credible audit trail for compliance and security reviews, the ability to recover from a bad configuration change in minutes instead of hours, and a foundation for standing up new environments without manual rebuilds. It's free and open source (Apache-2.0), so the investment is a small amount of engineering time, not a license. The caveat I'd flag up front: it's a low-adoption module, so we should plan to own a pinned fork rather than rely on upstream support — that's a contained cost, and the alternative is building the same capability ourselves.

For engineering (the practical case): This gives us branch-based promotion of DreamFactory config, PR review on API and role changes, full history and one-command rollback, and a path to automated instance provisioning and DR. It fits our existing Git/CI workflow instead of introducing a new one. The trade-offs are real and should be stated plainly: one star, zero dependents, a single maintainer organization, and a low overall health score — so we treat upstream as a reference implementation. Plan is to pin a version, fork it into our org, add a smoke test around config round-tripping, and name an owner. If the spike shows the module is too coupled to a specific DreamFactory version or the code is unsound, we fall back to a thin export/import service against the platform API — but we'd rather not build that from scratch if we don't have to.