Weave Code
Kernel Laravel Package
orchestra/kernel
Orchestra Kernel provides the application kernel and foundational bootstrapping for Orchestra Platform, extending Laravel with modular extension support, service providers, and a streamlined base for building admin-ready applications.
Orchestra/Kernel provides the core bootstrap HTTP and Console kernels for the Orchestra Platform, a modular extension of Laravel. It orchestrates application bootstrapping, wires service providers, and manages the request and console lifecycles so modular applications start cleanly and consistently.
- Extends Laravel's foundation kernels with platform-specific bootstrapping
- Loads and boots extensions and their service providers
- Manages HTTP request and Artisan console lifecycles
- Provides memory/resource handling during bootstrap
- Serves as the runtime backbone for Orchestra Platform components
Frequently asked questions about Kernel
- What is orchestra/kernel and what does it do in a Laravel application?
- Orchestra/Kernel provides the core bootstrap HTTP and Console kernels for Orchestra Platform, a modular extension of Laravel. It orchestrates application bootstrapping, wires service providers, and manages the request and console lifecycles so modular applications start consistently. It is best understood as the runtime backbone for Orchestra Platform components rather than a standalone feature package.
- Which Laravel versions does orchestra/kernel support?
- The only documented release artifact in the supplied context is v6.0.0, which targets Laravel 8. There is no evidence of a newer tag in those sources, so a greenfield Laravel 10 or 11 project should confirm a compatible release exists before adopting it. Treat the Laravel 8 ceiling as an inherited schedule and security constraint, not something you can fix internally.
- How do I install orchestra/kernel with Composer?
- Installation is done with Composer, but the integration is a kernel substitution rather than an additive library. You typically adopt Orchestra\Foundation\Application and replace the HTTP kernel, console kernel, and exception handler bindings in bootstrap/app.php. Expect exact version pins, a config/orchestra.php file to commit and diff, and a first cutover goal of booting identically to the previous kernel.
- How is orchestra/kernel different from Laravel's default HTTP and Console kernels?
- It extends Laravel's foundation kernels with Orchestra Platform-specific bootstrapping and owns the request pipeline, console registration, and exception handling for the application. The practical unit of evaluation is the $bootstrappers array, which defines exactly which steps Orchestra injects into the Laravel boot sequence and in what order. Extension discovery, provider orchestration, routing, and middleware all hang off that array.
- Do I need orchestra/kernel if I am not using Orchestra Platform?
- Probably not. The package is the load-bearing shim for an Orchestra Platform commitment and is not independently valuable outside that stack. If you only need internal code organization, Laravel's native service providers, package discovery, and standard kernels are simpler and carry less blast radius.
- How does orchestra/kernel load extensions and service providers?
- It loads and boots Orchestra Platform extensions and their service providers as part of the kernel bootstrapping process. The $bootstrappers array controls the injection order, so provider registration, routing, and middleware setup depend on that sequence. This ordering is why boot parity matters more than simply getting the application to start.
- Can I test a package that depends on orchestra/kernel with orchestra/testbench?
- Yes. The orchestra/testbench harness mirrors kernel bootstrapping so package-level tests can run against the Orchestra stack instead of a hand-rolled application instance. That gives you a supported way to exercise boot behavior and service provider wiring. It is also a good foundation for parity tests against a vanilla-kernel branch or recorded fixture.
- What are the production risks of using orchestra/kernel, especially with Octane or long-lived workers?
- Under Octane or any long-lived worker, bootstrappers run once, so request-scoped state cached in a bootstrapper can leak across requests. The more expensive risk is silent divergence: middleware ordering or container resolution may differ by one step and surface weeks later in auth or exception handling. Mitigate with a parity harness that diffs container bindings, loaded providers, middleware order, route list, and artisan list output.
- Is orchestra/kernel actively maintained, and what is the upgrade path for newer Laravel versions?
- The context shows zero stars, zero dependents, a single-maintainer bus factor, no SLA, and no documented security-patch latency. There is no Stack Overflow corpus or ecosystem peer pressure keeping it working, so debugging often means inspecting vendor code directly. Every Laravel minor becomes a coordinated upgrade against an external maintainer's schedule, which is a recurring tax.
- What alternatives exist to orchestra/kernel for modular Laravel applications?
- The main alternative is a standard Laravel kernel plus your own service providers, package discovery, and route or middleware organization. That approach is simpler when modularity is only internal code organization rather than a customer-facing extension marketplace or partner plugin system. Evaluate whether first-party service providers already solve the requirement before taking on a platform kernel dependency.
Weaver
How can I help you explore Laravel packages today?