承接 igne-agency/laravel-boot-up 相关项目开发

从需求分析到上线部署,全程专人跟进,保证项目质量与交付效率

邮箱:yvsm@zunyunkeji.com | QQ:316430983 | 微信:yvsm316

igne-agency/laravel-boot-up

Composer 安装命令:

composer require igne-agency/laravel-boot-up

包简介

Boot a Laravel project on any machine with one command: app:serve installs missing tools (PHP, Node, Composer, Herd, Docker), creates .env, sets up the database, runs migrations, builds assets, starts a queue worker and serves via Herd, Sail or artisan serve; app:down cleanly stops everything it sta

README 文档

README

Boot a Laravel project on any machine — even a blank one — with two commands:

composer install
php artisan app:serve

app:serve installs or updates the tools you're missing (Homebrew, PHP, Node, Composer, Docker, Herd, bun/yarn/npm/pnpm), creates your .env, sets up the database (prompting for credentials when they're missing), runs pending migrations, installs dependencies, builds or watches assets, starts a queue worker when your project needs one, and serves the app via Herd, Sail, or php artisan serve. app:down cleanly stops everything it started — and nothing it didn't.

Development only. Requires PHP 8.3+, Laravel 13, macOS or Linux.

Installation

composer require igne-agency/laravel-boot-up --dev

The package auto-registers via Laravel's package discovery. Always use --dev; this package has no business in production.

Usage

php artisan app:serve            # prompts for a server on first run
php artisan app:serve herd       # or: sail | laravel
php artisan app:serve --seed     # seed after migrating
php artisan app:serve --update   # update dependencies instead of installing
php artisan app:serve --no-migrate --without-queue --without-assets

php artisan app:deploy           # dependencies + project commands + migrations, no server
php artisan app:down             # stop tracked processes + the server app:serve started

php artisan app:deploy-script forge production        # export a hosting deployment script
php artisan app:deploy-script fortrabbit staging      # (see "Exporting a deployment script")

php artisan app:pipeline github                       # generate a CI/CD pipeline + .env.pipeline
php artisan app:pipeline bitbucket                    # (see "Generating a CI/CD pipeline")

What app:serve does, in order

Every step is a small class; the full ordered list is published config you can reorder, trim, or extend (boot-up.serve_steps):

  1. Create .env from .env.example when missing
  2. Guard against non-local environments (a fresh .env counts as local)
  3. Generate APP_KEY when empty
  4. Install missing tools / update ones that violate your version constraints
  5. Start the chosen server (Herd link+secure · Docker+Sail up · php artisan serve)
  6. composer install (or --update)
  7. Frontend install with bun/yarn/npm/pnpm
  8. Prompt for missing DB_* env values and write them to .env
  9. Create the database when it doesn't exist, verify the connection
  10. Your project's beforeMigrations() commands
  11. Run migrations — only when there are pending ones
  12. Your project's afterMigrations() commands
  13. Optional framework caching (off by default) + finalize (storage:link)
  14. Start queue:work — only when QUEUE_CONNECTION is not sync
  15. Build or watch assets
  16. Announce the URL and open your browser

Long-running processes (queue worker, asset watcher, php artisan serve) run detached in the background with their output in storage/logs/boot-up/ and their PIDs tracked in storage/framework/boot-up/, so app:down can reap exactly them. Set BOOT_UP_QUEUE_RUN_IN=terminal (or BOOT_UP_ASSETS_WATCH_IN=terminal) to open real terminal windows instead.

Shutdown behavior

  • app:down (and Ctrl-C during app:serve) stops every tracked background process, then asks whether to stop the server — only the server that app:serve itself started. A Herd or Sail that was already running before you served is left alone.
  • Re-running app:serve never stacks duplicate workers or watchers, and a second app:down is a friendly no-op.

Configuration

php artisan vendor:publish --tag=boot-up-config

Highlights of config/boot-up.php:

'server' => [
    'default' => env('BOOT_UP_SERVER'),           // 'herd' | 'sail' | 'laravel' | null = prompt
    'drivers' => [ /* add your own Server implementations here */ ],
    'herd' => [
        'site' => env('BOOT_UP_HERD_SITE'),       // https://{site}.test; null = prompt (folder name as default)
    ],
],

