Most products now claim to offer “application performance monitoring”, “distributed tracing”, “profiling”, “observability”, “error monitoring”, or some combination of all five. But those words do not always mean the same thing.

Some tools genuinely hook into the PHP runtime and show you what your application did at method, function, query, template, queue-job, or framework level. Others are closer to event collectors: they receive spans, errors, metrics, or emitted events, then wrap those events in dashboards. Both approaches can be useful, but they solve different problems.

If your question is:

“Which service is slow?”

A general APM or observability platform may be enough.

If your question is:

“Which PHP method, query, framework call, middleware, template render, or queue job made this request slow?”

You need something deeper than a glorified event wrapper.

That distinction is the core of this guide.

Below, we compare the best PHP APM tools in 2026, including New Relic, Datadog, Sentry, Scout APM, Tideways, Blackfire, Elastic APM, Pinpoint, Instana, and Perfbase.

Quick answer: the best PHP APM tools in 2026

The strongest PHP APM tools in 2026 are:

If you only want the short version:

Use Perfbase, Tideways, or Blackfire if PHP performance is the main thing you care about.

Use Datadog, New Relic, Elastic, or Instana if PHP is only one part of a wider multi-language platform.

Use Sentry if error tracking and developer workflow are just as important as performance.

Use Scout APM if you want a lighter, friendlier PHP monitoring product without the weight of a full observability suite.

What makes a PHP APM tool good?

A good PHP APM tool should do more than tell you that /checkout was slow.

It should help you understand why.

That means looking at:

1. Runtime depth Does the tool hook into PHP deeply enough to see functions, methods, database queries, framework internals, queue jobs, templates, and external calls?
2. Tracing quality Can it show a request or job from start to finish, including database, cache, HTTP, queue, and background work?
3. Profiling quality Can it show where CPU time, memory, and wall time were actually spent?
4. Framework awareness Does it understand Laravel, Symfony, WordPress, Magento, Yii, CakePHP, Joomla, or custom PHP apps?
5. Production safety Is the overhead low enough to leave enabled in production?
6. Pricing clarity Are you paying per host, per seat, per span, per trace, per project, per user, or by some confusing combination?
7. Data minimisation Does it avoid collecting request bodies, secrets, credentials, and sensitive payloads?
8. APM honesty Is it truly observing PHP execution, or mostly displaying events your code or SDK emitted?

That last point matters.

A product can have nice dashboards and still be shallow. If it only shows spans that were manually emitted, it may help you see the broad shape of a request, but it will not necessarily show the PHP runtime-level truth.

For PHP teams, the best APM tools are usually the ones that combine tracing with profiling.

PHP APM depth comparison

Here is the most important table in this article.

This does not mean Datadog or New Relic are weak products. They are excellent platforms. But they are not built around PHP in the same way that Perfbase, Tideways, or Blackfire are.

That is the core buying decision:

Do you want a broad observability platform that also supports PHP, or a PHP performance tool built specifically around how PHP applications actually run?

1. Perfbase

Best for: PHP teams that want proper runtime-level performance insight without enterprise observability bloat.

Perfbase is a PHP-focused APM and profiling tool built for teams that care about what happens inside their PHP applications.

Unlike tools that mostly rely on emitted spans or high-level transaction events, Perfbase is designed around native PHP profiling. It hooks into the runtime, captures call-level execution data, and turns that into flamegraphs, call trees, slow query views, memory analysis, CPU analysis, and request-level traces.

That makes it especially useful when you need to answer questions like:

• Which method caused this request to slow down?
• Which database query is repeated too often?
• Is this a Laravel middleware issue, an Eloquent issue, a view rendering issue, or a third-party HTTP call?
• Which part of this queue job is actually expensive?
• Did this deployment make a specific code path slower?

Perfbase supports modern PHP versions, common frameworks, and custom PHP applications. It is also priced per project rather than per host, per seat, or per span, which makes it easier to reason about cost.

That matters because PHP infrastructure is often messy. You may have multiple servers, workers, queues, staging environments, and cron workloads. Per-host APM pricing can become painful quickly. Per-project pricing is much easier for PHP teams to understand.

Where Perfbase is strongest

Perfbase is strongest when you want PHP-native visibility.

It is not trying to be a giant observability platform for every language, cloud, container, log line, browser session, and security event. That is a feature, not a weakness, if your main problem is PHP performance.

Perfbase is especially strong for:

• PHP SaaS applications
• Laravel applications
• Symfony applications
• WordPress and CMS-heavy systems
• Custom PHP platforms
• Agencies managing multiple PHP projects
• Teams that care about profiling, not just dashboards
• Teams that want low overhead and simple pricing

How much of an APM is Perfbase?

Perfbase scores highly here.

It is not just a wrapper around manually emitted events. It is closer to a true PHP runtime profiler and APM hybrid. It shows what the PHP application actually did, not merely what the developer remembered to instrument.

That makes it one of the more serious options if your definition of APM includes “show me the code path that caused the slowdown”.

Perfbase pros

• PHP-native runtime-level visibility
• Flamegraphs and call trees
• Database query analysis
• Memory and CPU profiling
• Useful for Laravel, Symfony, WordPress, and custom PHP
• Predictable per-project pricing
• Strong fit for production performance debugging
• Less bloated than general observability platforms

Perfbase cons

• Newer than incumbents like New Relic, Datadog, Blackfire, and Tideways
• Less public third-party validation than older tools
• Not designed to replace a whole-company observability platform
• Not the obvious choice if you need Kubernetes, infrastructure, logs, RUM, security, and APM in one vendor

Verdict

Perfbase is one of the best PHP APM tools in 2026 if your main goal is to understand PHP performance at code level.

It is especially compelling for teams that look at general APM dashboards and think:

“This tells me the request was slow, but not enough about why.”

For PHP-first teams, Perfbase should be on the shortlist.

2. Tideways

Best for: Mature PHP production observability.

Tideways is one of the strongest established PHP-specific APM tools.

It has a long history in the PHP ecosystem and is built around production tracing, framework awareness, bottleneck detection, and application-level insight. Tideways is especially relevant for teams running Laravel, Symfony, Shopware, Magento, WordPress, TYPO3, Laminas, Yii, CakePHP, Slim, or other PHP frameworks.

The key advantage of Tideways is that it understands PHP applications as PHP applications. It is not just ingesting generic telemetry and asking you to make sense of it yourself.

It can identify transactions, database calls, framework operations, external HTTP calls, queue work, and other common sources of production bottlenecks.

How much of an APM is Tideways?

Very much so.

Tideways is not merely an event dashboard. It is a PHP-native production performance tool with tracing and profiling roots. It has enough runtime and framework awareness to be considered a real PHP APM, not a generic tracing wrapper.

Tideways pros

• Strong PHP-native instrumentation
• Mature production tracing
• Broad framework support
• Good fit for Laravel, Symfony, Magento, Shopware, WordPress, and TYPO3
• Clearer PHP focus than most generalist platforms
• Good for finding bottlenecks in real production traffic

