Weave Code
Airdrop Laravel Package
hammerstone/airdrop
Hammerstone Airdrop is a Laravel package for straightforward server deployments. Define environments, deploy over SSH with Artisan commands, run release tasks, and manage releases without relying on a third-party deployment service.
Hammerstone Airdrop brings the safety of migrations to your data. Write class-based data drops that are recorded in a tracking table and run exactly once per environment—so you can ship seed data, settings, or one-off data changes to production without manual SQL or re-running seeders.
- Tracked execution — each drop is recorded and never runs twice
- Rollback support — cleanly revert data changes when needed
- Artisan commands — run pending drops and inspect status
- Class-based drops — version data changes alongside your code
- Environment-safe — deploy identical data changes across environments
Frequently asked questions about Airdrop
- What does the hammerstone/airdrop package do?
- Airdrop is a Laravel deployment package that speeds up releases by skipping asset compilation when the compiled assets are already current. It fingerprints the inputs that affect compiled output and short-circuits the build step instead of running npm ci and npm run build every time. It is a deploy-time-only optimization with no runtime footprint.
- How do I install and wire Airdrop into a Laravel deploy script?
- Install it with Composer and pin an explicit version rather than relying on a floating constraint. Wire the Airdrop command into your deploy script immediately before the existing asset build step, ideally guarded by an environment flag so you can force a normal build as a kill switch. Validate the PHP and Laravel version constraints against each app before rolling it out.
- Which Laravel and PHP versions does Airdrop support?
- The package is aimed at modern Laravel applications, with Laravel 10 and 11 plus PHP 8.1 or newer being the most likely fit for a Vite-based deploy. Support matrices change between releases, so check the composer.json constraints on the exact tag you intend to deploy rather than assuming compatibility. Verify each application independently before adding it to production pipelines.
- Does Airdrop support Vite only, or also Laravel Mix and plain npm builds?
- The documented use case centers on skipping the npm ci and npm run build step used by Vite in Laravel, so Vite is the safest assumption. Support for Laravel Mix or other bundlers is not guaranteed by the package description and should be confirmed in the documentation or source before relying on it. If your app still uses Mix, test on a staging app first.
- What inputs does Airdrop hash to decide whether to skip asset compilation?
- Airdrop fingerprints the inputs that affect compiled output, such as source assets, dependency lockfiles, and build configuration. The accuracy of the skip decision depends entirely on fingerprint completeness, so changes to vite.config.js, imports resolved outside resources, or lockfile drift must be covered. Treat fingerprint completeness as the main risk and verify behavior against your own asset graph.
- Where does Airdrop store its fingerprint, and does it survive a clean CI checkout?
- The fingerprint must persist between deployments for the skip check to pay off, whether that means a cache, a build artifact, or state inside the release. On ephemeral CI runners with a fresh checkout, the state has to live in a CI cache or a committed artifact, otherwise the check is a no-op that always rebuilds. Confirm the persistence mechanism on your actual pipelines before trusting it.
- Does Airdrop fail open and build assets if the fingerprint or public/build is missing?
- Fail-open behavior is essential: if the fingerprint state or public/build is absent, the package should build anyway rather than shipping stale or missing CSS and JS. A brand-new server with no prior artifact is the clearest test case for this. Verify the fail-open path explicitly on a fresh environment before promoting the package beyond staging.
- Does Airdrop handle .env and VITE_* differences between staging and production?
- Per-environment builds can produce different compiled assets even when source files are unchanged, especially when VITE_* variables or other .env values affect the output. If Airdrop does not include those values in its fingerprint, a skip could ship staging-configured assets to production. Force a build when environment inputs differ, or verify that the package accounts for them.
- Is there a dry-run or verbose mode to compare skipped builds vs forced builds?
- If a report-only or verbose mode is available, use it for a couple of weeks on a low-traffic app and compare predicted skips against actual input changes. That gives you evidence before you let the package skip a production build. If no dry-run mode exists, keep the build forced while observing logs and only enable skipping once you trust the fingerprint.
- Does Airdrop work with Laravel Forge, Envoyer, Deployer, and atomic release symlinks?
- Airdrop is designed for server-side deploy flows where the build runs on or near the target, so it can compose with Forge, Envoyer, or Deployer hook ordering and atomic release symlinks. The check only helps when the fingerprint state survives across releases, so confirm how it interacts with public/build/manifest.json, the Vite hot file, and .gitignore rules. Verify hook placement on a staging app before changing production deploy scripts.
Weaver
How can I help you explore Laravel packages today?