- How do I install octohk/laravel-segment in a Laravel application?
- Install it with Composer using composer require octohk/laravel-segment. The package ships a Laravel service provider that is auto-discovered, so no manual registration is normally required. After installing, publish the configuration file with php artisan vendor:publish and add your Segment write key to the environment. Check the repository README for the exact publish tag and any optional config keys.
- Which Laravel and PHP versions does laravel-segment support?
- Version 1.9.0 added Laravel 13 support on top of the existing Laravel 10, 11 and 12 constraints, so the package tracks the framework's annual major-release cadence. Because Laravel 13 raises the minimum PHP version, the package's own PHP floor may have moved as well. Confirm the exact Laravel and PHP matrix by reading the composer.json diff between v1.8.x and v1.9.0 before you commit. That two-minute check answers most compatibility questions.
- How do I configure my Segment write key?
- Publish the package config file and set your Segment write key, typically through a SEGMENT_WRITE_KEY environment variable referenced by that config. Keeping the key in .env means it stays out of version control and can differ per environment. Once the key is set, the facade can send identify, track, page, group and alias calls to Segment.
- Does laravel-segment queue events so analytics calls don't slow down requests?
- Yes. The package supports optionally queueing events so analytics calls never block your application requests. Enabling queueing in the config routes the Segment calls through your configured Laravel queue driver, so the HTTP request returns without waiting on Segment's API. Make sure a queue worker is running in every environment where queueing is enabled, or events will accumulate.
- Which Segment calls does the package support?
- The facade exposes the core Segment tracking methods: identify, track, page, group and alias. That covers user identification, event tracking, page views, account-level grouping and identity merging. You call them through the package's facade rather than wiring the Segment SDK directly into your controllers and jobs.
- Is it safe to upgrade to v1.9.0, or did it drop Laravel 10 and 11 support?
- Version 1.9.0 is a minor release whose visible change is Laravel 13 support, which implies a widened constraint rather than a replacement, but that is not guaranteed. A minor bump can also mask a raised PHP floor, which is breaking in practice even when semver says otherwise. Read the composer.json diff between v1.8.x and v1.9.0 and run composer update octohk/laravel-segment --with-dependencies --dry-run in a branch. If you must stay on Laravel 11 or below and the constraints were replaced, pin to v1.8.x.
- How do I test Segment tracking in my Laravel test suite without sending real data?
- Point the package at a test write key and prevent outbound calls, or fake the queue when queueing is enabled so you can assert the expected jobs were dispatched. If the package calls Segment's client directly, mock that underlying client and assert the method and payload. The exact seam depends on whether events are queued or sent inline, so inspect the package source once and standardise on one approach across your suite. Avoid letting tests hit the real Segment API, since that pollutes your production analytics data.
- What are the alternatives to octohk/laravel-segment?
- The most direct alternative is Segment's official PHP SDK, segmentio/analytics-php, wrapped in your own small service provider and facade, which gives you full control at the cost of writing and maintaining that glue. Other community Laravel wrappers exist but vary in how actively they track Laravel majors. This package's main value is the opinionated, ready-made facade plus optional queueing, so weigh that against the maintenance overhead of owning the integration yourself.
- Is octohk/laravel-segment actively maintained?
- The strongest available signal is that v1.9.0 shipped Laravel 13 support promptly, which shows the maintainers monitor Laravel's annual major-release cadence and cut compatibility releases. That is the most predictive maintenance indicator for a framework-coupled dependency. What is not documented is a formal support or end-of-life policy tying package versions to Laravel majors, so ask the maintainers directly whether older lines keep receiving security and bug fixes.
- What should I do before upgrading my application to Laravel 13 with this package?
- Adopt v1.9.0 on your current Laravel major first, stabilize it, then upgrade the framework, rather than changing both in one commit. Diff composer.json between v1.8.x and v1.9.0, run composer update --with-dependencies --dry-run to inspect the resolved dependency graph, and run your integration tests that touch the Segment surface area. Check your PHP version too, since Laravel 13's higher PHP floor can block you before the framework does. Collapsing the package and framework upgrades into one change merges two failure domains into a single debugging session.