- Is orkestra/guzzle-bundle compatible with Laravel?
- No. orkestra/guzzle-bundle is a Symfony bundle built around a Bundle subclass, a DependencyInjection extension, and compiler passes, none of which Laravel's kernel or container can consume. Laravel never calls registerBundles(), so even if the package installed, its service definitions and configuration schema would never be loaded.
- Can I install orkestra/guzzle-bundle in a Laravel 10, 11, or 12 project?
- Composer resolution will fail before any code runs. The bundle targets Symfony 2.x and a Guzzle 3/5-era API surface, while current Laravel requires symfony/* v6 or v7 and Guzzle 7, and those version ranges do not intersect. Forcing the install produces a dependency tree that is broken by construction.
- What does orkestra/guzzle-bundle actually do?
- It integrates the Guzzle HTTP client into Symfony applications as configurable, injectable services. You declare named clients, base URIs, middleware, plugins, and handler stacks in Symfony configuration, then inject those clients via autowiring or service references instead of instantiating Guzzle ad hoc.
- How do I install and configure orkestra/guzzle-bundle?
- In a Symfony application you would require the package with Composer, register the bundle in your kernel's bundle list, and define clients under the bundle's configuration key. That workflow is Symfony-specific; there is no equivalent registration step in Laravel, and no documented install path for a Laravel app.
- What is the Laravel equivalent of a configured Guzzle client?
- Illuminate\Http\Client, exposed through the Http facade, is Laravel's maintained Guzzle wrapper. It gives you Http::baseUrl(), timeout(), retry(), withMiddleware(), withHeaders(), and Http::fake() for tests, plus event-based logging hooks. It covers the same ground the bundle was built for, without a third-party abstraction.
- How do I set a base URI and default headers for Guzzle in Laravel?
- Define the values in a config file such as config/services.php, then either use Http::baseUrl(...)->withHeaders(...) at the call site or bind a preconfigured GuzzleHttp\Client as a singleton in a service provider. The latter takes roughly twenty lines and keeps raw Guzzle semantics available when you need custom handlers or streaming.
- Is orkestra/guzzle-bundle safe to use in production?
- It is archived, with no security patches, no PHP compatibility fixes, and no maintainer to escalate to. It pulls in end-of-life Symfony and Guzzle components that have no upstream remediation path, and it has zero public dependents, meaning no battle-testing or issue history. The technical risk is high across the board.
- Can I still use raw Guzzle in a Laravel application?
- Yes. Guzzle 7 installs cleanly alongside Laravel, and the idiomatic approach is to bind a configured GuzzleHttp\Client as a singleton in a service provider, then inject or resolve it where needed. This is the right route when you need custom handler stacks, parallel pools, or non-standard transports that the Http facade does not expose.
- How should I test HTTP clients in Laravel without this bundle?
- Use Http::fake() to stub responses and Http::assertSent() to assert outgoing requests, both of which are first-class features of Illuminate\Http\Client. If you are testing a raw Guzzle client instead, pass a MockHandler into the handler stack or swap the client binding in the container. No Symfony bundle is involved in either approach.
- What are the alternatives to orkestra/guzzle-bundle for Laravel developers?
- For application-level HTTP, use Illuminate\Http\Client; for lower-level control, bind GuzzleHttp\Client directly; and if you want framework-agnostic HTTP, consider symfony/http-client or any PSR-18 client with a Laravel adapter. All three are maintained, compatible with current Laravel, and require no bundle registration.