Tideways cons

• Narrower than Datadog or New Relic outside PHP
• Less useful if your estate is mostly non-PHP
• Retention and pricing may not suit every team
• Not as broad a general observability suite as enterprise platforms

Verdict

Tideways is one of the safest choices for PHP teams that want mature production APM without buying into a huge general-purpose observability platform.

If you are comparing PHP-native tools, Tideways should be compared directly with Perfbase and Blackfire.

3. Blackfire

Best for: Deep profiling, performance testing, and optimisation workflows.

Blackfire is one of the best-known PHP performance tools. It is especially strong as a profiler.

Blackfire helps developers inspect performance profiles, compare runs, enforce performance assertions, and build optimisation workflows into development and CI/CD. It is commonly used by teams that treat performance as an engineering discipline rather than something they only inspect after production incidents.

Blackfire also offers monitoring and continuous profiling features, but its centre of gravity is still profiling. That is not a criticism. In fact, for many PHP teams, profiling is exactly what they need.

How much of an APM is Blackfire?

Blackfire is a serious performance tool, but it is more profiler-first than classic APM-first.

It can monitor and profile production applications, but its biggest strength is helping engineers understand and improve code-level performance. If you want error inboxes, infrastructure monitoring, logs, RUM, and broad dashboards, Blackfire is not the obvious first pick. If you want deep PHP profiling, it is one of the best tools available.

Blackfire pros

• Excellent PHP profiling
• Strong flamegraph and call-level performance analysis
• Great for optimisation workflows
• Useful in development, staging, CI, and production
• Performance assertions and testing are valuable for serious teams
• Deep PHP ecosystem credibility

Blackfire cons

• Production pricing can be high for smaller teams
• More profiler-first than error/APM-first
• Less suited to broad observability needs
• May be more tool than a small team needs if they only want simple monitoring

Verdict

Blackfire is one of the best PHP profiling tools in the world.

As a PHP APM tool, it is strongest when your team wants to diagnose and prevent performance regressions in a disciplined way. It is less ideal if you want a simple, always-on SaaS APM with straightforward pricing.

4. New Relic

Best for: Enterprise APM across many languages and services.

New Relic is one of the oldest and most recognisable names in APM.

Its PHP agent supports modern PHP versions and common PHP frameworks. It gives you transaction traces, errors, dashboards, distributed tracing, service maps, logs in context, infrastructure correlation, and many of the workflows expected from a mature APM platform.

For larger teams, New Relic’s main strength is not PHP-specific depth. It is platform maturity.

If your organisation already uses New Relic for Java, Node.js, Go, Python, Kubernetes, browser monitoring, infrastructure, logs, and alerting, then adding PHP applications to the same platform can make sense.

How much of an APM is New Relic?

New Relic is absolutely a real APM.

But for PHP specifically, it is more of a broad APM platform with PHP support than a PHP-native profiler. It can tell you a lot about transactions, errors, databases, external calls, and service behaviour, but it is not as focused on PHP runtime-level profiling as Perfbase, Tideways, or Blackfire.

New Relic pros

• Mature APM product
• Broad language and platform support
• Good enterprise workflows
• Strong dashboards and alerting
• Useful distributed tracing
• Good fit for large organisations

New Relic cons

• Pricing can be harder to reason about
• Less PHP-native than specialist tools
• Can feel heavy for small PHP teams
• Not the best choice if your only problem is PHP code-level performance

Verdict

New Relic is a strong choice when PHP is one part of a larger engineering estate.

For PHP-only teams, it may be more platform than you need.

5. Datadog

Best for: Full-stack observability.

Datadog is one of the most complete observability platforms available.

It covers APM, infrastructure, logs, metrics, synthetics, real user monitoring, security monitoring, cloud cost visibility, database monitoring, incident workflows, and a huge integration ecosystem.

For PHP teams inside larger companies, Datadog can be extremely useful because it connects application traces to infrastructure, containers, databases, cloud services, logs, and alerts.

If your PHP application runs in Kubernetes, talks to Redis and MySQL, emits logs, depends on external APIs, and is part of a larger platform, Datadog can give you a joined-up view.

How much of an APM is Datadog?

Datadog is a real APM, but it is not PHP-native in the same way that Perfbase, Tideways, or Blackfire are.

It is better described as a full observability platform with PHP tracing support. It is excellent for seeing how systems interact. It is less focused on being a PHP runtime profiler.

Datadog pros

• Huge observability platform
• Strong infrastructure and service correlation
• Excellent integrations
• Good distributed tracing
• Useful for complex production environments
• Strong enterprise adoption

Datadog cons

• Pricing can grow quickly
• Can be too broad for PHP-only teams
• Requires careful setup to avoid noisy dashboards
• Less focused on PHP code-level performance than specialist tools

Verdict

Datadog is one of the best choices if your company wants one observability platform for everything.

It is not the most PHP-native option, but it may be the strongest platform option.

6. Sentry

Best for: Developer-first error monitoring with tracing and profiling.

Sentry started as error monitoring, but it has grown into a much broader developer observability platform.

For PHP teams, Sentry can now handle errors, performance monitoring, tracing, profiling, releases, issue ownership, and alerting. It is especially good when your developers want to move from “something broke” to “which release caused it?” quickly.

Sentry’s biggest advantage is workflow. It is one of the most developer-friendly tools on this list.

How much of an APM is Sentry?

Sentry is a real monitoring product, but it is still error-first and developer-workflow-first.

Its tracing and profiling features make it much more APM-like than it used to be, but it is not as deeply PHP-native as tools built specifically around PHP profiling.

For many teams, that is fine. If your biggest pain is errors, regressions, and slow endpoints tied to releases, Sentry can be a very good fit.

Sentry pros

• Excellent error tracking
• Strong developer workflow
• Useful tracing and profiling
• Good release correlation
• Friendly UI
• Works across many languages
• Can be self-hosted

Sentry cons

• Not as PHP-specific as Tideways, Perfbase, or Blackfire
• Usage-based pricing needs monitoring
• Less suitable as a full infrastructure observability suite
• Profiling depth may not satisfy teams that want full runtime-level PHP analysis

Verdict

Sentry is one of the best tools for product teams that care about errors and performance together.

It is not the deepest PHP APM, but it may be the most useful day-to-day debugging tool for many development teams.

7. Scout APM

Best for: Simple, developer-friendly PHP monitoring.

Scout APM is a lighter alternative to New Relic and Datadog.

It focuses on application performance, traces, slow database queries, N+1 query detection, memory bloat, errors, and developer-friendly views. It has good support for Laravel and Symfony, and is generally easier to adopt than a large observability platform.

Scout is particularly appealing if your team wants useful PHP performance monitoring without the weight, pricing complexity, or configuration overhead of a larger platform.

How much of an APM is Scout APM?

Scout is a real APM, and it has useful PHP-specific instrumentation.

