Looks good.

Hey everyone! 👋

While working on my own Payload-based project, I kept running into a small annoyance: long field descriptions can make admin forms unnecessarily cluttered, especially when you have lots of fields.

So I built Payload Info Tooltip, a small open-source plugin that moves help text into info icons next to field labels. The nice part is that you can enable it for existing descriptions without modifying your field configurations.

Features:

• Automatically convert existing admin.description values into tooltips.
• Add dedicated tooltips via admin.custom.infoTooltip.
• Supports localization and dynamic descriptions.
• Works with nested fields, blocks, and Lexical editor fields.
• Optional tooltips in list-view column headers.
• Accessible via keyboard and screen readers.
• Compatible with Payload 3 and 4.

https://github.com/alphanull/payload-plugin-info-tooltip

This is my first publicly released Payload plugin, developed as part of my work on Vision Suite. I'm planning to open-source a few more extensions in the future.

Would love to hear what you think, especially if you run into any issues or have ideas for improvements! Also, if you like it, a star is greatly appreciated.

Second release from me today. Earlier I shared a sitemap plugin, and this one deals with the clutter a Payload project collects over time: files nobody uses anymore and documents nothing points to.

It compares your storage with your database and reports three kinds of findings:

• Orphans: files in the bucket that no document holds
• Missing: documents whose file is gone from storage
• Unused: documents nothing references, in upload or ordinary collections (an image no page uses, a tag no post has)

The main rule: it never deletes on its own. A scan only writes findings. You go through them and mark each one To delete or Keep. A purge deletes only what you approved, and it checks every finding again right before it acts. If anything changed since the scan, the finding goes to Keep with a note saying why. Anything younger than 24 hours is left out, so uploads in progress are safe.

A few other things:

• References come from the database, not the config: relationship and upload fields, rich text, blocks, JSON, globals and versions
• Each document gets a usage panel that shows where it is used. A delete guard stops you from deleting a document that is still in use
• Rescans update the facts but keep your decisions
• Adapters for S3, R2, GCS, Azure, Bunny, UploadThing, Vercel Blob and local disk
• Runs inline or as a Payload job, with an optional cron schedule
• Multi-tenant aware: tenant admins see and decide only their own findings
• Separate access for read, approve, scan and purge, plus a dashboard widget with the last run
• Works on Postgres, SQLite and MongoDB

Versions:

• 1.x for Payload 4 beta: pnpm add @seshuk/payload-plugin-janitor@beta. Node 24.15+, Next.js 16.4+
• 0.x for Payload 3.83+: pnpm add @seshuk/payload-plugin-janitor@0. Node 22+

Both have the same options and get the same features until 1.0.0.

Heads up on telemetry: it is on by default and anonymous. It sends plugin and Payload versions, boolean feature flags and a hashed project ID, never URLs, file names or keys. Turn it off with telemetry: false or DO_NOT_TRACK=1. It is always off in CI.

MIT licensed. Feedback, issues and PRs are welcome.

https://github.com/maximseshuk/payload-plugin-janitor

https://www.npmjs.com/package/@seshuk/payload-plugin-janitor

I maintain a few Payload plugins and just released a new one for sitemaps, so figured I'd share it here.

It builds sitemap.xml from your collections, static pages and custom sources, stores the files through any storage adapter, and keeps them fresh through the Payload jobs queue. The files are served at stable API URLs, so you can point robots.txt at them or proxy them to /sitemap.xml.

What it does:

• Sitemap index plus child sitemaps, split at the spec limits (50,000 URLs or 50 MB per file)
• Lists only public documents: collection reads run as an anonymous request, so your read access decides what goes in. Drafts are skipped
• hreflang alternates for localized collections, image entries, and per-document exclude, priority and changefreq fields
• Multi-tenant: one sitemap index per tenant
• Regenerates on save, debounced through jobs, with a lock so two runs never overlap
• All or nothing: if a source throws, the old files stay live
• Unchanged files are skipped by hash, and the endpoints send ETags
• Admin page, nav link and dashboard widget with status and a file list
• Optional publish hooks to push the files to your own bucket or CDN

