I refreshed this guide in October 2026 because the Payload plugin ecosystem has changed materially since the first version. Payload now ships a substantial official plugin set covering SEO, redirects, search, multi-tenancy, MCP, ecommerce, Stripe and Sentry, which removes a lot of custom work that used to be unavoidable.
The first place I look on any project is that official set, because maintenance and compatibility matter more than the length of a feature list. Community plugins become valuable around authentication, AI workflows, editorial experience and specialist functionality.
What follows is my current shortlist of plugins I would consider for production Payload projects, with the limitations that matter before adopting each one. Versions referenced were checked against Payload 3.90.2.
What counts as a plugin
Plugin does not mean every optional Payload package. Four different things get lumped together under that word, and separating them makes the rest of the decisions easier.
Category
Meaning
Examples
Official plugins
First-party extensions maintained with Payload
SEO, Search, Multi-Tenant, MCP, Ecommerce
Community plugins
Third-party extensions to Payload capabilities
Auth integrations, AI tooling, admin enhancements
Adapters
Infrastructure integrations that connect Payload to a service
S3, Azure, GCS, Vercel Blob storage
Custom extensions
Functionality you implement through hooks, components, collections or endpoints
Approvals, governance, specialised workflows
Storage adapters such as @payloadcms/storage-s3, @payloadcms/storage-vercel-blob, @payloadcms/storage-gcs and @payloadcms/storage-azure are infrastructure choices that follow from where you host. They are not ranked below, because they do not compete with application plugins for a place in your architecture.
Decision table
This table is the short version. Each row is expanded in the sections below. "My take" is a judgement about trust, and the maintenance column shows the date of the latest release or commit I could verify, because star counts say little about whether a package will keep up with Payload.
Plugin
Category
Use it for
My take
Maintenance
@payloadcms/plugin-seo
Official
Meta fields, auto-generation, search preview
Default choice
Released with Payload
@payloadcms/plugin-redirects
Official
CMS-managed redirect records
Default choice
Released with Payload
@payloadcms/plugin-search
Official
Synced search collection
Strong option
Released with Payload
@payloadcms/plugin-multi-tenant
Official
Tenant field, scoping, admin filtering
Strong option, needs architecture around it
Released with Payload
@payloadcms/plugin-import-export
Official
Editor-driven CSV and JSON operations
Project-dependent
Released with Payload
@payloadcms/plugin-form-builder
Official
Admin-built forms and submissions
Project-dependent
Released with Payload
@payloadcms/plugin-mcp
Official
MCP endpoint for AI clients
Strong option
Released with Payload
@payloadcms/plugin-ecommerce
Official
Commerce primitives, currently Beta
Evaluate carefully
Released with Payload
@payloadcms/plugin-stripe
Official
Stripe sync, webhooks, REST proxy
Project-dependent
Released with Payload
@payloadcms/plugin-sentry
Official
Error and performance monitoring
Strong option
Released with Payload
payload-auth
Community
Better Auth for admin and app
Strong option
v3.0.0, Aug 2026
payload-authjs
Community
Auth.js sessions
Evaluate carefully
May 2026
payload-auth-plugin
Community
OAuth and SSO provider logins
Project-dependent
May 2026
payload-oauth2
Community
Generic OAuth2 login
Specialist
May 2026
payload-totp
Community
TOTP two-factor for admins
Specialist
Oct 2026
@ai-stack/payloadcms
Community
AI generation in the admin
Project-dependent
Sep 2026
payload-oapi
Community
OpenAPI spec generation
Specialist
Oct 2026
payload-lexical-typography
Community
Typography controls in Lexical
Specialist
Nov 2025
@matija2209/payload-plugin-admin-feedback
Community (mine)
In-context client feedback
Specialist
v1.0.4, May 2026
Official Payload plugins I would start with
The official plugins live in the Payload monorepo and are versioned with Payload itself. For the packages in this section, the payload peer dependency is pinned to the exact release, which removes the compatibility lag that causes most plugin upgrade problems. That is why I treat them as the baseline and look for gaps in them before reaching for anything else.
SEO
@payloadcms/plugin-seo adds a meta field group with title, description and image to the collections you choose. Editors can auto-generate those values through generateTitle and generateDescription functions you write, and a search result preview renders under the fields and updates as they type.
I would use it on any content-driven website. It handles the CMS metadata layer only. The frontend still owns rendering that metadata correctly, which means wiring generateMetadata in Next.js, canonical URLs, Open Graph tags and structured data. If you run several sites from one install, multi-tenant SEO with Payload and Next.js covers where per-site metadata logic goes. I trust this plugin as infrastructure.
Redirects
@payloadcms/plugin-redirects adds a redirects collection with from and to fields, where to can point at a document reference. The plugin manages redirect records in the admin panel and the database. It does not perform the redirect. Your frontend queries the collection and issues the HTTP redirect, which is the part teams forget when they install it.
This deserves its own place in a plugin stack because redirects carry real SEO weight during migrations and slug changes, and editors should be able to fix a broken URL without a deploy. Redirect coverage belongs in every migration plan, and the Payload CMS migration service page describes how it fits the wider process. The multi-tenant case needs extra thought, since the same path can mean different pages on different sites, which I cover in Payload redirects across tenants and locales. I would use this plugin by default and trust it as infrastructure.
The sibling package @payloadcms/plugin-nested-docs handles parent and child page hierarchies with generated breadcrumbs. It is a good fit for page trees, and the nested docs breadcrumbs guide covers the tenant-aware version.
Search
@payloadcms/plugin-search creates a separate search collection and keeps a static copy of selected fields from your other collections in sync through hooks. You query it with the normal Payload APIs and sort by a priority value you control per collection or per document.
I would use it for ordinary CMS search over controlled, indexed content: a site search bar, a docs search, a blog index. It stops where search becomes its own product. Large catalogues, complex ranking, typo tolerance and faceting are the cases where Algolia, Meilisearch or similar infrastructure earns its cost. For shared indexes across sites, see the Payload multi-tenant search guide. It is a strong option with a clear boundary.
Multi-Tenant
@payloadcms/plugin-multi-tenant is the official tenant foundation. It adds a tenant field to the collections you list, a tenant selector in the admin panel, filtering of list views and relationship fields by the selected tenant, automatic tenant assignment for new documents, and rejection of writes that assign a tenant the user does not belong to. It can also treat a collection as a per-tenant global, with one document per tenant.
That is the foundation. A production multi-site system needs a lot more around it, and I have built that surrounding layer for a single Payload installation serving several brands. A tenant field does not decide who can edit which brand, how departments split access within a brand, who may publish and who may only draft, how content on one site references content on another, how the frontend learns which site a request belongs to, or where brand-specific configuration lives. Roles, site memberships, departmental permissions, publishing gates and frontend site context are all your design work. The plugin also deletes related documents by default when a tenant is deleted (cleanupAfterTenantDelete), so access control on the tenants collection deserves careful thought.
@payloadcms/plugin-import-export adds CSV and JSON export through the admin UI, with import back into a collection, a preview step before either operation, and jobs-queue processing for large runs. The queue needs a configured runner (jobs.autoRun), otherwise imports and exports sit in a pending state.
I would use it for editor-controlled operations: bulk field updates, structured exports for a client, recurring data fixes. Application migration is a separate problem. On a project with hundreds of normalised products carrying relationships, localized fields and media, an editor-driven CSV import is the wrong tool, and a deliberate ETL pipeline with validation, ordering and idempotent re-runs is the right one. I describe that route in building a CSV product import system with Payload queues. Project-dependent, and trusted for what it is designed to do.
Form Builder
@payloadcms/plugin-form-builder lets editors build forms in the admin panel, store submissions in the database, send emails on submission and show a confirmation message or redirect. You render the form on the frontend with your own components.
It replaces external form tooling for contact forms, lead forms, surveys and editable landing page forms. It does not cover custom workflows such as routing a lead into a CRM, multi-step logic tied to your data model, or automation after submission. Those need custom collections, hooks or an external system, and the Payload and n8n integration patterns show one way to connect them. Project-dependent.
MCP
@payloadcms/plugin-mcp turns a Payload instance into an MCP server. After mcpPlugin({}) is added to the plugins array, POST /api/mcp accepts MCP requests, and every collection and global is reachable through generic tools such as getConfigInfo, getCollectionSchema and findDocuments.
This is more than an AI plugin. It makes Payload an interface that agents can interact with programmatically while the CMS stays the controlled content and permissions layer. The pieces that matter for production:
Capability
What it gives you
Tools
Built-in discovery and CRUD tools, plus custom tools defined with defineTool
Resources and prompts
Custom resources and prompts you expose to clients
Operation restrictions
Per-collection control over which operations are enabled
Access control
API keys with per-key capabilities, code-level access callbacks, and normal Payload access rules still protecting documents
Response shaping
overrideResponse to sanitise what a model receives
I would use it where an organisation wants structured content to be reachable by agents, which ties into the wider work of making content infrastructure AI-ready. The plugin handles the protocol and the permission hooks. You still design which operations an agent should have, how sensitive fields are filtered, and how to authenticate remote clients. My security-first Payload MCP integration guide documents a production setup, including a slug case-sensitivity failure I hit along the way. Strong option, and trusted as infrastructure as long as you restrict operations deliberately.
Ecommerce
@payloadcms/plugin-ecommerce provides commerce primitives: products with variants, carts tracked in Payload, orders, transactions, addresses linked to customers, multiple currencies, React utilities for frontend logic and a payments adapter pattern with Stripe supported today. It is currently marked Beta in the Payload documentation, so breaking changes are possible between releases.
The plugin does not handle shipping, taxes or subscriptions natively, and it is not a Shopify replacement. Production commerce needs decisions on shipping rules, tax calculation, fulfilment, subscriptions, inventory and integrations with the systems around the shop. My walkthrough of the ecommerce plugin with Stripe, carts and orders covers the build, and the ecommerce plugin compared with Medusa covers when each fits. For budgeting a shop on Payload, the Payload CMS pricing guide breaks down the variables. Evaluate carefully, and pin versions while it is Beta.
Stripe
@payloadcms/plugin-stripe solves Stripe-specific integration problems. It syncs Payload collections with Stripe resources such as customers and products, stores a read-only stripeID for cross-reference, handles webhooks for events like customer.subscription.updated, and proxies the Stripe REST API through Payload access control at /api/stripe/rest with an explicit method allowlist.
The ecommerce plugin supplies commerce-domain primitives. The Stripe plugin supplies Stripe synchronisation. They complement each other: the ecommerce plugin's Stripe adapter covers taking payments, and the Stripe plugin is useful when you also need customers or subscriptions mirrored between systems. Because the ecommerce plugin does not do subscriptions natively, that mirroring is often where subscription logic starts. Project-dependent.
Sentry
@payloadcms/plugin-sentry connects Payload to Sentry for exception visibility, performance monitoring and stack traces with context. It requires Sentry's Next.js setup first, and by default it captures errors with a 500 or higher status, with captureErrors for adding more codes. I would install it on every production project. It is infrastructure for debugging and reliability, and its presence in the official list shows how far the ecosystem extends beyond editorial features.
Community plugins I would actually shortlist
This is a curated shortlist organised by problem. It is not a catalogue. I checked each package's Payload peer dependency and latest activity on npm and GitHub in October 2026.
Authentication
Authentication architecture depends on who owns authentication. Payload may own it for the admin and a small set of users. The wider Next.js application may share it with Payload. An external identity provider may sit in front of both. No single plugin wins across those cases, and the comparison of Payload auth plugins works through the decision in detail.
Approach
Plugin
When I would consider it
Better Auth shared by admin and app
payload-auth
Greenfield projects wanting one auth system across the admin and the application
Auth.js sessions
payload-authjs
Existing Auth.js applications, with the caveat below
OAuth and SSO provider logins
payload-auth-plugin
Provider-based login and enterprise-style SSO, with protocol coverage documented at authsmith.com
Generic OAuth2
payload-oauth2
Google, GitHub or another standard provider without a larger auth layer
Stronger admin authentication
payload-totp
TOTP second factor for admin-heavy applications
On payload-authjs, its own README warns that Auth.js v5 is still in beta and that Auth.js is now part of Better Auth, so its long-term path is uncertain. That is the reason I mark it "evaluate carefully" and lean toward payload-auth for new builds. Payload's native auth is often enough, and the cookie auth with Next.js guide shows the architecture without a third-party layer.
AI and localization
I only shortlist AI plugins where the workflow is concrete and measurable in editor time saved. @ai-stack/payloadcms (the payload-ai repository) adds text, image and voice generation, and translation inside the admin panel, supporting several providers. It fits teams that publish a lot of content or work across languages and want drafting help without leaving Payload. Budget for provider costs and keep a human review step before publishing.
For translation of localized fields at scale, a plugin button runs into the same limits as any synchronous request. Long translation runs belong in background jobs, which I describe in automating Payload translations with OpenAI and job queues.
Admin and editorial experience
These are workflow improvements and not core architecture dependencies, so I add them last and remove them without much pain.
Payload already has a native capability for in-context editing. Before adding any visual editing package, check whether Live Preview covers the need. The Live Preview implementation guide shows the setup with no extra dependency, and the Payload CMS demos show it running. The payload-visual-editor package still appears in searches, but its peer dependency targets Payload 2 (^2.0.13) and its last release was in March 2024, so I do not recommend it for a Payload 3 project.
payload-lexical-typography adds font, size, line height and colour controls to the Lexical editor. It is useful when editors need more inline styling than the default editor offers. It declares peer dependencies on the Lexical and UI packages (^3.43.0) and none on payload itself, so test it against the exact Payload version you run. Its latest release is from November 2025, so I treat it as a specialist option. The payload-bites repository is a collection of small packages such as soft delete, activity log, audit fields, content freeze and a broken link checker. It is worth scanning before you write a utility by hand, and each package deserves the same vetting as any other dependency. For custom admin work that no plugin covers, the guide to custom admin fields and views shows the native route.
Developer tooling
payload-oapi generates OpenAPI 3.0 and 3.1 specifications from a Payload instance and includes Swagger UI and Rapidoc. I would use it when a Payload project is an integration surface for other teams or third parties, and a generated contract replaces hand-written endpoint documentation. It was updated in October 2026 and supports Payload ^3.0.0.
My own plugin: admin feedback
I built @matija2209/payload-plugin-admin-feedback because of a recurring problem on client projects. Client QA and feedback arrives as screenshots in Slack, vague descriptions and messages with no route context, and someone has to reconstruct which page and which element the comment meant.
The plugin keeps the feedback inside the application. A floating widget captures the message, the current page path, an optional CSS selector, and a screenshot that can be annotated with pen, rectangle, arrow and text tools. Each submission creates a record in an admin-feedback collection and sends an email notification through the Payload email adapter you already use, with a direct admin link. It works in the Payload admin and on selected Next.js frontend routes.
I do not position it as an ecosystem standard. It is at v1.0.4, it requires Payload ^3.84.1, and it is a specialist tool. I include it as a firsthand example of when writing a plugin makes sense: a repeated problem, a clear boundary, and behaviour that several projects can share. It also uses definePlugin, so it doubles as a real example of the API described later in this guide.
payload-plugin-admin-feedback header
When I would not install a plugin
A plugin is a dependency, and it also adds extension points and config changes that your project inherits. I usually avoid a plugin when:
the required behaviour is only a small hook you could write in a few lines
the plugin alters important collection behaviour in ways the team does not understand
maintenance activity is weak
its peer dependencies lag behind Payload releases
the project needs substantially different behaviour anyway
the feature is part of the project's core business logic
Complex approvals and publishing governance are the clearest example. They tend to become business-specific quickly: who reviews what, which content types need two approvers, what happens when a reviewer is on holiday, how a publish gate differs between brands. Explicit collections, hooks and access rules are easier to reason about than a generic workflow plugin bent to fit. A Payload CMS audit is a good point to check whether a plugin has ended up carrying business logic it should not.
How I evaluate a community Payload plugin
I run the same checklist on every community package before it enters a project. GitHub stars are a useful discovery signal and carry no weight in the decision.
Check
What I look for
Payload peer dependency
A range that includes the Payload version I run, and a history of following Payload releases
Latest release and commits
Activity in the last few months, and releases that match the commit history
Open issues
Whether the maintainer responds, and whether reported breakages get fixed
Test coverage
Tests that exercise the plugin against a real Payload instance
Documentation
Setup, options, and known limitations written down
TypeScript quality
Typed options and exported types without casts
Config mutation
How many collections, fields, endpoints and admin components the plugin changes
Introduced collections and fields
Which ones appear in my schema and database
Registered hooks
Which hooks run on my collections, and when
Migration implications
What database migrations installation and upgrades require
Removal
How hard it is to take the plugin out later, including the data it created
The last three often decide the outcome. A plugin that registers hooks on collections you rely on, adds tables, and cannot be removed without losing data is a much larger commitment than its install command suggests.
How Payload plugins work in 2026
The mental model is unchanged: a plugin is a function that receives the incoming config and returns a modified config. Payload's documentation describes that contract as stable, and it can add collections, fields, hooks, endpoints and admin components. This is the plain form:
Plugins run in array order by default, and they transform the config before Payload sanitises and initialises it. Hooks a plugin registers run later, during operations, which is a separate phase.
Diagram
Config transformation happens once at startup. The hooks a plugin adds execute later at runtime.
Payload also documents an advanced API, currently marked experimental, built around definePlugin. It adds a slug, an execution order (lower values run first, default 0), typed options, and a plugins map that lets one plugin find another and adjust its options before it runs.
Plugin packages can augment the RegisteredPlugins interface so the plugins map is typed for consumers. Because the API is experimental, I use it for published plugins and accept that its surface may shift. The full workflow, including packaging and publishing, is in building publishable Payload plugins with definePlugin.
For admin UI, the server and client split matters. Components are referenced from the config by path and resolved through the import map, so client components belong in their own exported entry point with 'use client' at the top, while server components and config logic stay on the server side of the package. Mixing them is a common source of build errors in plugin packages.
How to discover more plugins
Payload does not run a marketplace. The official plugin list lives in the Payload plugin documentation, and community plugins are discoverable through the payload-plugin GitHub topic and npm. The documentation itself says plugins change quickly, so check back often.
Discovery is the first step only. A plugin appearing in a topic list or a package search does not make it production-ready. For anything that will sit deep in your architecture, read the source: look at what it adds to the config, which hooks it registers and what it writes to the database.
The hierarchy I follow
Start with the official plugins. Use community packages where they solve a defined problem and show credible maintenance signals. Keep core business workflows in code you control when their behaviour is specific to the business.
The ecosystem is increasingly useful because you no longer need to rebuild every common capability yourself. Payload's underlying extension model still gives you an escape hatch when the plugin abstraction stops fitting.
If you are evaluating Payload for a production CMS, a multi-site platform or a migration, I help teams design and build the architecture around it. See how I work as a Payload CMS developer. If you are still deciding on the CMS itself, the CMS picker tool gives a quick recommendation, and the Payload CMS cost estimator helps size the budget.
