# Elements ships full-stack shadcn/ui blocks instead of isolated components

> Elements is a shadcn registry of production-ready blocks for Next.js and TypeScript, grouped by the service they integrate with: 154 brand logos, Clerk auth flows, AI chat and tool-call pieces for the Vercel AI SDK, Polar pricing, UploadThing uploads, Upstash rate limiting and GitHub widgets, plus a theme switcher and loaders. It is MIT licensed and installs with a single shadcn command.

**crafter-station/elements** — Full-stack shadcn/ui blocks for auth, payments, AI, logos, and more

- Repository: https://github.com/crafter-station/elements
- Website: https://www.tryelements.dev/
- Stars: 526 · Forks: 29
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/crafter-station-elements

## What a block is, and how it gets into your project

Elements is described as full-stack shadcn/ui blocks for auth, payments, AI, logos, and more, built for Next.js, TypeScript, and the agentic era.

The word full-stack is the important qualifier. A shadcn component is a single UI primitive you compose into a form; a block here is a whole working feature, including the server side, the service integration and the configuration. The listing makes that concrete: the Clerk category covers sign-in, sign-up, an org switcher and a waitlist, the Polar category covers sponsorship badges, pricing cards and licence keys, and the UploadThing category is file upload with drag and drop and progress.

Installation goes through the shadcn CLI, and the three examples in the readme are the whole story:

```bash
npx shadcn@latest add @elements/clerk-sign-in
npx shadcn@latest add @elements/logos
npx shadcn@latest add @elements/polar-pricing-card
```

That is the shadcn model applied to blocks: the code is copied into your repository rather than installed as a dependency, so you own it and can edit it. The readme notes that Elements is a trusted shadcn registry, and that no manual config is needed, which points at the one thing that usually goes wrong with registry items, namely the component.json and tailwind wiring.

The repository is a Next.js application, with next.config.ts, middleware.ts, vercel.json, components.json and an app in src/. The dev script is unusual though: portless elements next dev, which suggests a tool that starts the Next dev server and hands the port over automatically, and the package manager is Bun at 1.2.2 with a bun.lock at the root.

The primary language is TypeScript, the licence is MIT, the last push was on 2026-08-14, and the repository has no GitHub releases, so the registry contents change in place rather than in tagged versions.

## What is in the catalogue

The readme's table gives the count and the purpose of each category, and the numbers are the quickest way to see where the weight of the collection sits.

Brand Logos is the largest by a wide margin, at 154 elements, described as theme-adaptive logos for tech companies and AI services. That category is the reason the project is worth knowing about even if you install none of the rest, because a logo set that adapts to your theme is a lot of fiddly work to reproduce.

AI Elements has 37, covering chat, reasoning, tool calls and streaming for the Vercel AI SDK. SFX has 24, which are CC0 sound effects for UI and video. Claude Code has 12, described as automation hooks covering notifications, safety guards and developer experience. Dev Tools has 9, a JSON viewer, a schema viewer and a webhook tester.

Then the smaller groups. GitHub has 7, for stars, contributions and repo stats, and UploadThing has 7 for file upload. Clerk has 6 for the auth flows, Theme Switcher has 6 for dark and light mode toggles with variants, and Loaders has 6 for animated loading indicators. Upstash has 5, for rate limiting, caching and leaderboards, and Polar has 5 for sponsorship badges, pricing cards and licence keys. PDF is the smallest at 2, a viewer and utilities.

Two things stand out about that list. The categories are named after services rather than after UI patterns, which is a different axis from a component library: you pick a block because you use Clerk, not because you need a dialog. And the inclusion of Claude Code hooks and SFX means the catalogue covers parts of an application that a pure UI library would never touch, which is the point of calling the collection full-stack.

## The service dependencies, and what each block expects of you

The.env.example file at the repository root is the most informative document in the repository, because it lists exactly which services the blocks talk to and what each one needs.

Clerk needs a publishable key and a secret key, plus optional sign-in and sign-up URL overrides for additional integrations. The Clerk dependencies in package.json span the whole stack: the backend package, the React bindings, the Next.js integration, the themes package and the types package.

Polar needs an access token, a success URL with a checkout_id placeholder, and a base URL pointing at the Polar API.

Resend needs an API key, which is the email service used by some of the blocks. UploadThing needs a token. Google Sheets needs a service account private key, a client email and a spreadsheet id, which is the most involved of the configurations and the one that most often needs a real service account rather than a placeholder.

And the Vercel AI Gateway needs an AI_GATEWAY_API_KEY, with the AI SDK packages in the dependency list covering the gateway, OpenAI, an OpenAI-compatible provider and the React bindings.

The Radix UI packages in the dependency list tell you what the blocks are built from: accordion, avatar, checkbox, collapsible, context menu, dialog, label, popover, scroll area, select, slider, slot, switch, tabs, toggle and tooltip. The Slot package in particular is what allows a component to pass props through to its child element, which is how a button can be rendered as a link or a Radix trigger without a wrapper.

The practical consequence for an adopter is that each block arrives with its own environment requirements, and a block whose variable is missing will fail at the point where it is used rather than at build time, since these are runtime credentials on the server.

The.env.example is the only place that surfaces the Google Sheets integration, and the repository also carries a CREDITS.md, a CLAUDE.md and a.claude/ directory, which suggests the project keeps agent instructions alongside the code.

## The registry mechanics, and the tooling behind them

The repository is not just a set of blocks; it is also the machinery that publishes them as a shadcn registry, and the package.json scripts describe that machinery.