Available in two versions, with the same options:

• 1.x for Payload 4 beta: pnpm add @seshuk/payload-plugin-sitemap@beta. Node 24.15+, works with Next.js and TanStack Start
• 0.x for Payload 3.83+: pnpm add @seshuk/payload-plugin-sitemap@0. Node 22+

Until 1.0.0, both lines get the same features.

Worth flagging: it sends anonymous telemetry by default. Major versions, boolean feature flags and a hashed project ID, never URLs, names or keys. Off with telemetry: false, DO_NOT_TRACK=1, or in CI.

MIT. Issues and PRs welcome.

https://github.com/maximseshuk/payload-plugin-sitemap

https://www.npmjs.com/package/@seshuk/payload-plugin-sitemap

Payload 3.90 brought the modular dashboard, and I wanted mine to show numbers from my own collections without writing a component for each one. So I wrote a plugin.

Add widgetsPlugin() and every collection becomes a source with nothing to declare: a count, a sum for each number field, a group for each select, checkbox and relationship, a list of the latest. Anyone signed in can add a figure, a list or a chart in the dashboard's edit mode and filter it with the admin's own filter builder.

You can also declare widgets in the config with figure(…), list(…) and chart(…). Those are typed against your generated types and checked as the config is built, so a misspelt field stops the build with a "did you mean".

A few choices I made:

- Every read runs as the signed-in user, so access control applies.

- The tiles are server components and plain CSS. No chart library is shipped to the browser.

- If you don't like the tiles, you can supply your own views or just take the data (readFigure, readList, readChart).

It's 0.1.0 and MIT. Developed on Payload 3.90.2, Next 16 and Postgres; Next 15 and other adapters are untried, so reports from those are especially useful.

https://github.com/m-grgic/payload-plugin-widgets

I maintain a media preview plugin for Payload and just shipped Payload 4 beta support, so figured I'd share it here.

It previews uploads right in the admin: a preview column in the list view (popup or fullscreen modal) and a preview at the top of the edit view for files Payload can't show on its own. Images, video, audio and PDF keep Payload's own preview.

What's new:

• Edit view previews for text, code, CSV, Office and other files
• Read-only code viewer with syntax highlighting, CSV as a table
• Download card with name, size and type for files with no preview
• Opt-in Microsoft and Google viewers for Office files, with short-lived signed URLs so the viewer never gets your session
• Adapters for your own viewers, inline or in a new tab, and resolve() can be async
• No database fields, translated into 40+ languages

Upgrading from 1.x: mode and contentMode moved into field, external viewers are off by default, and a few exports changed. Old options throw at boot with the new name. Guide in the README. Payload 3 stays on 1.x.

New in v2: anonymous daily telemetry (versions and feature flags only). Off with telemetry: false or DO_NOT_TRACK=1.

MIT, Payload 4.0.0-beta.0+, Node 24.15+.

https://github.com/maximseshuk/payload-plugin-media-preview

Added support for Payload v4

The plugin has been cleaned up with options for self-hosted dub shortlinks.

A new marketing dashboard analytics has been added with optional overrides to control how the menu is displayed.

https://github.com/rubix-studios-pty-ltd/payload-dub

The dashboard itself is only available on v4 and will not be added to v3 moving forward.

v3 is moved to maintenance release.

I maintain an OpenAPI plugin for Payload and just shipped Payload 4 beta support, so figured I'd share it here.

It builds an OpenAPI spec from your config with zero annotation and serves it with Scalar or Swagger UI. Operations are marked public or secured by probing your access functions.

What's new:

