community-plugins

Cursor Directory

The directory of plugins from the Cursor community.

cursor.directory

Project Structure

├── apps/
│   └── cursor/          # Next.js app
├── supabase/
│   └── migrations/      # Database migrations
└── package.json         # Bun workspace config

All data lives in the database — there is no local data in the repo.

Getting Started

Prerequisites

• Bun
• A Supabase project

Setup

1. Clone the repo

git clone https://github.com/cursor/community-plugins.git
cd community-plugins

1. Install dependencies

bun install

1. Configure environment variables

cp apps/cursor/.env.example apps/cursor/.env

Fill in the required values:

1. Run the database migrations

Apply the migrations in supabase/migrations/ to your Supabase project.

1. Start the dev server

bun dev

Open http://localhost:3000.

Contributing

All content is submitted through the website — no pull requests needed for data.

Submit a Plugin

1. Go to cursor.directory/plugins/new
2. Sign in with GitHub or Google
3. Paste a GitHub repo URL — we auto-detect components following the Open Plugins standard
4. Click Submit

Auto-detected components:

See the Open Plugins specification and plugin template for details.

Tech Stack

• Framework: Next.js (App Router, Turbopack)
• Runtime: Bun
• Database: Supabase (PostgreSQL)
• Job Queue: Supabase Queues (pgmq) drained by a 1-min Vercel cron
• Styling: Tailwind CSS
• UI: Radix UI + shadcn/ui
• Search: Fuse.js (client-side fuzzy search)
• URL State: nuqs
• Linting: Biome

Plugin security scan

Submitted plugins are auto-reviewed by a Cursor SDK agent (composer-2) running in local mode against a fresh clone of the plugin's repo plus its inline component content. The verdict (safe / suspicious / malicious) is written back to plugins.scan_status and surfaces in the admin queue.

The scan is asynchronous and runs out of the request lifecycle:

1. Enqueue — server actions and the recover-stuck-scans cron call enqueuePluginScan(pluginId) which sends a message to the plugin_scans pgmq queue.
2. Kick — user-facing actions also fire kickDrainAfterResponse() so the drain route is called via next/server after() immediately after the response is flushed. Scans typically start within a few hundred ms.
3. Drain — /api/queue/plugin-scans/drain reads one message (vt=900s, n=1), runs runPluginScan(pluginId), archives the message on success, leaves it for VT-expiry on retryable error, or buries it after MAX_ATTEMPTS=5 deliveries.
4. Cron safety net — Vercel cron hits the same drain route every minute so any messages that missed their kick still get processed.

The drain route uses maxDuration = 800 (Vercel Pro+ Fluid Compute ceiling) and relies on CURSOR_API_KEY + CRON_SECRET from the env file.