The build:registry script runs scripts/build-registry.ts, and the prebuild hook runs it before every next build. The registry:index script runs scripts/generate-registry-index.ts, and move-component runs scripts/move-component.ts, which is a maintenance tool for relocating a component between categories without hand-editing every reference. There are matching registry/ and __registry__/ directories at the root, which is the standard shadcn layout where the generated output and the source definitions live side by side.

The testing setup is Vitest, with vitest.config.ts and vitest.setup.ts, and both a test and a test:ui script. Linting is Biome, with biome check for lint and biome format --write for formatting, and typecheck is a plain tsc --noEmit. Husky handles the git hooks, and there is a .vscode/ directory for editor configuration.

The development commands in the readme are the Bun equivalents:

```bash
bun install
bun dev
bun run build
```

The catalogue itself is browsable at tryelements.dev, with a separate documentation page per category, and the readme links the shadcn directory listing filtered to elements so you can find them through the shadcn interface you already use.

The ecosystem table lists a second product, Tinte, whose role is generating design systems, alongside Elements, whose role is installing production-ready blocks. The two are linked from the readme as related products from the same organisation, and the CREDITS.md file at the root is where attribution for the individual blocks is likely to live, which matters given the range of third-party services involved.

## Where Elements fits, and where it stops

The comparison worth making is with building the feature yourself out of shadcn primitives, and with a conventional component package.

Against building it yourself, the difference is that a block arrives with the parts that are tedious and easy to get subtly wrong. A Clerk sign-in flow is a form, a session state, an error path, a loading state and a redirect, and the parts that are tedious are not the form. An AI chat block is a message list, a streaming response, a tool call rendering and a stop button, and the streaming protocol is the part you would otherwise spend a day on.

Against a conventional component package, the difference is the shadcn model: the code is copied into your repository rather than installed as a dependency. You own it and can change it, which is the argument for the model, and the cost is that a block is not upgradeable. When the upstream service changes its API, a copied block has to be fixed by you.

The limits are worth naming. These are examples rather than a maintained API surface, and the repository version of 0.1.0 with no GitHub releases reflects that. Several blocks are tightly coupled to a specific service and a specific framework, so the Clerk and Polar and UploadThing blocks assume Next.js and their own SDKs, and the README's own description says built for Next.js, TypeScript. The AI Elements assume the Vercel AI SDK.

The catalogue is also uneven in depth. 154 logos is a lot of content, and 2 PDF elements is very little, so the value depends entirely on whether the thing you need happens to be in a deep category.

And there is a licensing question behind the whole collection. The repository is MIT, and the readme credits the individual elements elsewhere, but the blocks that contain a third party's logo artwork or a third party's proprietary SDK integration are a separate matter from the code that wires them up. The CREDITS.md file is the place to check that, and for a commercial product the logos category in particular is worth reading before you ship.

For a team on Next.js with shadcn already in place, the registry format means the adoption cost is one command per block and the code lands where you can edit it. For a team starting from scratch, the same blocks are a reasonable way to see how a well-built feature is put together, since a copied block is readable source rather than a dependency.

## Conclusion

Elements suits a Next.js team that has already adopted shadcn/ui and would rather take a working auth flow, pricing card or AI chat block than assemble one from primitives, since the blocks are registered with shadcn and install into your own source tree with the same command you already use for components. It is the wrong tool if you want a component library, because the blocks are examples of how to compose shadcn rather than a package you import, and it is the wrong tool if you are not on Next.js, since several blocks assume a specific stack. Before you install one, read the .env.example file, because each block brings its own service credentials and a block that references a variable you have not set will fail at runtime rather than at build time.

## FAQ

### What is the Elements project?

It is a set of full-stack shadcn/ui blocks for auth, payments, AI, logos and more, built for Next.js and TypeScript. Each block is a working feature rather than a single primitive, covering things like Clerk auth flows, Polar pricing cards, UploadThing uploads, Upstash rate limiting and AI chat for the Vercel AI SDK.

### How do I install an Elements block?

With the shadcn CLI, for example npx shadcn@latest add @elements/clerk-sign-in, npx shadcn@latest add @elements/logos or npx shadcn@latest add @elements/polar-pricing-card. Elements is a trusted shadcn registry, and the readme says no manual configuration is needed.

### What categories does the Elements catalogue cover?

Brand Logos with 154 elements, AI Elements with 37, SFX with 24, Claude Code with 12, Dev Tools with 9, GitHub and UploadThing with 7 each, Clerk, Theme Switcher and Loaders with 6 each, Upstash and Polar with 5 each, and PDF with 2. Every category is documented at tryelements.dev.

### What environment variables do Elements blocks need?

The .env.example file lists them: a Clerk publishable key and secret key, a Polar access token with success URL and base URL, a Resend API key, an UploadThing token, Google Sheets service account credentials and a spreadsheet id, and a Vercel AI Gateway API key. These are runtime server credentials, so a missing one fails where the block is used rather than at build time.

### How is the Elements registry built?

The build:registry script runs scripts/build-registry.ts and is wired as a prebuild hook, so it runs before every next build. There are also scripts to generate the registry index and to move a component between categories, plus registry/ and __registry__/ directories for the generated output and the source definitions. Development uses Bun with bun install, bun dev and bun run build.

### What licence does Elements use?

MIT, with the LICENSE file at the repository root and a CREDITS.md alongside it. The project is private as a package but published as a shadcn registry, and the main repository version is 0.1.0 with no GitHub releases, so the registry contents are updated in place.

## Sources

- [crafter-station/elements on GitHub](https://github.com/crafter-station/elements)
- [Issues](https://github.com/crafter-station/elements/issues)
- [License: MIT](https://github.com/crafter-station/elements/blob/main/LICENSE)
- [Project website](https://www.tryelements.dev/)
- [README](https://github.com/crafter-station/elements/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crafter-station-elements