It does not feel as deeply profiler-first as Blackfire, Tideways, or Perfbase, but it gives more practical PHP-level insight than many generic tools. For many Laravel and Symfony teams, that middle ground is attractive.

Scout APM pros

• Simple to understand
• Good Laravel and Symfony support
• Useful N+1 and memory bloat detection
• More approachable than large observability platforms
• Developer-friendly
• Clearer pricing than many competitors

Scout APM cons

• Less broad than Datadog or New Relic
• Less profiler-heavy than Perfbase, Tideways, or Blackfire
• Not ideal for huge multi-language observability estates
• PHP version and framework support should be checked against your stack

Verdict

Scout APM is a strong choice for PHP teams that want useful monitoring quickly.

It is not the deepest profiling tool, but it is practical, focused, and easier to adopt than many enterprise platforms.

8. Elastic APM

Best for: Teams already using Elastic, or teams that want self-hosted observability.

Elastic APM is part of the Elastic Stack. If your team already uses Elasticsearch, Kibana, Elastic Observability, or Elastic Cloud, then Elastic APM is a natural option.

It supports PHP through the Elastic APM PHP agent and can connect traces, logs, metrics, and service data inside the Elastic ecosystem.

Elastic’s biggest advantage is deployment flexibility. You can use Elastic Cloud, serverless options, or self-managed infrastructure depending on your requirements.

How much of an APM is Elastic APM?

Elastic APM is a real APM, especially when used as part of the wider Elastic Observability stack.

For PHP specifically, it is more of a general tracing/APM product than a PHP-native profiler. It is useful for service-level visibility, but less compelling if your main need is deep PHP function-level analysis.

Elastic APM pros

• Good option for Elastic users
• Self-managed option available
• Connects traces, logs, and metrics
• Flexible retention and deployment models
• Strong fit for teams with existing Elastic expertise

Elastic APM cons

• More operational work if self-hosted
• Less PHP-native than specialist tools
• Setup and data modelling can be more involved
• Not the simplest choice for small PHP teams

Verdict

Elastic APM is a good choice if you already use Elastic or want more control over your observability stack.

It is not the first tool I would choose purely for PHP code-level profiling.

9. Pinpoint

Best for: Open-source distributed tracing.

Pinpoint is an open-source APM and distributed tracing platform. PHP support exists through its C agent and related ecosystem packages.

The appeal is obvious: open-source, self-hosted, and not tied to SaaS pricing.

The trade-off is also obvious: you take on more operational responsibility. Documentation, polish, compatibility clarity, retention, and ease of use may not match commercial PHP-focused tools.

How much of an APM is Pinpoint?

Pinpoint is a real distributed tracing platform.

For PHP specifically, it is less polished and less obviously PHP-native than Perfbase, Tideways, Blackfire, or Scout. It is better suited to teams that have platform engineering capacity and want control over their tooling.

Pinpoint pros

• Open-source
• Self-hosted
• Distributed tracing focus
• No SaaS lock-in
• Flexible for teams willing to operate it

Pinpoint cons

• More operational burden
• PHP support is less productised
• Less transparent compatibility information
• Less polished than commercial tools
• Not ideal for teams that want quick onboarding

Verdict

Pinpoint can make sense for engineering-heavy teams that want open-source tracing.

Most PHP product teams will be better served by a commercial PHP-focused APM.

10. Instana

Best for: Existing IBM/Instana environments.

Instana is an enterprise observability platform now under IBM. It supports application monitoring across many technologies and can fit companies that already use IBM tooling or have standardised around Instana.

For PHP buyers, Instana is harder to recommend as a standalone first choice. Public PHP-specific detail is less compelling than New Relic, Datadog, Tideways, Blackfire, Scout, Sentry, or Perfbase.

Instana may still make sense if your organisation has already chosen it as the standard observability platform.

How much of an APM is Instana?

Instana is a real enterprise APM platform.

For PHP specifically, it is better thought of as a platform-level observability choice than a PHP-native performance tool. If you are buying specifically for PHP code-level insight, there are stronger options.

Instana pros

• Enterprise observability platform
• Useful in IBM-centric environments
• Suitable for large organisations
• OpenTelemetry direction may appeal to some teams

Instana cons

• Less PHP-specific public clarity
• Likely overkill for small PHP teams
• Not the strongest PHP-native profiler
• Usually requires a broader platform buying decision

Verdict

Instana is worth considering if your company already uses it.

It is not the obvious first choice for a PHP team independently choosing the best PHP APM tool.

General APM vs PHP-native APM

The biggest mistake teams make is comparing all APM tools as if they are the same category.

They are not.

There are two broad categories:

General observability platforms

These include:

• Datadog
• New Relic
• Elastic APM
• Instana

They are good at:

• Distributed tracing
• Infrastructure correlation
• Logs and metrics
• Multi-language environments
• Dashboards
• Alerting
• Governance
• Enterprise workflows

They are less good at:

• Deep PHP runtime-level profiling
• Explaining exactly which PHP method was expensive
• Showing PHP-specific framework internals in detail
• Giving small PHP teams simple pricing

PHP-native performance tools

These include:

• Perfbase
• Tideways
• Blackfire
• Scout APM, to a lesser extent

They are good at:

• PHP runtime visibility
• Framework-aware traces
• Flamegraphs
• Call trees
• Slow query diagnosis
• N+1 detection
• Memory and CPU analysis
• Code-level bottleneck discovery

They are less good at:

• Whole-company observability
• Infrastructure-wide dashboards
• Security monitoring
• Multi-language governance
• Centralised log analytics

Neither category is universally better.

But if your goal is to improve PHP performance, PHP-native tools usually get you to the answer faster.

Which PHP APM tool should you choose?

Choose Perfbase if…

Choose Perfbase if you want a modern PHP-native APM that focuses on runtime-level profiling, clear traces, flamegraphs, call trees, database query analysis, and simple pricing.

Perfbase is especially compelling if you are tired of generic dashboards that show symptoms but not causes.

Best for:

• PHP-first teams
• Laravel teams
• Symfony teams
• WordPress/CMS teams
• Agencies
• SaaS teams
• Teams that care about profiling
• Teams that dislike per-host or per-seat pricing

Choose Tideways if…

Choose Tideways if you want a mature PHP-native production monitoring tool with broad framework support and a long track record.

Best for:

• Established PHP businesses
• Ecommerce platforms
• Symfony/Laravel/Magento/Shopware/WordPress teams
• Teams that want production tracing with PHP context

Choose Blackfire if…

Choose Blackfire if you want deep profiling, performance testing, and optimisation workflows.

Best for:

• Performance-focused engineering teams
• Teams using CI/CD performance assertions
• Developers who want to compare profiles
• Organisations that treat performance as a discipline

Choose Datadog if…

Choose Datadog if PHP is only one part of a larger platform and you want one observability tool across infrastructure, logs, traces, security, cloud, and services.

Best for:

• Enterprises
• Platform teams
• Kubernetes-heavy environments
• Multi-language estates
• Teams with observability budgets

