- What is fb-copydb used for in a Laravel application?
- fb-copydb is an operational utility that duplicates a database, copying schema and data so you can refresh staging, seed a test environment, take a backup, or move data during a migration. It runs as Laravel artisan console commands rather than as application runtime code, so it sits outside the request/response path. It is a one-shot copy tool, not a continuous sync or replication engine, so do not expect bidirectional consistency between environments.
- How do I install fb-copydb in a Laravel project?
- Install it with Composer using composer require mortezamasumi/fb-copydb. The package is auto-discovered, so its service provider and console commands register without any application code changes. After installing, publish the package config with php artisan vendor:publish and then supply your source and target connection details.
- Which Laravel and PHP versions does fb-copydb support?
- Laravel 13 support was added in v5.2.0, and earlier releases target the Laravel 10 and 11 era on PHP 8.x. Because the framework constraint was widened in that release, confirm the exact illuminate/support and PHP floor values in the package composer.json before adoption. Also verify that any underlying database or Google SDK constraint in the dependency tree is actually installable alongside your pinned Laravel version.
- How do I configure fb-copydb source and target connections and credentials?
- Configuration lives in the published config file, which holds the source and target project or database credentials plus the copy parameters. Prefer environment variables over committed values, and never commit service account JSON keys or passwords into the repository. Restrict the credentials by role so the source identity is read-only and the target identity can only write to the intended destination.
- Does fb-copydb support a dry-run mode or selective copying?
- The available documentation does not describe dry-run, idempotency, or per-collection and per-document scoping controls, so treat these as unverified. Run a spike against a disposable target environment first and confirm what filtering options the command signatures actually expose. If you need partial copies in production workflows, plan to wrap or extend the command yourself.
- What happens if a database copy fails halfway through?
- Partial-failure behaviour (silent skip, hard abort, or partially written target needing manual reconciliation) is not documented in the release notes available for review. Because a half-completed copy leaves the destination in an inconsistent state, always snapshot or back up the target before executing, and test the failure path deliberately in staging. Only then decide whether the tool is safe enough for a given environment.
- Is fb-copydb safe to run against a production database?
- Any copy tool that writes to a live datastore carries destructive-operation risk, and this package does not document guardrails such as dry-run, idempotency, or scoped filtering. An operator error, such as pointing the target at production instead of staging, can overwrite real data. Mitigate with least-privilege credentials, a pre-run backup, and by running the tool only from an ops workflow with review.
- Should fb-copydb be a production dependency or a dev dependency?
- Treat it as require-dev or ops-tooling rather than a runtime dependency, and keep it out of the deployable artifact where possible. It adds nothing to a request-handling application and only needs to exist on the machine or CI runner performing the copy. That also reduces exposure if the package goes unmaintained.
- How do I upgrade fb-copydb from v5.1.5 to v5.2.0?
- v5.2.0 is a minor release containing one feature commit that adds Laravel 13 support, with no removals, renames, or announced deprecations. In practice the upgrade is a composer update with no code changes expected. The one thing to check is whether the widened framework constraint also raised the PHP floor or bumped a major version of an underlying SDK.
- What alternatives exist and how risky is the maintenance of fb-copydb?
- The dominant risk is continuity: this is a single-maintainer package with a narrow audience, and the evidence base is a release note rather than an issue-tracker history. Alternatives include native engine tooling such as physical/logical backup utilities for your database, managed cloud export and import jobs, or a small in-house artisan command written against your own connection config. Whichever you choose, run a spike first and avoid coupling critical runbooks to a package you cannot fork or maintain.