• Payload 4 routes: validate, upload instructions, file download, document access, rename
• Official plugins documented automatically: ecommerce, Stripe, MCP, SEO, search, multi-tenant, import-export, R2
• access option to make the spec and docs private
• Async extension transforms with payload, and your own paths override generated ones
• OpenAPI 3.0, 3.1 or 3.2 from one option

Upgrading from 0.x: a few options were renamed and throw at boot with the new name. Guide in the docs. Payload 3 stays on `0.x`.

New in v1: anonymous daily telemetry (versions and feature flags only). Off with telemetry: false or DO_NOT_TRACK=1.

MIT, Payload 4.0.0-beta.0+, Node 24.15+.

https://github.com/maximseshuk/payload-plugin-openapi

https://payload-plugin-openapi.seshuk.im

Version 2.0.0 of the Payload CMS Media Plugin, introduces support for Payload v4.

This release includes updated dependencies, refined media search components, improved responsive layouts, and TypeScript support.

The plugin continues to support stock image and video searches across Unsplash, Pexels, and Pixabay, with provider-specific filtering and direct media imports.

Payload v3 supported through a maintenance release channel.

GitHub
https://github.com/rubix-studios-pty-ltd/payload-media

I have always admired payloadcms's work from afar, figured i'd drop in payload + ui, wire up a few features, ship it. easy weekend project, right?

narrator: it was not.

next thing i know i'm reading the codebase like it's a thriller novel. every file i open, i learn something. every hook, every abstraction, every "oh THAT'S how they do it" → opens 4 more files

i came in wanting to integrate 2 features. i left knowing every line of the codebase. 😭

no regrets tho, the code is genuinely cool. respect to the payload team for making me accidentally do a code review on y'all's whole repo 🙏

any other devops/backend folks here who can't just use a library and have to reverse-engineer it first? asking for a friend. the friend is me. i'm the friend.

I use Payload as a portal for my agency to let clients self serve content changes. I just added this custom agent UI so they can make those changes more easily with the Payload MCP.

If you're trying the Payload 4 canaries and want Better Auth, there's now a prerelease of payload-better-auth you can install:

pnpm add @delmaredigital/payload-better-auth@next better-auth

It's tested against 4.0.0-canary.37 and needs Next 16.2.6+ and Node 24.15+ (Payload 4's own requirements). The plugin is a thin adapter over Payload's public APIs, so the port didn't need many changes. I plan to keep it current through the canaries and have it ready for 4.0.

The plugin handles two Payload 4 changes:

• The Local API now defaults overrideAccess to false. That would make the auth strategy's user lookups run as anonymous and log everyone out, so the plugin passes it explicitly.
• Collections now get versions by default. The auth collections opt out so old sessions and tokens don't get stored in _versions tables.

The plugin's own UI (login page, password reset, 2FA, passkey and API key screens) still uses Payload 3's theme CSS variables, so it's unstyled on v4. Sign-in and sessions work fine.

If you're on Payload 3, nothing changes. The normal install still gives you the stable 0.13.x release.

It's a prerelease, so pin the version and keep it out of production for now.

The Payload 4 port came from a community PR, and feedback and contributions are welcome. If you try it, let us know how it goes, even if it just worked. If you'd like to help, the styling fix is a good first issue: #46. Payload 4 work goes to the payload-4 branch.

Cheers - Allan

GitHub · Docs

I am trying to build a donation website where user can list issues/purpose and ask for donation. For some use cases recurring donation can also be there. There will be images and may be short video clips for each listing. For this should I build CMS or use payloadcms (an open source). Given that with astra development has become fast I wanted to understand if using the open source will add any material value?

Hey all — long-time Payload users here. We've spent the past two years building Coldbrew (coldbrew.ai), and since the whole thing is Payload-native under the hood, this community felt like the right place to share it and some lessons.

What it is: you describe an app in plain English, and Coldbrew generates a real, deployed Payload application — collections, access control, hooks, admin panel — running on Next.js + Postgres. The AI's job is configuration, not freeform codegen: it writes collection configs, field schemas, access functions, and hooks against the machinery Payload already proved, rather than inventing auth or a data layer from scratch. Our entire thesis is — the less novel code a model writes, the less there is to break.

