Weave Code
Lumen Laravel Package
orchestra/lumen
Orchestra Lumen brings Orchestra Platform-style service providers, extensions, and resource management to the Lumen micro-framework, helping you bootstrap configuration and structure for fast, lightweight Laravel-based APIs and services.
Orchestra/Lumen bridges the lightweight Lumen micro-framework with the Orchestra Platform ecosystem, letting you build fast, service-oriented applications while keeping Orchestra's extension and configuration tooling. It pairs Lumen's minimal bootstrap with Laravel-style conventions, so packages and settings can be shared cleanly across both frameworks.
- Seamless Lumen bootstrapping inside Orchestra
- Laravel-compatible service providers and facades
- Shared configuration and package discovery
- Lightweight routing and middleware integration
- Simple Composer installation and autoloading
Frequently asked questions about Lumen
- What is orchestra/lumen used for?
- Orchestra/Lumen is a compatibility bridge that lets Orchestra Platform service providers, facades, configuration loading, and container bindings resolve inside the Lumen micro-framework's lighter bootstrap. It is intended for existing Orchestra Platform codebases that must also run on Lumen, or codebases deliberately sharing code between the two frameworks. It is not a platform of its own, and for a greenfield API or admin surface plain Laravel or Lumen is simpler.
- How do I install orchestra/lumen with Composer?
- Run composer require orchestra/lumen, but do not expect anything to work from autoloading alone because Lumen does not auto-discover service providers. You must hand-register each Orchestra provider in bootstrap/app.php in the correct order, call $app->withFacades() before Orchestra providers register, and copy config files manually since Lumen has no vendor:publish. Before committing, prove resolution with composer require orchestra/lumen --dry-run against your exact PHP and Lumen versions.
- Which Lumen and Laravel versions does orchestra/lumen support?
- The package sits between two sets of illuminate/* constraints, so real support depends on what Composer can resolve against your pinned PHP and Lumen versions. Check composer show orchestra/lumen --tree and run a dry-run require before assuming compatibility. If resolution fails there is no upstream fix path to wait for, so treat the dry run as the cheapest go or no-go test you have.
- Why can't Lumen find my Orchestra service providers after installation?
- Lumen disables package auto-discovery, so a successful composer require registers nothing on its own. You have to add every Orchestra provider explicitly in bootstrap/app.php, and registration order matters because those providers expect the container and facades to be ready. A missing $app->withFacades() call is one of the most common reasons providers fail to boot.
- How do I fix BindingResolutionException when calling config() inside an Orchestra provider's register() method?
- Lumen binds the config repository later in the boot sequence than Laravel does, so reading config() inside register() fails with BindingResolutionException. Move that logic into boot() or defer it until configuration is loaded. A single probe route that resolves one Orchestra contract is enough to confirm whether the boot and binding order is now correct.
- Is orchestra/lumen safe to use in production?
- Treat it as high risk and internal-only unless you control the entire stack and accept the maintenance burden. The failure modes are quiet: an unrelated composer update can drift an illuminate/* constraint out from under the bridge, and missing session, cache, queue, or broadcast drivers can silently fall back to an in-memory driver in production. The package also reaches into Symfony internals, so a Symfony minor bump can break it with no upstream owner to patch it.
- How does orchestra/lumen compare to just using Laravel instead of Lumen?
- Laravel already ships package auto-discovery, vendor:publish, and full session, cache, queue, and broadcast drivers, so most Orchestra packages work without a shim. Orchestra/Lumen exists to make those packages run on Lumen's minimal bootstrap, which means manual provider registration and manual config copying. If the only reason for choosing it is lightness, you likely do not have a concrete requirement that justifies the extra kernel boundary.
- Is orchestra/lumen actively maintained?
- It has effectively no community patch stream: zero dependents, low visibility, and a bus factor of one, so knowledge of the boot sequence lives with whichever engineer read it. Security fixes, framework upgrades, and onboarding are internal line items rather than upstream work. Before adopting it, name a code owner and a funded exit date.
- Can I use orchestra/lumen with queues, sessions, caching, or broadcasting?
- Lumen does not register session, cache, queue, or broadcast the way Laravel does, so Orchestra providers that assume Laravel defaults may not behave correctly. Any requirement on the request path for queues, scheduling, broadcasting, or a Blade-heavy admin UI collapses the fit and makes Laravel the correct target. Verify each driver explicitly instead of trusting defaults.
- Should I pull orchestra/foundation or only the lighter Orchestra contracts with orchestra/lumen?
- Using the full orchestra/foundation admin and extension surface is an order of magnitude harder to keep alive than depending only on lighter contracts such as orchestra/support, orchestra/memory, or orchestra/authorization. Run composer show orchestra/lumen --tree to see exactly which Orchestra packages you are pulling in. Decide that scope in design review, because it drives the entire maintenance estimate.
Weaver
How can I help you explore Laravel packages today?