'tools' => [
    'auto_install' => true,
    'auto_update' => true,                          // update when the constraint is violated
    'required' => [
        'php' => env('BOOT_UP_PHP_VERSION', '*'), // composer-style constraints: '^8.3', '*'
        'node' => env('BOOT_UP_NODE_VERSION', '*'),
        'composer' => env('BOOT_UP_COMPOSER_VERSION', '*'),
    ],
],

'frontend' => [
    'package_manager' => env('BOOT_UP_PACKAGE_MANAGER', 'bun'), // bun | yarn | npm | pnpm
    'assets' => env('BOOT_UP_ASSETS', 'watch'),                 // watch | build | skip
],

'serve_steps' => [ /* the entire pipeline, reorderable */ ],
'deploy_steps' => [ /* what app:deploy runs */ ],

Sail extras: when serving with Sail, the package offers (once, with your consent) to add the sail alias to your shell profile, and rewrites every app-level command to run inside the containers (./vendor/bin/sail artisan ...).

Herd extras: app:serve herd verifies Herd's site registry against the actual project path. A link pointing at a moved project (the classic "folder-was-relocated 404") is replaced automatically; a name owned by another live project is only taken over after you confirm. On first link you choose the site name — the folder name is the default, so https://{name}.test can differ from the directory. Pin it with BOOT_UP_HERD_SITE to skip the prompt.

Exporting a deployment script

app:deploy-script turns this package's config (package manager, migrations, finalize commands, queue usage, and your bound project commands) into a paste-ready deployment script for your hosting platform:

php artisan app:deploy-script forge production        # zero-downtime release script (Forge's default)
php artisan app:deploy-script forge production --classic   # for older sites without zero-downtime deployments
php artisan app:deploy-script fortrabbit staging      # "Build commands" + "Post deploy commands" sections
php artisan app:deploy-script                         # prompts for platform + environment
php artisan app:deploy-script forge production --output=deploy.sh
  • Forge — the zero-downtime script uses Forge's release macros ($CREATE_RELEASE(), $ACTIVATE_RELEASE(), $RESTART_QUEUES()); paste it into your site's deployment script. The --classic variant (git pull + PHP-FPM reload) is for sites created without zero-downtime deployments — the two styles cannot be mixed.
  • Fortrabbit — outputs the two command lists the fortrabbit dashboard expects per environment: Build commands (composer + frontend build; the package manager is npm i -g-installed when it isn't npm) and Post deploy commands (migrations, optimize, finalize, queue restart).
  • The environment argument tunes the script: development keeps dev dependencies and skips artisan optimize; staging/production add --no-dev and framework caching.
  • Your ProvidesProjectCommands binding is embedded at the right positions (before/after migrations), with descriptions as comments.

Generating a CI/CD pipeline

app:pipeline writes a ready-to-commit pipeline for your git provider plus a .env.pipeline test environment, both at their canonical paths:

php artisan app:pipeline github       # .github/workflows/ci.yml + .env.pipeline
php artisan app:pipeline bitbucket    # bitbucket-pipelines.yml + .env.pipeline
php artisan app:pipeline              # prompts for the provider
php artisan app:pipeline github --force   # overwrite existing files without asking

Both providers run the identical command sequence (generated from one shared source): composer install with caching, cp .env.pipeline .env, Nova publish (only when laravel/nova is in your composer.json — composer auth comes from a COMPOSER_AUTH secret), lockfile-strict frontend install + build (driven by your frontend.package_manager config), finalize commands, project commands, migrate --force, and php artisan test. When laravel/pint is installed, a lint job (pint --test) runs in parallel with the tests on both providers, and deploys wait for both to pass.

  • Tests run on every pull request and on pushes to the deploy branches, against in-memory SQLite (.env.pipeline carries the config — commit it; the generated APP_KEY is only ever used in CI).
  • Deploys are webhook-based: after a green push, the pipeline curls the hook named in boot-up.pipeline.branches (defaults: developDEV_DEPLOY, stagingSTAGING_DEPLOY, masterPROD_DEPLOY). Point each secret at your host's deploy trigger URL (e.g. Forge's "Deployment trigger URL"). An unset hook skips that deploy with a notice instead of failing the run. On a main repo, remap boot-up.pipeline.branches and regenerate.
  • PHP version comes from your composer.json require.php (setup-php on GitHub, the laravelsail/php{XY}-composer image on Bitbucket).
  • After generating, the command prints exactly which secrets/variables to create and where (GitHub → Actions secrets; Bitbucket → secured repository variables + enabling Pipelines once). Nothing else needs to change in the git provider.