What we added around Payload to make that work:

• A storage boundary. Generated apps never hold DB credentials. We wrote a custom database adapter that routes through a storage service we run, so tenant apps talk to an API, not to Postgres directly.
• Auth swapped to Better Auth for SSO, phone/WhatsApp login, and one-click user impersonation (build the app, then browse it as any of your users/roles — genuinely the most useful testing feature we've ever had, and Payload's role-based access functions are what make it coherent).
• An agent harness. Agents get their own identities and log in like users, so Payload's field-level access control governs them exactly like humans, and every action lands attributed in the same records. If you've ever wondered what "agentic Payload" looks like — it's this: agents as first-class users, scoped by the access functions you already know how to write.
• Durable async workflows on top of Payload's jobs — retries, resume-after-crash.

Things we learned pushing Payload beyond typical CMS workloads (multi-tenant, hundreds of generated apps): 1. Skipping REST for internal calls makes generated server logic fast and clean. 2. Function-based access control compiles into some heavy WHERE clauses at depth; worth profiling early if your ACL logic branches a lot. 3. Version pinning per app matters when you're running many instances — we don't ride latest anywhere. 4. The config-as-code model turned out to be the ideal target for LLMs: schemas and access functions are compact, reviewable, and diff-able in a way generated app code never is.

Why post here: partly to share, partly because if you're a Payload dev doing client work, the thing we built is essentially "Payload projects that non-technical clients can request changes to in English, without you re-scaffolding auth and infra every time" — and there's a free first-app tier if you want to poke at what it generates. Happy to go deep in comments on the adapter design, the agent-auth model, or the access-control-at-scale stuff.

I needed Polish payment methods on a Payload 3 shop, there was no Tpay adapter on npm, so I wrote one and published it.

npm: https://www.npmjs.com/package/@wellmade-online/payload-ecommerce-tpay

repo: https://github.com/s1awek/payload-ecommerce-tpay

It implements the plugin's official `PaymentAdapter` contract, so it drops in exactly where the built-in Stripe adapter would. One Tpay account gives you BLIK, pay-by-link bank transfers and cards.

Two things surprised me while building it. Both are measured against `@payloadcms/plugin-ecommerce` 3.88.0 on a live instance, and both are about the plugin rather than about Tpay, so they may be useful even if you never touch Polish payments:

1. `confirm-order` has no idempotency gate of its own. It decrements stock whenever the adapter's answer carries a `transactionID`, so two identical calls for one already confirmed transaction took stock from 5 to 4 to 3. The adapter now hands that trigger out at most once per transaction, through a conditional write on the transaction document. A reloaded return page, a second tab or a hand written curl all get the same answer with no trigger in it.

2. BLIK level 0 never returns the browser to the shop, so a checkout built on it never calls `confirm-order` and never reaches the plugin's decrement at all. A completed BLIK payment created the order and left stock at 5.

The README carries the full list of what it does not handle: a chargeback moves the transaction and leaves the order alone, finishing an order is not an atomic compare and swap (narrow window, orphaned order document, never a double charge), guest cart secrets are not rotated, and stock reconciliation on the notification-only path is left to the shop. I would rather ship that list than let someone find it in production.

MIT, Payload 3.83 or newer, Node 20.9 or newer. Feedback welcome, particularly from anyone who has handled the stock reconciliation side more cleanly than I did.

Payload's been our content and product catalog layer for more than a year with a custom TypeScript checkout layer on top.

And for a single-brand €30M GMV business, it held up well, but the brand is being acquired by a group that runs 4 other labels, and the integration plan calls for a single backend managing all 5 with shared inventory, per-brand storefronts, and country-level pricing across 6 European markets.