Choose New Relic if…

Choose New Relic if you want mature APM workflows and broad platform coverage, especially if your organisation already uses New Relic.

Best for:

• Mature engineering organisations
• Multi-service applications
• Teams that want established APM workflows
• Companies already invested in New Relic

Choose Sentry if…

Choose Sentry if errors, releases, tracing, and developer workflow are your biggest concerns.

Best for:

• Product teams
• SaaS teams
• Teams that care about issue triage
• Developers who want errors and performance together

Choose Scout APM if…

Choose Scout if you want a simpler PHP-friendly APM that is easier to adopt than a full observability platform.

Best for:

• Laravel teams
• Symfony teams
• Smaller engineering teams
• Teams wanting practical performance monitoring without complexity

Choose Elastic APM if…

Choose Elastic APM if you already use Elastic or want a self-managed observability stack.

Best for:

• Elastic users
• Teams with internal platform expertise
• Self-hosted observability
• Custom retention requirements

Choose Pinpoint if…

Choose Pinpoint if you specifically want open-source distributed tracing and are happy to operate the platform yourself.

Best for:

• Platform-heavy teams
• Open-source-first organisations
• Teams with internal observability expertise

Choose Instana if…

Choose Instana if your company already uses IBM/Instana or has standardised around it.

Best for:

• IBM-centric enterprises
• Existing Instana users
• Teams following a platform-level observability mandate

The best PHP APM tool overall

For PHP-specific performance work, the best options are:

1. Perfbase
2. Tideways
3. Blackfire
4. Scout APM

For broad observability, the best options are:

1. Datadog
2. New Relic
3. Elastic APM
4. Instana

For developer-first debugging, the best option is:

1. Sentry

The most important thing is to be honest about what you are buying.

A broad observability platform may give you a beautiful dashboard and still leave you guessing which PHP method caused the slowdown.

A PHP-native profiler may not replace your infrastructure monitoring, but it may solve your actual performance problem much faster.

If you are running a serious PHP application, you probably want runtime-level insight, not just emitted events.

That is why tools like Perfbase, Tideways, and Blackfire deserve special attention in any PHP APM comparison.

FAQ

What is the best PHP APM tool in 2026?

The best PHP APM tool depends on what you need.

For PHP-native performance profiling, Perfbase, Tideways, and Blackfire are the strongest options.

For broad enterprise observability, Datadog and New Relic are stronger.

For developer-first error monitoring with performance features, Sentry is an excellent choice.

What is the difference between APM and profiling?

APM tells you which transactions, services, endpoints, jobs, or dependencies are slow.

Profiling tells you what the code was doing inside that slow transaction.

For PHP teams, profiling is often the missing piece. A trace might tell you that /checkout took 900ms. A profile can show that 520ms was spent inside a specific method, ORM call, template render, or repeated database query.

Are all APM tools real profilers?

No.

Some APM tools are mostly based on traces, spans, metrics, logs, or emitted events. They can be useful, but they may not show function-level runtime behaviour.

If you want deep PHP performance insight, look for tools that support flamegraphs, call trees, runtime hooks, database query analysis, memory profiling, and CPU profiling.

Is Datadog good for PHP?

Yes, Datadog is good for PHP if you want PHP traces inside a wider observability platform.

It is especially useful if you also care about infrastructure, logs, containers, databases, security, and cloud services.

But if your main goal is PHP code-level profiling, a PHP-native tool may be a better fit.

Is New Relic good for PHP?

Yes. New Relic has mature PHP APM support and is a strong choice for larger teams.

However, it is a general APM platform rather than a PHP-specific profiler. It may be more than you need if you only want to diagnose PHP bottlenecks.

Is Sentry an APM tool?

Sentry is increasingly an APM-like platform, especially now that it combines error monitoring, tracing, profiling, releases, and issue workflow.

It is strongest for developer debugging rather than deep PHP runtime profiling.

Is Blackfire an APM or a profiler?

Blackfire is best understood as a profiler-first performance platform.

It includes monitoring and production features, but its biggest strength is deep profiling, performance comparison, and optimisation workflow.

What is the best APM for Laravel?

For Laravel, the strongest options are:

• Perfbase for PHP-native profiling and runtime-level insight
• Tideways for mature PHP production observability
• Blackfire for deep profiling and optimisation
• Scout APM for simple Laravel-friendly monitoring
• Sentry for errors, releases, tracing, and developer workflow
• Datadog or New Relic for broader platform observability

What is the best APM for Symfony?

For Symfony, consider:

• Perfbase
• Tideways
• Blackfire
• Scout APM
• Sentry
• Datadog
• New Relic

The right choice depends on whether you want deep PHP profiling or broad observability.

What is the best self-hosted PHP APM?

The strongest self-hosted options are Elastic APM, Pinpoint, and self-hosted Sentry.

However, self-hosting usually means more operational work. If your goal is simply to improve PHP performance, a hosted PHP-native tool may be faster to adopt.

Final recommendation

If you are choosing a PHP APM tool in 2026, do not start with the vendor logo.

Start with the depth of visibility.

Ask:

Does this tool actually understand what my PHP application is doing?

If the answer is “it mostly shows emitted spans and dashboard events”, that may be enough for service-level observability.

But if you want to fix real PHP performance problems, you need deeper runtime-level insight.

For that reason, PHP-first teams should start their shortlist with Perfbase, Tideways, and Blackfire.

Datadog and New Relic are excellent platforms, Sentry is excellent for developer workflow, Scout is a strong lightweight APM, and Elastic is a good self-hosted option.

But if the goal is to understand why PHP code is slow, the best tool is the one that can show what PHP actually executed.

TL;DR

• For 90% of new Laravel 12/13 apps, start with an official Starter Kit (React, Vue, Svelte, or Livewire) — they ship Laravel Fortify, Sanctum, and now first-party passkeys out of the box. Reach for Laravel Sanctum for SPA and mobile API auth, Laravel Passport only when you must be an OAuth2 provider, and Laravel Socialite for “Sign in with Google/GitHub/Apple.”
• Breeze and Jetstream are officially in maintenance-only mode — Laravel’s 12.x release notes state they “will no longer receive additional updates.” They still work, but new projects should adopt the new Starter Kits (which use Fortify under the hood).
• Passkeys are now first-party. The laravel/passkeys package (currently v0.2.1, released May 18, 2026) plus Fortify's Features::passkeys() makes WebAuthn a one-line install. Pair with spatie/laravel-permission for roles, and you have a complete, modern auth stack with zero third-party dependencies.

Key Findings

