- Can I use gylaandrij/swiftmailer-mailgun-bundle in a Laravel application?
- Not directly. It is a Symfony bundle built around a DI extension and a Swiftmailer transport service, and Laravel has no bundle lifecycle; it uses service providers, a MailManager, and transport closures registered through Mail::extend(). Making it work would mean extracting the transport factory and re-hosting it in your own provider, which is effectively writing the integration yourself rather than adopting the package. Laravel also already ships a first-class Mailgun driver, so there is no architectural gap to fill.
- How do I install swiftmailer-mailgun-bundle?
- The intended path is a Composer require plus registering the bundle in a Symfony kernel and configuring it under a swiftmailer_mailgun-style config namespace. Laravel has no equivalent registration step, so there is no supported install path for a Laravel app. Even in Symfony, the package pins Swiftmailer and Symfony component ranges from the Symfony 2/3/4 era, so expect dependency resolution conflicts on any modern application.
- Does this bundle support Laravel 9, 10, or 11?
- No. Laravel 9 and later removed Swiftmailer entirely in favor of Symfony Mailer, so there is nothing for this bundle to bind to. Laravel 9+ delivers Mailgun through symfony/mailgun-mailer, and older Laravel versions can install Swiftmailer but the bundle's constraints may force downgrades of symfony/* packages shared with the framework. A mail transport that requires downgrading framework components is a non-starter for production.
- Does it support the Mailgun v3 API and the EU region endpoint?
- This is unclear from the available documentation. The bundle likely targets the Mailgun v2 API or an early v3 client, and Mailgun has deprecated and retired older API surfaces, so even a successful install may fail at runtime against the current API. The README excerpt does not document endpoint configuration or EU region support, so verify both with the maintainer before depending on it.
- Is this package maintained and safe for production?
- Treat it as high risk. Swiftmailer reached end of life in November 2021 and receives no security patches, so any dependency graph that keeps it installed is a standing liability. The package itself sits at roughly one star and zero dependents with no issue traffic, meaning there is no production validation to learn from and no realistic prospect of upstream fixes.
- What should Laravel developers use instead for Mailgun?
- Use Laravel's native mailgun mailer: set MAIL_MAILER=mailgun and provide your domain, secret, and optional endpoint in config/services.php and config/mail.php. That driver is maintained with the framework and already handles Mailgun API changes. If you genuinely need behavior the driver lacks, implement a small custom transport of roughly 100 lines behind Mail::extend() instead of pulling in an end-of-life bundle.
- How are Mailgun credentials configured, and are they read from environment variables?
- The bundle configures the transport through Symfony DI under a swiftmailer_mailgun-style namespace, which typically means container parameters. The available evaluation does not confirm whether credentials are resolved from environment variables at runtime or written into compiled container configuration, and that distinction matters for secret handling. In Laravel the equivalent is config/services.php reading env values, but do not assume the bundle behaves the same way.
- Does it handle Mailgun webhooks and event tracking, or only outbound sending?
- Based on the evaluation, it only provides an outbound Swiftmailer transport; no webhook or event-handling surface is exposed. If you need delivery events, bounces, or complaint handling you would build that separately against Mailgun's webhooks. This is one more reason the bundle adds little over Laravel's built-in Mailgun integration.
- How would I test this package before putting it in production?
- The evaluation reports no meaningful adoption signal, so you would be the one validating it. Start by attempting a clean Composer install in a throwaway Symfony or Laravel 8 project to see whether dependency resolution succeeds without downgrading symfony/* packages. Then send against a Mailgun sandbox domain to confirm the API version still works, and in Laravel use Mail::fake() or a custom transport wrapper so your test suite never depends on EOL Swiftmailer code paths.
- What license is it under, and is there a maintained fork or successor?
- The README excerpt provided does not state a license, so check the repository before any reuse or vendoring. There is no known maintained fork or successor; the modern equivalents are Laravel's native mailgun mailer on Laravel 9+ and symfony/mailgun-mailer on the Symfony side. If you do copy the transport class into app/Support/Mail, keep the attribution and confirm the license permits it.