Clonio Cli Laravel Package

Product Decisions This Supports

• Non-prod data strategy (clone-and-mask vs synthetic fixtures). Clonio's core job is refreshing staging/QA/preview environments from a source database with masking applied — a decision about where realistic test data comes from and how much engineering time that costs per refresh.
• Build vs buy for data masking. The realistic alternatives are hand-rolled mysqldump + sed/SQL-update scripts, a bespoke artisan command, or a commercial masking suite. Clonio sits in the "cheap, self-hosted, CLI-native" slot; the trade-off is no vendor, no SLA, single maintainer.
• Schema-drift policy. New recreate_tables option forces an explicit decision: are downstream targets disposable-by-design (rebuild drifted tables automatically) or stateful and owned by someone else? That is an ops/governance call, not a config detail.
• Per-environment data scope. The exclude column strategy, generated-column skipping, and schema row strategy (structure-only tables) reduce bespoke config for reference/lookup tables and computed columns — fewer "why is this table empty / why did the clone fail on a generated column" tickets as the schema evolves.
• Compliance posture. If you sell into regulated or EU markets, a repeatable, scripted masking pipeline is a control you can point at during security review, and it constrains what production data is allowed to leave prod.
• Tooling distribution / DevEx roadmap. Shipping as static binary, PHAR, Docker image, and Composer dev dependency means adoption can be mandated in CI without a PHP toolchain in every image — a factor in whether standardizing on this is feasible across teams.

When to Consider This Package

Consider it when:

• You run a Laravel/PHP application on a relational database and regularly need production-shaped data in staging, preview, or QA.
• You have columns that must be masked or dropped (PII, tokens, generated columns) and are currently doing this with ad-hoc scripts.
• Your schema changes often enough that per-column/per-table config churn is the main cost — the v1.3.0 strategies (skip generated columns, exclude columns, schema-only rows) directly target that.
• You can install it as a dev dependency or run it purely as a Docker image, and are comfortable with a CLI-first workflow.

Look elsewhere when:

• PHP 8.5 is not on your roadmap. The PHAR explicitly requires 8.5, and the Composer dev-dependency path is likely pinned the same way — teams on 8.3/8.4 may be blocked. Verify the constraint before committing.
• You need vendor support, an SLA, or certified masking/audit guarantees — this is a single-maintainer OSS project.
• You're not on Laravel/PHP, or you need continuous/CDC replication rather than periodic clones.
• macOS is a primary developer platform: the binary is unsigned and un-notarized, so every developer hits a Gatekeeper workaround on first run. That's a distribution problem, not a bug, and it will generate support noise.
• You can't put guardrails around destructive operations — recreate_tables rebuilds target tables and needs to be off (or tightly scoped) anywhere the target isn't disposable.

How to Pitch It (Stakeholders)

Executives: A small, self-hosted CLI that refreshes staging and QA with realistic data without hand-written scripts and without leaking PII into non-production. Replaces a recurring engineering chore and gives us a concrete answer to "how is test data masked?" without a commercial masking contract. Costs to weigh: single-maintainer dependency, a PHP 8.5 requirement that narrows who can adopt it today, and an unsigned macOS build that creates friction for Mac-based developers.

Engineering: Install via composer require --dev clonio-dev/clonio-cli or run the pinned Docker image (ghcr.io/clonio-dev/clonio:v1.3.0). v1.3.0 is a feature release with no breaking changes called out, but it upgrades to Laravel Zero 13 and bumps all dependencies — smoke-test on a branch before rolling out. New cloning capabilities (exclude-column strategy, generated-column skipping, schema-only row strategy, recreate_tables for drifted targets) cut config maintenance as the schema moves, and the audit fix now preserves delivery flags when updating a channel. Treat recreate_tables as a destructive flag: disable it in any environment whose database is not explicitly disposable.