1. Laravel 12 (Feb 24, 2025) and Laravel 13 (released March 17, 2026, announced live by Taylor Otwell at Laracon EU 2026) reshaped the auth story. The old Breeze/Jetstream world has been replaced by stack-specific Starter Kits (React, Vue, Svelte, Livewire), and Laravel 13 brings native passkeys to Fortify and a redesigned Teams feature.
2. Sanctum is now the default API stack for new Laravel apps. Its cookie-based SPA flow is more secure than localStorage tokens, and its personal-access-token mode covers mobile clients and “API key” use cases.
3. Passport is no longer the default recommendation — it remains essential when you need a full OAuth2 server (i.e., when third parties need to log in with your app), but for first-party auth it’s overkill. Passport 13.x is now a headless OAuth2 library (its frontend views were removed and customization happens through Starter Kits).
4. Fortify is the engine, not the UI. Every official Starter Kit uses Laravel Fortify under the hood. If you have a fully custom frontend (Inertia, Nuxt, mobile shell) but want Laravel-grade auth backends — registration, password reset, 2FA, email verification, passkeys — Fortify is the right primitive.
5. The Laravel ecosystem has converged on a small, opinionated stack: Fortify (backend) + Sanctum (API/SPA tokens) + Socialite (OAuth clients) + Passkeys + Spatie Permission. You rarely need anything else.

Details: Every Laravel Authentication Option, Ranked and Explained

1. The New Laravel Starter Kits (React, Vue, Svelte, Livewire) — The Default in 2026

When you run laravel new my-app in 2026, you're prompted to pick a Starter Kit. There are four official options:

• React Starter Kit — Inertia 2, React 19, TypeScript, Tailwind, shadcn/ui
• Vue Starter Kit — Inertia 2, Vue 3, TypeScript, Tailwind, shadcn-vue
• Svelte Starter Kit — Inertia 2, Svelte 5, Tailwind, shadcn-svelte
• Livewire Starter Kit — Livewire 3, Volt, Tailwind, Flux UI

Per Laravel’s official docs: “The starter kits use Laravel Fortify to provide authentication.” That means under the hood you get registration, login, password reset, email verification, 2FA, and (as of 2026) passkeys — all wired up. Each kit can also be installed in a WorkOS variant that adds enterprise SSO, social, and Magic Auth. The Laravel 12 release notes explicitly state: “WorkOS offers free authentication for applications up to 1 million monthly active users.”

# Start a Laravel 13 project with the React Starter Kit
laravel new my-saas
# choose: React → Inertia 2 → SSR? → Pest/PHPUnit → Yes/No WorkOS
cd my-saas && composer dev

When to choose which kit?

• Building a SaaS dashboard? React or Vue with Inertia + SSR.
• Don’t want a JS toolchain? Livewire — write Blade + Volt, get reactivity, ship faster.
• Want server-rendered with the smallest bundle? Svelte.

Senior-dev opinion: The Starter Kits are now the canonical “Hello Laravel” entry point. If you find yourself fighting them (shadcn opinionated styles, Flux’s paid Pro tier), reach for Fortify directly rather than rolling your own.

2. Laravel Fortify — Headless Authentication Backend

Fortify is a frontend-agnostic auth backend. Per the official docs: “Laravel Fortify is a frontend agnostic authentication backend implementation for Laravel. Fortify registers the routes and controllers needed to implement all of Laravel’s authentication features.”

It’s what every Starter Kit uses internally. Install it directly when you want Laravel’s auth routes (login, register, password reset, email verification, 2FA, passkeys) but plan to ship your own UI — typically a Nuxt/Next/Astro frontend, a mobile shell, or a heavily customized Blade theme.

composer require laravel/fortify
php artisan vendor:publish --provider="Laravel\Fortify\FortifyServiceProvider"
php artisan migrate

Then in config/fortify.php, opt into the features you want:

'features' => [
    Features::registration(),
    Features::resetPasswords(),
    Features::emailVerification(),
    Features::updateProfileInformation(),
    Features::updatePasswords(),
    Features::twoFactorAuthentication(['confirm' => true, 'confirmPassword' => true]),
    Features::passkeys(['confirmPassword' => true]), // new in 2026
],

Fortify exposes endpoints like POST /login, POST /register, POST /user/two-factor-authentication, POST /passkeys/login. Your UI calls them. Done.

When to use Fortify over a Starter Kit: You’re building a mobile-first product where the “frontend” is React Native, Flutter, or an existing JS app you don’t want to refactor into Inertia.

3. Laravel Sanctum — SPA Auth & API Tokens, Lightweight

Sanctum solves two distinct problems:

1. Cookie-based, session authentication for first-party SPAs (Vue/React/Svelte/Nuxt living on the same top-level domain as your Laravel API).
2. Personal access tokens (“API keys”) for mobile apps and external integrations — GitHub-style.

It does not implement OAuth2. That’s deliberate — it’s lean and security-friendly. Per the docs: “Sanctum exists to offer a simple way to authenticate single page applications (SPAs) that need to communicate with a Laravel powered API… Sanctum does not use tokens of any kind. Instead, Sanctum uses Laravel’s built-in cookie based session authentication services. This provides the benefits of CSRF protection, session authentication, as well as protects against leakage of the authentication credentials via XSS.”

SPA setup (the part everyone gets wrong):

composer require laravel/sanctum
php artisan install:api   # Laravel 11+: scaffolds Sanctum + statefulApi()

// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->statefulApi();
})

APP_URL=https://api.example.com
SESSION_DOMAIN=.example.com
SANCTUM_STATEFUL_DOMAINS=app.example.com,localhost:3000
SESSION_SECURE_COOKIE=true
SESSION_SAME_SITE=lax

// config/cors.php
'paths' => ['api/*', 'sanctum/csrf-cookie', 'login', 'logout'],
'allowed_origins' => ['https://app.example.com'],
'supports_credentials' => true, // CRITICAL

// Frontend (axios) — get CSRF cookie, then log in
import axios from 'axios';
const api = axios.create({ baseURL: 'https://api.example.com', withCredentials: true });

await api.get('/sanctum/csrf-cookie');
await api.post('/login', { email, password });
const { data } = await api.get('/api/user'); // authenticated!

Mobile / API token mode:

$user = User::where('email', $request->email)->first();
$token = $user->createToken('iphone-15', ['read', 'write'])->plainTextToken;
return ['token' => $token]; // store in iOS Keychain / Android Keystore

Then on protected routes:

Route::middleware('auth:sanctum')->get('/api/profile', fn (Request $r) => $r->user());

Pitfall: SPA + Sanctum requires the SPA and API to share a top-level domain (subdomains are fine). If you’re cross-origin (e.g., frontend.vercel.app calling api.heroku.com), you'll either need to use token-based auth or proxy through the same domain.

4. Laravel Passport — Full OAuth2 Server (Only When You Really Need It)

Passport is a full OAuth2 server built on league/oauth2-server. It supports Authorization Code, Client Credentials, Password Grant (deprecated in OAuth 2.1 — avoid in new code), Implicit (also deprecated), and refresh tokens. As of 2026, Passport 13.x is now headless — per the upgrade notes: "Passport is now a headless OAuth2 library. If you would like a frontend implementation of Laravel Passport's OAuth features that are already completed for you, you should use an application starter kit."

