Labby Bundle Laravel Package

Getting Started

Before you write any code, understand what you're actually installing: LabbyBundle is a Symfony bundle, not a Laravel package. It has no service provider, no facade, no config/labby.php. Its last release was June 2016, it has 3 stars and zero dependents, so it was almost certainly never used in a production Laravel app. Plan accordingly — you are not "adding a package," you are either (a) reading it for ideas, or (b) standing up a small parallel Symfony console app next to your Laravel project.

Minimal steps to evaluate it:

1. Read the README first — it is the only real documentation. Look for the bundle's console commands (they are namespaced under labby:), the config.yml example, and the source/target "stage" configuration block. That config shape tells you more about the package's mental model than the code does.
2. Inspect composer.json in the repo. Note the symfony/* version constraints and the PHP floor (typically PHP 5.5–7.0 era). If your Laravel app is on PHP 8.1+, treat the package as non-installable in-app.
3. Decide whether you want the behavior (pull a database and public assets from one environment into another) or the code. For a Laravel developer, you almost always want the behavior.

First realistic use case: "pull the latest staging database and uploads into my local environment with one command." That is the entire value proposition. In a modern Laravel app you should reproduce it with a custom Artisan command rather than adopting this bundle — Process::run('mysqldump ...'), mysqldump | mysql, and rsync -av --delete cover 90% of what LabbyBundle does, and they will not fight your framework.

If you must run the original, isolate it in a throwaway Symfony 3.x skeleton on the same host (or in a Docker sidecar), point its config at the same MySQL/Redis/S3 endpoints as your Laravel app, and invoke it as an external binary from a Laravel command. Do not attempt to register it inside config/app.php.

Implementation Patterns

The pattern LabbyBundle popularized — and the only thing worth copying — is stage-to-stage sync driven by named environment configs:

• Define named stages (production, staging, local) each with their own database DSN and asset root.
• A single command (labby:db, labby:assets, or a combined run) pulls from the configured source stage into the current one. Direction is config-driven, not argument-driven, which reduces the chance of fat-fingering a destructive command.
• Database and assets are separate operations, so a failed rsync doesn't invalidate a good dump.

Translated into idiomatic Laravel, that becomes:

• php artisan db:pull --from=staging as a thin command in app/Console/Commands, wrapping Process calls to mysqldump and mysql (or pg_dump/psql). Guard it with $this->confirm() and an if (app()->isProduction()) abort(403) check.
• php artisan assets:pull --from=staging wrapping rsync or aws s3 sync for storage/app/public and public/uploads. Always pass --exclude rules for node_modules, .git, and cache directories.
• A single sync:pull meta-command that calls both via $this->call().

Integration tips if you're borrowing the concept:

• Config over flags. Put source hostnames and credentials in .env (STAGING_DB_HOST, etc.) and reference them — never in a committed YAML file, which is a trap the original Symfony bundle encourages.
• Post-pull hooks. After importing, run php artisan migrate (only if the dump is schema-only), php artisan cache:clear, php artisan storage:link, and any search index rebuild. Chain these in the same command so a pull is always atomic from the developer's point of view.
• CI usage. The same wrapper command is useful in CI to seed an ephemeral database from a scrubbed staging dump. Pair it with --no-interaction and a separate "seed" entry point that skips confirmation.
• If you genuinely need the Symfony bundle's behavior in a Symfony service, register it as a real bundle in app/AppKernel.php and let it consume parameters.yml. That is its only supported mode.

Gotchas and Tips

• It is abandoned. Last release 2016, 3 stars, 0 dependents. There is no security response, no PHP 8 support, and no compatibility work with Symfony 5/6/7 or Laravel 9+. Treat any adoption as a fork.
• No Laravel integration exists and none ever will. No service provider, no facade, no config publish tag. composer require velikonja/labby-bundle in a Laravel project will either fail on constraints or install a bundle that does nothing until you build a Symfony kernel — don't.
• The destructive direction is the real risk. A stage-to-stage DB pull is one typo away from overwriting production. If you port the pattern, hard-code a refusal to run when APP_ENV=production unless an explicit --force-prod flag is passed, and always confirm() interactively.
• Config quirks originate in Symfony's config.yml inheritance. config_dev.yml overrides config.yml, which is how people accidentally point "local" at a production DSN. In Laravel use .env + config/ and php artisan config:clear religiously — do not emulate the YAML layering.
• Character set and collation. Old dump tooling defaults to utf8 (not utf8mb4), which silently corrupts emoji and 4-byte characters on import. Always pass --default-character-set=utf8mb4 to mysqldump/mysql in any replacement you write; the 2016-era bundle doesn't.
• Asset sync exclusions. rsync --delete without excludes will wipe your local built assets. Build the exclude list defensively (node_modules/, .git/, storage/framework/, bootstrap/cache/, vendor/) before trusting it.
• Debugging the original: run its commands with -vvv to see the underlying exec/Process calls. Most failures are permissions on the dump directory, missing SSH keys for the remote rsync, or a DSN mismatch, not bundle logic.
• Extension points are Symfony DI service overrides — you'd redeclare a driver service in your own services.yml. Worth knowing only if you fork; it does not map to Laravel's container in any meaningful way.
• Better alternatives for Laravel specifically: spatie/laravel-db-sync, spatie/laravel-backup (restore side), dusterio/laravel-remote for artisan over SSH, and plain mysqldump/rsync scripts wrapped in Artisan commands. Any of these is a safer day-to-day tool than resurrecting a 9-year-old Symfony bundle.