Runqora UI
A shadcn registry of components for the
screens most SaaS apps need and shadcn/ui doesn't ship. Install them with the
shadcn CLI and own the code. Nothing runs on Runqora's side.
Docs: runqora.dev · Changelog
npx shadcn@latest registry add @runqora=https://runqora.dev/r/{style}/{name}.json
npx shadcn@latest add @runqora/file-browser @runqora/storage-actions
Principles
- shadcn's look. Components use shadcn/ui and your theme's CSS variables,
with no styles of their own.
- Radix and Base UI. Each component is published for both and tested in
both.
- Your icon library. Icons follow the
iconLibrary in components.json.
- Your backend. Components take data and callbacks. Where a server part
can't be avoided, it ships as a small file you own.
- Accessible and responsive, with few dependencies.
Roadmap
One set at a time. Each ships, gets announced and gets feedback before the
next starts.
- File browser for S3-compatible buckets. Browse folders, preview, see
details, upload, download, copy links, rename or move, and delete files in
the Amazon S3 or Cloudflare R2 bucket you already have. Files go straight
between the browser and the bucket through signed URLs, with server
actions and a small S3 client you own.
- Audit log viewer. See who did what in your app: filter by actor,
action, outcome and date, and open an event to see what it changed. Events
live in your own Postgres database, through any Postgres library or ORM,
with server actions that scope every query to what the person may see.
- Webhooks. Let your customers add and manage the endpoints your app
sends webhooks to, and see each delivery's payload and responses, with
resend. You bring the backend that sends them, your own code or a service
such as Svix: the components call a small
interface you write for it.
- Custom domains. Let your customers connect their own domains: add
one, see the DNS records to create, and watch it become active. Your
backend serves the domains, such as Cloudflare for SaaS, Vercel or your
own proxy, through a small interface you write for it.
Not planned, because good registries already cover them:
Development
Uses Bun.
bun install
bun run dev # docs site on http://localhost:3000
bun run registry:build # writes apps/docs/public/r
bun run check # lint, formatting and types
bun run test # tests
The S3 client's tests also run against a real S3-compatible server when
S3_TEST_ENDPOINT, S3_TEST_ACCESS_KEY_ID and S3_TEST_SECRET_ACCESS_KEY are
set. CI uses RustFS. The audit store's tests run against
PGlite, and also against a Postgres server when
POSTGRES_TEST_URL is set, as in CI.
Registry source is in apps/docs/registry, listed in
apps/docs/registry.json. Components are written once, Radix-style, with an
IconPlaceholder for each icon. They may use another registry's items, such
as Dice UI's, when those are published for both Radix
and Base UI, follow the project's icon library, and need no app-wide setup. The shadcn CLI adapts them to Base UI and to
the project's icon library when it installs them. A file that needs different
code on Base UI gets a copy at the same path under apps/docs/registry/base/.
To test installs the way CI does, start the built docs site and run:
bun scripts/test-install.ts --style base-nova --icons hugeicons \
--registry http://localhost:3000
License
MIT