The official guidance (paraphrased from the docs): use Passport if your application absolutely needs OAuth2 — i.e., other applications need a “Sign in with [Your App]” button. Otherwise, use Sanctum.

When you actually need Passport:

• You’re building a developer platform (Stripe, GitHub, Slack–style) where third-party apps integrate with user accounts.
• You need fine-grained scopes consumable by other OAuth2 clients.
• Machine-to-machine (Client Credentials grant) between microservices.
• OIDC / Single Sign-On where your Laravel app is the Identity Provider.

Setup:

composer require laravel/passport
php artisan migrate
php artisan passport:keys
php artisan passport:client --client   # client_credentials

// config/auth.php
'guards' => [
    'api' => ['driver' => 'passport', 'provider' => 'users'],
],

// User model
use Laravel\Passport\HasApiTokens;
class User extends Authenticatable { use HasApiTokens; }

Client Credentials grant (machine-to-machine):

curl -X POST https://api.example.com/oauth/token \
  -d "grant_type=client_credentials" \
  -d "client_id=$CID" \
  -d "client_secret=$CSECRET" \
  -d "scope=read-billing"

Senior-dev opinion: Passport is wonderful when you need it and a foot-cannon when you don’t. I’ve seen multiple teams adopt Passport for “API auth” only to migrate to Sanctum a year later because they never used a single OAuth2 flow. Default to Sanctum until OAuth2 is a hard requirement.

5. Laravel Socialite — OAuth Client (Social Login)

Socialite is the opposite of Passport: instead of being an OAuth provider, Socialite lets your Laravel app consume OAuth from external providers. Per the docs, it supports “Facebook, X, LinkedIn, Google, GitHub, GitLab, Bitbucket, and Slack” out of the box, with over 100 community adapters available at socialiteproviders.com (the SocialiteProviders GitHub organization hosts 296 repositories spanning Social/Platform, Gaming, and other provider categories, fetched May 21, 2026).

Google login example (the most common scenario):

composer require laravel/socialite

// config/services.php
'google' => [
    'client_id' => env('GOOGLE_CLIENT_ID'),
    'client_secret' => env('GOOGLE_CLIENT_SECRET'),
    'redirect' => env('GOOGLE_REDIRECT_URL'),
],

// routes/web.php
use Laravel\Socialite\Facades\Socialite;

Route::get('/auth/google',  fn () => Socialite::driver('google')->redirect());
Route::get('/auth/google/callback', function () {
    $g = Socialite::driver('google')->user();
    $user = User::updateOrCreate(
        ['email' => $g->email],
        ['name' => $g->name, 'google_id' => $g->id, 'avatar' => $g->avatar]
    );
    Auth::login($user, remember: true);
    return redirect('/dashboard');
});

Migration columns to remember: provider_name, provider_id, provider_token (encrypted), provider_refresh_token (encrypted) — and make password nullable so users who only auth via Google don't need one.

Pitfall: Don’t try to store the provider token without encryption. Add it to $casts as encrypted and to $hidden.

6. Laravel Breeze — Still Works, But Officially in Maintenance

Breeze was the friendly minimal scaffold: it published plain controllers into app/Http/Controllers/Auth and gave you Blade/Livewire/Inertia (Vue or React) flavors. Compared to Jetstream, "Breeze publishes controllers you edit directly. Jetstream hides auth logic behind Fortify."

Status in 2026: Laravel 12 release notes explicitly state: “With the introduction of our new application starter kits, Laravel Breeze and Laravel Jetstream will no longer receive additional updates.” It still works in Laravel 12 and is patched for compatibility — Breeze is at v2.4.2 (released May 14, 2026, per Packagist) — but it’s not getting new features.

composer require laravel/breeze --dev
php artisan breeze:install blade   # or vue, react, livewire, api
npm install && npm run dev
php artisan migrate

When to still use Breeze: Legacy projects on Laravel 11 or earlier. New tutorials and courses where “everything is a plain controller” makes pedagogy easier. If you want Blade with no JS toolchain and minimal opinion, Breeze (Blade stack) still wins on simplicity.

7. Laravel Jetstream — Deprecated, But Still Compatible with Laravel 12

Jetstream went further than Breeze: 2FA, team management, browser session monitoring, profile photos, API token management UI. It used Fortify under the hood and shipped Livewire or Inertia-Vue stacks.

Status in 2026: Same deprecation notice as Breeze — no new features. Jetstream is at v5.5.3 (released May 19, 2026, per Packagist), still compatible with Laravel 12, but the team management feature is being replaced in the new Laravel 13 Starter Kits. Povilas Korop summarized the Laracon EU 2026 announcement: “The old starter kit Jetstream had a functionality of Teams, so the new starter kits will get it back, but implemented a bit differently.”

Senior-dev opinion: Don’t start a new project on Jetstream in 2026. If you need teams, wait for or use the Laravel 13 Teams implementation, or roll your own using Spatie Permission + a teams table. If you have a Jetstream project in production: it's fine. Don't rush to migrate.

8. Built-In Auth Scaffolding (Guards, Providers, Middleware, the Auth Facade)

Underneath everything — Breeze, Jetstream, Fortify, Sanctum, Passport, Socialite — sits Laravel’s core authentication machinery: guards (how a user is authenticated for a request), providers (how to retrieve users), and middleware (auth, auth:sanctum, auth:api, verified, password.confirm).

For a tiny app, you can skip every package and write this yourself:

// routes/web.php
Route::post('/login', function (Request $r) {
    $credentials = $r->validate(['email' => 'required|email', 'password' => 'required']);
    if (Auth::attempt($credentials, $r->boolean('remember'))) {
        $r->session()->regenerate();
        return redirect()->intended('/dashboard');
    }
    throw ValidationException::withMessages(['email' => 'Invalid credentials']);
});

Route::middleware('auth')->get('/dashboard', fn () => view('dashboard'));

That’s a complete login system in 10 lines. There’s no shame in this for admin tools, internal dashboards, or content-light sites.

9. Laravel Passkeys — First-Party Passwordless Auth (New in 2026)

This is the headline auth feature of 2026. Laravel released a first-party WebAuthn/passkeys package in late April 2026 — laravel/passkeys v0.1.0 was published on Packagist on April 22, 2026, and has since advanced to v0.2.1 (released May 18, 2026) — with a companion @laravel/passkeys npm client. In a May 12, 2026 Laravel News article titled "Laravel Introduces First-Party Passkey Authentication Support," Eric L. Barnes wrote: "Laravel has introduced native passkey authentication support through new first-party packages… Laravel Fortify integrates the stack behind Features::passkeys() and a passkeys section in config/fortify.php, so Fortify apps get the same endpoints and contracts (PasskeyUser, PasskeyAuthenticatable) without reimplementing glue."

Setup:

composer require laravel/passkeys
php artisan vendor:publish --tag=passkeys-migrations
php artisan migrate

// app/Models/User.php
use Laravel\Passkeys\Contracts\PasskeyUser;
use Laravel\Passkeys\PasskeyAuthenticatable;