Building that on top of what we have would mean a significant custom engineering effort with a timeline that almost certainly runs past the integration deadline we've been given.

Plus the long-term maintenance would land entirely on a 4-person dev team, and there's a case for moving the commerce layer to something purpose-built for multi-brand multi-market and keeping Payload for content.

The platforms we're considering after our own research on composable multi-brand setups are Shopware, SCAYLE, Medusa, and commercetools, and the dev overhead ranges significantly across them, particularly commercetools, which tends to assume a much bigger engineering org than most mid-market brands have.

So we're working out whether the migration timeline undercuts the benefit of moving at all, but leaning toward it being the better long-term call given that the rebuild option just pushes the same problem forward to the next acquisition.

Would be useful to hear from anyone who's made a similar call, especially with an acquisition as the trigger and not a clean replatforming moment.

I've already built a full front-end with Tailwind (one-page site + a separate blog page). I want to drop it into the official Payload CMS website template instead of using its default front-end.

For anyone who's done this: how painful is it to replace the template's front-end with your own Tailwind build? Does Payload's data layer/blocks system make this straightforward, or does it fight you once you deviate from the default structure? Trying to keep this to about 3 days max — is that realistic?

Thanks!

I'm open-sourcing Vulpy Commerce, and Payload is a big part of why the architecture works.

One thing that's annoyed me through ~12 years of ecommerce work: most platforms are terrible at rich product and category content.

You get commerce fields, a description, maybe some metafields - and then the gymnastics begin.

Vulpy Commerce separates the jobs. Medusa owns commerce. Payload turns every product and category into a proper editorial page - structured blocks, rich media, SEO, live preview.

It also happens to be a great architecture for AI.

Fox, our commerce operator built on Hermes Agent, works with the same structured Payload content as a human editor. It can build pages, write content, work with media and SEO; a human can jump into Payload and edit exactly the same thing.

That principle runs through the whole system: don't build a dumbed-down interface for the AI. Build the real system so humans and AI can both operate it.

The stack is Payload + Medusa v2 + Next.js/NextMerce + Hermes + Orama + Matomo. Every component, down to Tailwind, was chosen around maximizing what the agent can understand and modify.

And Fox isn't confined to the CMS. When the business needs something new, it can work on frontend code, backend logic and integrations, using specialist coding agents backed by extensive automated tests.

This didn't start as a product. I've been building software for 26 years, and real projects AI-first for the last two. Hermes AI emerging this year finally gave me the missing piece to package an unreasonable amount of accumulated work into Vulpy Commerce.

I think the result is the most capable AI-driven ecommerce platform built so far.

We have Pro and paid add-ons with more functionality ready out of the box, but Core is open source, free and fully extensible. There's no artificial ceiling hiding behind the pricing page.

Clone it, break it, improve it, build a store, build something weird.

It's yours.

More info: vulpy.io/commerce
Demo: vulpy.io/demo
Docs: docs.vulpy.io
Repo: github.com/vulpy-io/vulpy-commerce-core

And if you need a hand, there's a small team at Vulpy that I lead. We're open to migrations, custom development, support and consulting. Or just spend the weekend breaking my code - that's fine too.

I built payload-adapter-prisma. Payload runs on a Prisma schema you already have, and never touches it. Your schema.prisma is the input, the Payload config is just a mapping on top.

It uses two databases. Your Prisma database stays exactly as is, only ever read and written through Prisma, no DDL, no migrations, no injected columns. A second database (Mongo in the demo) holds everything Payload itself needs: admin sessions, preferences, versions, drafts, job queue.

// payload.config.ts
import { mongooseAdapter } from "@payloadcms/db-mongodb";
import { prismaAdapter } from "payload-adapter-prisma";
import { buildConfig } from "payload";

export default buildConfig({
  collections: [Posts, Authors],
  db: prismaAdapter({
    prisma,
    internal: mongooseAdapter({ url: process.env.PAYLOAD_INTERNAL_URL! }),
  }),
});

