Installing Payload CMS Blocks Wired, Not Pasted

Chai Pin Zheng — Wed, 24 Jun 2026 09:26:04 +0000

When you build with Payload CMS and Next.js, reusable blocks are easy to imagine but annoying to distribute cleanly.

A block is rarely just one component file. It usually needs a Payload block config, a frontend renderer, a collection registration, a renderer map entry, regenerated Payload types, and an updated admin import map. Copying the files is the easy part. Remembering the wiring every time is where projects drift.

That is the problem Payload Components is trying to solve.

Payload Components is an MIT registry and CLI for Payload v3 + Next.js blocks. The tagline is:

Install Payload CMS blocks wired, not pasted.

The basic flow looks like this:

npx payload-components add hero-basic

A plain shadcn add copies files into your project. payload-components add copies the block source too, but it also performs the Payload-specific setup: it registers the block in the collection, maps the renderer, regenerates types and the admin import map, records install state, and leaves the result as a normal reviewable git diff.

Why copying files is not enough

Payload blocks touch both editor schema and frontend rendering. If a registry only copies a component file, the install still leaves work behind:

import the block config
register the block in the right collection
import the frontend renderer
add the renderer to the block map
regenerate Payload types
regenerate the admin import map

Those steps are small, but they repeat in every project. They are also easy to get slightly wrong when components evolve.

What the CLI does

The CLI treats each block as source code you own. It builds the registry item, installs files through the shadcn-compatible path, applies the supported Payload wiring, runs the post-install generation steps, and records install state so reruns converge instead of duplicating setup.

The result is deliberately boring: a git diff you can review, edit, and keep.

Current status

The project is open source and MIT licensed. The catalog is intentionally small while the install contract is hardened around Payload v3 + Next.js projects shaped like the official website starter.

Links:

Site: https://www.payload-components.xyz
GitHub: https://github.com/Ducksss/payload-components
Docs: https://www.payload-components.xyz/docs
Catalog: https://www.payload-components.xyz/components

Feedback from Payload and Next.js teams would be useful, especially around repo shapes the installer should support next and which block families should be added first.

Stop copying Codex auth files: use CODEX_HOME profiles instead

Chai Pin Zheng — Thu, 07 May 2026 02:48:40 +0000

If you use Codex with more than one account, repo context, or local setup, the usual workaround gets old quickly: copy one auth.json somewhere safe, swap it back later, and hope you did not overwrite the wrong state.

I wanted something boring and explicit, so I made codex-profiles: a small open-source helper that launches Codex CLI or Codex Desktop with a named CODEX_HOME.

GitHub: https://github.com/Ducksss/codex-profiles

The problem

Codex keeps useful local state under CODEX_HOME: auth, config, sessions, plugins, logs, and other local files. That is convenient for one identity, but awkward when you want clean separation between:

work and personal accounts
experimental and stable config
different plugin sets
repo-specific sessions
short-lived test logins

You can script around it manually, but copying auth files is a brittle workflow.

The workflow

Install with Homebrew:

brew install Ducksss/tap/codex-profile

Create or log into a profile:

codex-profile login work

Run Codex CLI using that profile:

codex-profile cli work exec "review this repo"

Open Codex Desktop with a separate local profile:

codex-profile app personal

Each profile maps to its own CODEX_HOME, so the local Codex state stays isolated without moving files around by hand.

Why this shape

The tool is intentionally small. It does not try to wrap the entire Codex workflow or invent a new config model. It just makes the boundary explicit:

CODEX_HOME=<profile-directory> codex ...

That means the underlying Codex behavior stays familiar, while profile switching becomes a repeatable command.

What it is useful for

keeping work and personal Codex auth separate
testing new Codex config without touching your main setup
keeping separate plugin/session state per context
launching Desktop or CLI against the same named profile
avoiding accidental auth.json swaps

Try it

brew install Ducksss/tap/codex-profile
codex-profile login work
codex-profile cli work exec "summarize this repo"

The project is open source and dependency-light. Feedback from other Codex users would be useful, especially around naming, install friction, and profile workflows I have missed.

Repo: https://github.com/Ducksss/codex-profiles

DEV Community: Chai Pin Zheng