class User extends Authenticatable implements PasskeyUser
{
    use PasskeyAuthenticatable;
}

// Frontend (Vue example)
import { usePasskeyVerify, usePasskeyRegister } from '@laravel/passkeys/vue';

const { verify } = usePasskeyVerify({ autofill: true,
    onSuccess: r => router.visit(r.redirect ?? '/dashboard') });
const { register } = usePasskeyRegister();

<input type="text" autocomplete="email webauthn" />
<button @click="verify">Sign in with passkey</button>
<button @click="register('My MacBook')">Add a passkey</button>

The package fires events you can hook into, supports multiple passkeys per user, and integrates with Fortify’s password-confirm middleware. HTTPS is required — WebAuthn refuses to run on http://, including on 127.0.0.1 (use localhost or Valet's valet secure).

Alternative: If your app is heavily Livewire-based and you already have spatie/laravel-passkeys working, you don't need to migrate — it ships ready-made Livewire components. But don't run both packages simultaneously; their routes overlap.

10. Spatie laravel-permission — The De Facto Roles & Permissions Package

Authentication ≠ Authorization, and the moment you have more than one type of user, you need a role/permission system. The community-standard package is spatie/laravel-permission — at v7.4.1 (released April 29, 2026) with 96,199,540 Packagist installs and 12,873 GitHub stars (per Packagist, fetched May 21, 2026).

composer require spatie/laravel-permission
php artisan vendor:publish --provider="Spatie\Permission\PermissionServiceProvider"
php artisan migrate

// app/Models/User.php
use Spatie\Permission\Traits\HasRoles;
class User extends Authenticatable { use HasRoles; }

// Seeder
Permission::create(['name' => 'edit articles']);
Role::create(['name' => 'editor'])->givePermissionTo('edit articles');

// Usage
$user->assignRole('editor');
$user->can('edit articles');     // true
@can('edit articles') ... @endcan
Route::get('/admin', ...)->middleware('role:admin');

It plugs into Laravel’s Gate, supports multiple guards, teams (multi-tenancy), and integrates cleanly with Policies.

11. Filament Authentication — For Admin Panels

If you’re building an admin panel with Filament v4, authentication is built-in and now includes native multi-factor authentication: TOTP apps (Google Authenticator, 1Password) and email codes. Recovery codes are supported. You activate it in your panel provider:

use Filament\Auth\MultiFactor\App\AppAuthentication;

public function panel(Panel $panel): Panel
{
    return $panel
        ->profile()
        ->multiFactorAuthentication([
            AppAuthentication::make()->recoverable(),
        ]);
}

For passkeys + 2FA combined in a Filament panel, the popular community plugin is stephenjude/filament-two-factor-authentication, which adds a fluent API for enabling Google 2FA, passkey login, and forced setup.

12. WebAuthn Community Packages (Pre-Native Passkeys Era)

Before laravel/passkeys shipped, the community filled the gap with:

• spatie/laravel-passkeys — Livewire-first, very ergonomic.
• laragear/webauthn — Lower-level, supports password fallback, EdDSA keys, blacklisting.
• livewirez/webauthn-laravel — Lightweight, no framework opinion.

These are still maintained and valid, but for new projects, the first-party laravel/passkeys package is the right choice unless you have a specific reason to use a community option (e.g., heavy Livewire UI investment).

Comparison Table: Which Laravel Auth Package for Which Use Case?

Decision Tree: “Which Laravel Auth Should I Pick for X?”

• Traditional Blade monolith / server-rendered app, single login form? → Laravel core auth + (optionally) the Livewire Starter Kit. Add Socialite if you need “Sign in with Google.”
• SaaS with Inertia (Vue/React/Svelte) SPA + Laravel API on the same domain? → New Starter Kit + Sanctum cookie mode (it’s already wired in). Add spatie/laravel-permission for roles.
• Mobile app + Laravel API? → Sanctum personal access tokens. If you also have a web SPA, you can run both modes simultaneously.
• Cross-domain frontend (Vercel/Netlify SPA → separate API host)? → Sanctum API tokens (not cookies — cookies require same top-level domain). Or proxy through your own domain.
• You want third-party developers to “Sign in with My App” — i.e., you ARE the identity provider? → Laravel Passport.
• Machine-to-machine API between your own microservices? → Passport Client Credentials grant, OR pre-shared Sanctum tokens for simpler cases.
• SaaS with teams (multi-tenancy)? → Laravel 13 Starter Kit (Teams returned) OR Spatie Permission’s team features OR stancl/tenancy. Avoid starting new Jetstream projects.
• Need social login (Google/GitHub/Apple/Facebook)? → Laravel Socialite. For Apple, LinkedIn-OIDC, or many others, also check socialiteproviders.com for community drivers.
• Need passkeys / passwordless? → laravel/passkeys + Fortify's Features::passkeys(). Heavy Livewire app? spatie/laravel-passkeys is still excellent.
• Need an admin panel with 2FA? → Filament v4 + native MFA. Or Filament + stephenjude/filament-two-factor-authentication plugin for passkeys too.
• Enterprise SSO (SAML, OIDC, SCIM)? → WorkOS-powered Starter Kit variant (free for up to 1M monthly active users, per Laravel 12 release notes). Or build it yourself on top of Passport’s OAuth2 + custom SAML adapter.

Security Best Practices (Briefly)

1. Never store tokens in localStorage for SPA auth. Use Sanctum's cookie mode or, if you must use tokens, store them in httpOnly cookies set server-side.
2. Always rotate sessions on login ($request->session()->regenerate()).
3. Hash passwords with bcrypt or argon2id. Laravel does this by default; don’t override it.
4. Use HTTPS in production. Passkeys won’t work without it. Set SESSION_SECURE_COOKIE=true.
5. Enable 2FA for privileged accounts. Fortify makes this a one-liner.
6. Encrypt OAuth provider tokens at rest. Use 'encrypted' casts on your provider_token column.
7. Set sensible token expirations. For Sanctum: SANCTUM_TOKEN_EXPIRATION=43200 (30 days). For Passport access tokens: shorter (15 min) + refresh tokens.
8. Rate-limit auth endpoints. Laravel’s throttle middleware is sufficient: Route::middleware(['throttle:login'])->post('/login', ...).
9. Keep a password fallback when you adopt passkeys — not every user device supports them, and account recovery still needs a path.
10. Audit logins. Listen to Illuminate\Auth\Events\Login, Failed, Logout events and log them.

Common Pitfalls (And How to Avoid Them)