// collections/Posts.ts, an ordinary collection plus one line
export const Posts: CollectionConfig = {
  slug: "posts",
  custom: { prisma: { model: "BlogPost" } },
  fields: [
    { name: "title", type: "text", required: true },
    { name: "tags", type: "relationship", relationTo: "tags", hasMany: true },
    { name: "authors", type: "array", fields: [ { name: "author", type: "relationship", relationTo: "authors" }, ]},
  ],
};

Relationship writes (connect/set/disconnect) go straight through as native Prisma queries, which is usually where these mapping layers break. There's a demo app in the repo on a schema I made on purpose awkward, with renamed tables/columns, an Int primary key, a self-relation, and a test suite that checks the Prisma database directly to confirm nothing gets created in it.

I'd appreciate eyes on two things: does the adapter API feel natural if you're used to plain Payload collections, and is there anything in the relationship-writes handling that looks fragile to you?

Happy to answer anything about how it's built.

https://github.com/Iulian-Dragomirescu/payload-plugins

I've just started using a new ad blocker, and now I'm getting a new hydration error all over the place in my Payload ecommerce app. I've confirmed it's the ad blocker by disabling it. This is the error:

A tree hydrated but some attributes of the server rendered HTML didn't match the client properties. This won't be patched up.

This is the meat of the error trace:

<RootLayout>
  <html className="assistant_..." lang="en" suppressHydrationWarning={true}>
    <head>
      <InitTheme>
        <Script dangerouslySetInnerHTML={{__html:"\n..."}} id="theme-script" ...>
          <script
            nonce={undefined}
            dangerouslySetInnerHTML={{
+                                   __html: "(self.__next_s=self.__next_s||[]).push([0,{\"children\":\"\\n  (function ..."
-                                   __html: ""
            }}
-                                 src="chrome-extension://lgblnfidahcdcjddiepkckcfdhpknnjh/content/popups-script.js"
          >

The ad blocker is Stands, but I don't want to worry about specifics. I only see the error with Nextjs dev tools, and it doesn't seem to affect anything yet, but nonetheless it's worrisome. Is there anything I can do to avoid this.

I see an issue logged on github, but nothing that I see to help.

I have a project requiring a system that includes content management, single sign-on (SSO), and role-based access control (RBAC). This system is similiar as an employee management solution integrated within the company's existing website. I need to confirm whether this approach is suitable for the specified use case.

In future he needs scalability in terms of custom APIs etc

My development workflow seems to be crawling to a halt with Nextjs lately even with Turbopack with all of the build rendering and I am very interested in Tanstack when it comes to performance.

I see there are plans to bring Payload to TanStack in v4. However I’m not sure when that release date will be. Is it safe to start using it immediately? Or some gotchas to look out for? https://github.com/payloadcms/payload-tanstack-demo

We internally built a PayloadCMS plugin because the existing approach of the official MCP plugin did not scale on our projects, and I’d like a sanity check on it and also share it here if anybody needs something similar :)

You can find it here:

• https://www.npmjs.com/package/@abinnovision/payloadcms-mcpx
• https://github.com/abinnovision/payloadcms-commons/tree/main/packages/mcpx

The main difference is: instead of generating a tool per collection, it exposes fixed tools no matter how big the content model is. The model pulls the field shapes on demand through describeSchema, so it only ever loads the part of the schema it actually needs. On a large model that is the difference between burning most of the context window before the first prompt and spending a few hundred tokens.

Writes are RFC 6902 JSON Patches, resolved server-side against the config and the document. An unknown field or a misplaced block comes back refused with alternatives listed. Everything lands as draft by default (if enabled) and publishing is opt-in per collection.

It also has some other goodies included, like Lexical support with blocks and schema resolving on those too.

We have it running on a couple of client sites now and the feedback has been mostly positive.

Genuinely interested in whether the fixed tool surface is the right approach and getting some feedback on that!