Extending the package

Four extension points, none of which require touching package code:

  1. Project commands — generators and warmers that run before/after migrations. See CUSTOM_COMMANDS.md and examples/ProjectCommands.php.
  2. Custom pipeline steps — implement Serve\Step and insert the class anywhere in the published serve_steps / deploy_steps arrays.
  3. Custom servers — implement Servers\Server and register it under server.drivers (e.g. 'valet' => ValetServer::class). It becomes selectable by argument, config, and prompt, and participates in state tracking, shutdown, and command rewriting automatically.
  4. Custom tools — implement Tools\InstallsTool and map it under tools.installers with a constraint under tools.required. Config wins on key collision, so you can also replace a built-in installer (e.g. install Node via nvm).
  5. Custom deployment platforms — implement Deploy\Scripts\ScriptGenerator and register it under deploy.script_generators (e.g. 'envoyer' => EnvoyerScriptGenerator::class); it becomes selectable in app:deploy-script alongside Forge and Fortrabbit.
  6. Custom git providers — implement Pipelines\PipelineGenerator and register it under pipeline.generators (e.g. 'gitlab' => GitlabPipelineGenerator::class); it becomes selectable in app:pipeline alongside GitHub and Bitbucket.

Testing

composer test          # Pest 4 suite (unit + feature + architecture tests)
vendor/bin/pint        # code style

License

MIT — see LICENSE.

igne-agency/laravel-boot-up 适用场景与选型建议

igne-agency/laravel-boot-up 是一款 基于 PHP 开发的 Composer 扩展包,目前已累计 0 次下载、GitHub Stars 达 0, 最近一次更新时间为 2026 年 07 月 15 日, 在 PHP 生态内属于活跃度较高的组件。

它主要适用于以下技术方向: 「development」 「laravel」 「deployment」 「forge」 「dev-tools」 「onboarding」 等业务场景。在实际项目中,围绕这些方向常见需要落地的问题包括:接口对接、性能调优、并发安全、与既有框架(Laravel / ThinkPHP / Yii / Webman 等)的兼容适配,以及生产环境的日志埋点与稳定性保障。

我们在过去多个企业项目中使用过 igne-agency/laravel-boot-up 或与其功能相近的方案,如果你在选型或落地过程中遇到问题,例如 版本兼容、二次改造、私有化封装、与内部系统对接、生产 BUG 排查,欢迎联系我们协助评估。

围绕 igne-agency/laravel-boot-up 我们能提供哪些服务?
定制开发 / 二次开发

基于 igne-agency/laravel-boot-up 在你已有业务上做功能扩展、字段裁剪、UI 适配、与内部账号 / 权限 / 日志系统的深度对接。

BUG 修复 & 性能优化

线上偶发问题、内存泄漏、慢查询、并发异常等排查修复;针对高流量场景做缓存、队列、索引层面的调优。

项目外包 & 长期维护

承接完整的项目从需求 → 设计 → 开发 → 上线 → 长期运维;也可按月提供技术保姆服务。

yvsm@zunyunkeji.com QQ:316430983 微信:yvsm316 西安尊云信息科技 · 专注 PHP / Go / 分布式系统研发

统计信息

  • 总下载量: 0
  • 月度下载量: 0
  • 日度下载量: 0
  • 收藏数: 0
  • 点击次数: 9
  • 依赖项目数: 0
  • 推荐数: 0

GitHub 信息

  • Stars: 0
  • Watchers: 0
  • Forks: 0
  • 开发语言: PHP

其他信息

  • 授权协议: MIT
  • 更新时间: 2026-07-15