• Sanctum SPA returning 419 / CSRF token mismatch? Your frontend isn’t calling GET /sanctum/csrf-cookie first, or your SESSION_DOMAIN is wrong, or supports_credentials isn't true in CORS.
• Sanctum SPA returning 401 with cookies set? Your SANCTUM_STATEFUL_DOMAINS doesn't match — only include hostname + port, no scheme, no trailing slash.
• Passport “personal access client not found”? Run php artisan passport:install (or passport:client --personal after a fresh migrate).
• Socialite always returning the same user? You’re not handling the provider_id carefully — match users on both email AND provider, or you'll merge accounts unexpectedly.
• Passkeys silently failing in dev? WebAuthn refuses non-HTTPS. Use valet secure, Herd's HTTPS toggle, or localhost exactly (not 127.0.0.1).
• Adopted Jetstream a year ago, now blocked on missing features? Don’t migrate; extend. The Fortify under-the-hood pattern lets you add nearly anything by overriding Actions.

FAQ: Laravel Authentication in 2026

Q: What is the best Laravel authentication package in 2026? A: For 90% of new projects: a new Starter Kit (React, Vue, Svelte, or Livewire) — they bundle Fortify, Sanctum, and now passkeys. For headless or mobile-first: Fortify directly. For OAuth2 server: Passport. Don’t start new projects on Breeze or Jetstream.

Q: Is Laravel Breeze deprecated in 2026? A: Not “deprecated” in the strict sense, but the Laravel 12 release notes state: “Laravel Breeze and Laravel Jetstream will no longer receive additional updates.” They still work and receive compatibility patches (Breeze v2.4.2 was released May 14, 2026), but the new Starter Kits are the future.

Q: Sanctum vs Passport — which should I use? A: Sanctum unless you need to be an OAuth2 provider. Passport is overkill for first-party SPAs and mobile apps and adds significant complexity (clients, keys, scopes, grants). Use Passport only when third parties need to log in via your app, or when you specifically need OAuth2’s Client Credentials grant for machine-to-machine auth.

Q: How do I add authentication to a Laravel API for a mobile app? A: Use Sanctum’s personal access tokens. After login, return a token with $user->createToken('device-name')->plainTextToken, store it in the device's secure storage, and send it as Authorization: Bearer {token} on every request.

Q: Does Laravel support passkeys / WebAuthn natively? A: Yes, as of April 2026. The first-party laravel/passkeys package (currently v0.2.1) plus Fortify's Features::passkeys() provides full WebAuthn support. New Laravel Starter Kits (v5.28.0+ installer) include it by default.

Q: How do I add Google login to Laravel? A: Install Laravel Socialite (composer require laravel/socialite), add Google credentials to config/services.php, and create two routes — one for redirect, one for callback. See the code example above.

Q: Do I need Laravel Fortify if I’m using a Starter Kit? A: No — the Starter Kits already use Fortify under the hood. You install Fortify directly only if you’re building a fully custom frontend (mobile, separate Nuxt/Next app, etc.) and want Laravel’s auth backend without any view scaffolding.

Q: Can I use both Sanctum and Passport in the same app? A: Yes, by configuring separate guards. Common pattern: Sanctum for your own SPA + mobile, Passport for third-party developer APIs. It’s complex to maintain — only do this if you genuinely need both.

Q: What’s the best Laravel authorization (roles & permissions) package? A: spatie/laravel-permission — over 96 million Packagist installs as of May 2026, multi-guard support, team/multi-tenant support, integrates with Laravel Gate.

Q: Should I use Jetstream’s team feature for SaaS in 2026? A: Not for new projects — Jetstream is in maintenance. Wait for or use the Laravel 13 Starter Kits’ Teams feature (announced at Laracon EU 2026), or roll your own teams table with Spatie Permission’s team support.

Q: Is the WorkOS variant of the Starter Kits worth using? A: If you need enterprise SSO, SAML, SCIM, or want a hosted auth UI for free up to 1 million monthly active users — yes. If you want everything self-hosted with zero third-party dependencies — stick with the standard Starter Kit + Fortify + Socialite + passkeys.

Q: How do I implement 2FA in Laravel? A: It’s built into Fortify. Enable Features::twoFactorAuthentication() in config/fortify.php, add the TwoFactorAuthenticatable trait to your User model, and the Starter Kits already render the QR code and recovery codes UI. For Filament admin panels, Filament v4 has native MFA.

Recommendations

Starting a brand-new Laravel 12 or 13 project today?

1. laravel new and pick a Starter Kit matched to your team's frontend skill (Livewire for PHP teams, React/Vue/Svelte for JS teams).
2. Accept the default Fortify + Sanctum + (optionally) passkeys stack.
3. Add spatie/laravel-permission on day one — even if you "only have admins and users today," you'll need it eventually.
4. Add Socialite the moment you need a “Sign in with Google” button — it’s a 30-minute install.
5. Don’t reach for Passport unless and until you have a specific OAuth2-server requirement.

Modernizing a Breeze/Jetstream app in 2026?

• Don’t panic — both still work and are patched for Laravel 12 compatibility.
• If you’re staying on Breeze/Jetstream: pin versions, lock Composer, and treat them as part of your application code.
• If you’re migrating: pick a new Starter Kit that matches your existing frontend stack, scaffold a fresh project, and port your business logic over. Don’t try to “upgrade in place” — the structure is different enough that a fresh scaffold is faster.

Building a mobile-first API?

• Fortify + Sanctum tokens. Skip the Starter Kits entirely; ship a Postman collection as your “frontend.”

Building an enterprise B2B SaaS?

• Starter Kit (WorkOS variant) + Spatie Permission (team mode) + passkeys + enforced 2FA for admin roles.

Thresholds that should change your decision:

• If your app needs to be an OAuth2 provider → switch to Passport.
• If you have more than five distinct authentication flows (admin, customer, partner API, mobile app, public API, etc.) → consider a dedicated identity provider (WorkOS, Keycloak self-hosted, or roll your own with Passport).
• If you serve regulated industries (healthcare, finance) → force 2FA, prefer passkeys, audit-log every auth event, and consider hardware security keys via WebAuthn attestation.

Caveats

• Laravel 13 was released on March 17, 2026, and the Teams + native passkeys features in the new Starter Kits are still maturing. The laravel/passkeys package is at v0.2.1 — its public API may still evolve before 1.0. For mission-critical production passkeys today, pin your version explicitly.
• Install counts and version numbers in this article were captured from Packagist on May 21, 2026 and are point-in-time snapshots.
• Some sources cited in this article are vendor blogs and individual developer write-ups; where possible I’ve cross-referenced against official Laravel documentation and Laravel News (Eric L. Barnes’s reporting in particular).
• The Laravel ecosystem moves fast. Even within 2026, expect Starter Kit features (especially Teams, which is brand new) to evolve. Always check the official docs for breaking changes before upgrading.
• No silver bullets. “Auth0/Clerk/WorkOS vs first-party Laravel” is a real trade-off I deliberately skipped here — this article focuses on Laravel-native options. Managed services can save engineering time but introduce vendor lock-in and recurring cost. Pick the trade-off that matches your team and product.

If this guide saved you from a 419 PAGE EXPIRED headache or a needless Passport install, give it a clap and share it with the Laravel dev who keeps asking "Sanctum or Passport?" in your team Slack. Happy authenticating.