- What is dreamfactory/df-system used for?
- It is the System Service module of the DreamFactory platform, shipping the service provider, routes, controllers, models, migrations, and config behind the system/* API surface. That surface covers users, roles, apps, services, config, scripts, events, CORS, environment, email templates, upgrade, and sessions. It is the admin plane of the platform, not a general-purpose library you compose into an arbitrary Laravel app.
- Can I install dreamfactory/df-system in a standalone Laravel application?
- No, not realistically. The package binds to df-core service contracts, the DreamFactory service manager, the platform authentication and authorization stack (API keys, JWT, role-based system.* permissions), and a shared database schema. Dropping it into a bespoke Laravel app would require reimplementing those contracts and the auth model, which is a rewrite rather than an integration.
- Which Laravel and PHP versions does df-system support?
- Support is dictated by the DreamFactory core release train rather than by this package independently. The platform's supported matrix defines the PHP 8.x and Laravel versions you can run, and df-system is versioned against a matching df-core release. Check the core release notes for the exact matrix before pinning anything.
- How do I install dreamfactory/df-system with Composer?
- Run composer require dreamfactory/df-system inside an existing DreamFactory host application, then publish the config and run migrations as part of the platform setup. The package is Apache-2.0 licensed, so internal forks and redistribution with attribution are permitted. Installing it outside a DreamFactory runtime will not give you a working system service.
- What API endpoints does the System service expose?
- It provides the system/* routes for users, roles, apps, services, config, scripts, events, CORS, environment, email templates, upgrade, and session management. Access to each is governed by role-based system.* permissions in the DreamFactory auth stack. These are administrative endpoints intended for the dashboard, CLI, and governed platform administration rather than public client traffic.
- Can the system service be disabled or restricted to an internal route group?
- The assessment flags this as something to verify in your own deployment rather than assume. The system service underpins bootstrap flows such as df:setup, the admin dashboard, and CLI operations, so disabling it outright may break platform setup. The practical approach is to keep the routes on an internal network segment or behind strict auth and confirm scoping behavior in a non-production environment first.
- How should I manage df-core and df-system version compatibility?
- Pin df-core and df-system to exact matching versions and treat them as a single unit during upgrades. Version skew typically surfaces as boot-time or service-registration failures rather than graceful degradation, which makes it easy to miss in staging. There is no documented backward-compatibility policy for internal interfaces, so read the source diff before bumping either side.
- What are the security risks of running df-system in production?
- This is the admin plane, so a defect here can mean config exfiltration, privilege escalation through role or app endpoints, or unauthenticated access to system/config. It deserves threat modeling rather than a quick code review, plus network restrictions and audit logging around the administrative routes. Confirm whether the project has a public security disclosure process before you rely on it.
- Does df-system run database migrations during upgrades?
- Yes. The package owns tables for users, roles, apps, services, and config, so upgrades carry schema migrations against the most sensitive data in the platform. Back up the database, rehearse the upgrade in a non-production environment, and review migration diffs before applying them in production.
- Is dreamfactory/df-system actively maintained, and are there alternatives?
- The repository shows roughly 3 stars and 0 dependents, which means effectively no external adoption and no ecosystem pressure to keep internal interfaces stable. Maintainers are a small set and documentation on internal contracts is sparse, so expect to read source; test coverage and CI should be verified yourself. There is no drop-in alternative, because the real choice is adopting the DreamFactory platform or building your own admin API.