Skip to main content
Glama

UploadKit

File uploads for developers. Beautifully.

Open-source TypeScript SDK + 40+ premium React components + managed storage on Cloudflare R2 — with BYOS (Bring Your Own Storage) mode so you can use your own S3, R2, GCS, or Backblaze B2 bucket. 5 GB free forever.

Website · Docs · Dashboard · Changelog

npm: @uploadkitdev/react npm: @uploadkitdev/mcp Glama MCP score Awesome MCP Servers


Quickstart — add to an existing project

Most people land here with a Next.js app already running. Three steps:

pnpm add @uploadkitdev/react @uploadkitdev/next

Create app/api/uploadkit/[...uploadkit]/route.ts:

import { createUploadKitHandler, type FileRouter } from '@uploadkitdev/next';

const router = {
  default: { maxFileSize: '4MB', allowedTypes: ['image/*'] },
} satisfies FileRouter;

export const { GET, POST } = createUploadKitHandler({
  router,
  apiKey: process.env.UPLOADKIT_API_KEY!,
});

Wrap the root layout and drop in a dropzone:

// app/layout.tsx
import { UploadKitProvider } from '@uploadkitdev/react';
// <UploadKitProvider endpoint="/api/uploadkit">{children}</UploadKitProvider>

// any page
import { UploadDropzone } from '@uploadkitdev/react';
// <UploadDropzone route="default" />

Set UPLOADKIT_API_KEY=uk_live_... in .env.local and you're done. Full walkthrough: docs.uploadkit.dev/docs/getting-started/quickstart.

npx uploadkit init

Detects your framework, installs deps, creates the route handler, and wraps your layout — all in one command. See the CLI guide for details.

Starting a new project?

npx create-uploadkit-app my-app

Templates for Next.js, SvelteKit, Remix, and Vite — see the CLI guide.

Using an AI-assistant IDE?

Install the UploadKit MCP server and let Claude Code, Cursor, Windsurf, or Zed wire the whole thing up for you:

npx -y @uploadkitdev/mcp

Related MCP server: Rendobar MCP Server

Packages

Package

Version

Description

@uploadkitdev/core

npm

Framework-agnostic upload client (browser, Node, Edge)

@uploadkitdev/react

npm

40+ premium React upload components

@uploadkitdev/next

npm

Next.js App Router handler + Express/Hono adapters

@uploadkitdev/mcp

npm

Official MCP server for AI coding assistants

create-uploadkit-app

npm

Scaffolder for new projects (Next, SvelteKit, Remix, Vite)

Component highlights

UploadKit ships 40+ components across 7 categories:

  • Classics — UploadButton, UploadDropzone, UploadModal, FileList, FilePreview

  • Premium dropzones — Glass (Vercel/Linear), Aurora (Apple), Terminal (Raycast), Brutal (Neo-brutalist), Minimal, Neon

  • Specialty — UploadAvatar, UploadInlineChat (ChatGPT-style), UploadStepWizard (Stripe Checkout-style), UploadEnvelope (WeTransfer-style)

  • Motion / Progress — UploadProgressRadial, UploadProgressLiquid, UploadProgressOrbit, UploadCloudRain, UploadBento, UploadParticles, UploadDataStream (Matrix/Warp-style)

  • Galleries — UploadGalleryGrid, UploadPolaroid, UploadTimeline, UploadKanban, UploadStickyBoard

All are MIT-licensed, dark mode out of the box, themeable via CSS custom properties, and work with or without motion as a peer dep.

BYOS — Bring Your Own Storage

Use the same SDK against your own bucket — zero frontend changes, credentials stay server-side.

import { createUploadKitHandler, type FileRouter } from '@uploadkitdev/next';
import { createR2Storage } from '@uploadkitdev/next/byos';

const router = {
  media: { maxFileSize: '8MB', maxFileCount: 4, allowedTypes: ['image/*'] },
} satisfies FileRouter;

export const { GET, POST } = createUploadKitHandler({
  router,
  storage: createR2Storage({
    accountId: process.env.CLOUDFLARE_R2_ACCOUNT_ID!,
    accessKeyId: process.env.CLOUDFLARE_R2_ACCESS_KEY_ID!,
    secretAccessKey: process.env.CLOUDFLARE_R2_SECRET_ACCESS_KEY!,
    bucket: process.env.CLOUDFLARE_R2_BUCKET!,
  }),
});

Supported providers: AWS S3 · Cloudflare R2 · Google Cloud Storage · Backblaze B2.

AI-native — MCP server

UploadKit ships an official Model Context Protocol server so Claude Code, Cursor, Windsurf, Zed, ChatGPT, and Claude.ai can generate UploadKit code with first-class knowledge of every component and scaffold.

Stdio (IDE clients):

npx -y @uploadkitdev/mcp

Remote HTTP (ChatGPT / Claude.ai web):

https://api.uploadkit.dev/api/v1/mcp

Full setup: docs.uploadkit.dev/docs/guides/mcp · Source: packages/mcp · Registry: io.github.drumst0ck/uploadkit

Monorepo layout

apps/
  web         Landing + pricing (uploadkit.dev)
  docs        Fumadocs site (docs.uploadkit.dev)
  dashboard   SaaS dashboard (app.uploadkit.dev)
  api         REST API + MCP remote endpoint (api.uploadkit.dev)
packages/
  core                  @uploadkitdev/core
  react                 @uploadkitdev/react
  next                  @uploadkitdev/next
  mcp                   @uploadkitdev/mcp (stdio MCP server)
  mcp-core              shared MCP tool surface (internal)
  create-uploadkit-app  scaffolder for new projects
  db                    MongoDB models
  emails                React Email templates
  shared                types, errors, utilities
  ui                    dashboard components
  config                shared tsconfig / eslint / tailwind base

Tech stack

Next.js 16 · React 19 · Tailwind CSS v4 · TypeScript 5 · MongoDB + Mongoose · Cloudflare R2 · Auth.js v5 · Stripe · Resend + React Email · Fumadocs · Turborepo · pnpm · Changesets.

Status

Version 1.0 shipped. Actively maintained. Issues and contributions are welcome on GitHub.

License

MIT © Drumst0ck and contributors.

Available Tools

12 tools
get_byos_configA

Generate Bring-Your-Own-Storage (BYOS) configuration for an UploadKit Next.js handler — environment variables, handler code, and setup notes for a specific storage provider.

When to use: the user wants to store uploads in their own cloud bucket instead of UploadKit's managed R2. Typical triggers: compliance/data-residency requirements, existing bucket infra, desire to avoid vendor lock-in.

Returns: a plain-text string with three sections — provider-specific notes, the .env variable block, and the TypeScript handler code. Credentials are always server-side; the browser never sees them. Read-only, deterministic. No network calls, no secrets exposed.

Inputs: provider (required).

get_componentA

Fetch full metadata plus a ready-to-paste React usage example for one specific UploadKit component.

When to use: once you know the exact component name (from list_components or search_components) and need to show the user how to drop it into their code. The returned "usage" field is copy-pasteable TSX including the correct import line and the styles.css import.

Returns: JSON { name, category, description, inspiration, usage }. If the name does not match any component, returns a suggestion message with the 5 closest matches. Read-only, idempotent.

Inputs: name (required).

get_docA

Fetch the full markdown content of a single UploadKit docs page by its path, formatted with title, description, source URL, and the body.

When to use: after search_docs identifies a relevant page and you need its full contents to answer a deep question — prefer search_docs first, then get_doc on the top result. Reading the full page avoids relying on snippets that may omit critical context (callbacks, env vars, edge cases).

Returns: a plain-text string — "# {title}\n\n> {description}\n\nSource: {url}\n\n---\n\n{content}". If the path is unknown, returns a not-found message suggesting list_docs. Read-only, idempotent.

Inputs: path (required).

get_install_commandA

Return the exact shell command to install UploadKit packages for a given package manager.

When to use: before asking the user to add dependencies — match their package manager (detect from the presence of pnpm-lock.yaml / package-lock.json / yarn.lock / bun.lockb if you can, otherwise ask or default to pnpm). Saves you from guessing pnpm vs npm vs yarn vs bun syntax.

Returns: a plain-text shell command as a single string (e.g. "pnpm add @uploadkitdev/react @uploadkitdev/next"). Read-only, idempotent, never modifies anything.

Inputs: packages, packageManager.

get_quickstartA

Return the complete UploadKit quickstart walkthrough for Next.js — install, API key env, route handler, provider, first component, optional BYOS — in one markdown document.

When to use: the user is brand new to UploadKit and asks "how do I get started?", "set this up for me", or any variation that signals zero prior context. Prefer scaffold_route_handler + scaffold_provider + get_install_command when you already know which specific step they need.

Returns: a plain-text markdown document. Takes no parameters. Read-only, static content, idempotent.

Inputs: no named parameters.

list_componentsA

List every React upload component shipped by @uploadkitdev/react with its name, category, one-line description, and design inspiration.

When to use: before recommending or scaffolding any UploadKit component, to confirm the exact name exists and to pick the right variant for the user's context (e.g. browse all "dropzone" variants when the user wants a drag-and-drop area).

Returns: JSON { count, components: [{ name, category, description, inspiration }] }. Read-only, no side effects, idempotent.

Inputs: category.

list_docsA

Enumerate every available UploadKit docs page with title, description, URL, and path.

When to use: to discover what documentation exists before targeted searching, or to orient yourself around the shape of the docs site. Prefer search_docs when you already have a concrete question.

Returns: JSON { count, generatedAt, pages: [{ path, url, title, description }] }. Pages are sorted alphabetically by path. Read-only, static at bundle time, idempotent.

Inputs: no named parameters.

scaffold_providerA

Return a ready-to-paste snippet that wraps the Next.js root layout with <UploadKitProvider> so React components can talk to the upload route handler.

When to use: right after scaffold_route_handler, to complete the wiring. The snippet goes in app/layout.tsx. Without the provider, UploadKit React components throw at runtime.

Returns: a plain-text string containing a short explanatory note followed by a fenced tsx code block. Takes no parameters — the endpoint path is always /api/uploadkit since that is what scaffold_route_handler produces. Read-only, deterministic, idempotent.

Inputs: no named parameters.

scaffold_route_handlerA

Generate the complete file content for a Next.js App Router upload route handler — typed file router, handler export, correct path comment.

When to use: when the user is setting up UploadKit server-side in a Next.js App Router project and needs the app/api/uploadkit/[...uploadkit]/route.ts file created. The returned string is a complete, compilable TypeScript file — write it to disk as-is.

Returns: a markdown-formatted string containing the target path and the complete TS source inside a fenced code block. You must create the file at the literal path app/api/uploadkit/[...uploadkit]/route.ts. Read-only — generates text, never touches the filesystem itself.

Inputs: routeName (required), maxFileSize, allowedTypes, maxFileCount.

search_componentsA

Fuzzy-search the UploadKit component catalog by any free-text keyword — component name, category, description, or design inspiration (e.g. "apple", "stripe", "vercel", "terminal", "progress ring", "kanban board", "matrix").

When to use: the user describes the vibe or use case but does not know the component name yet ("I want something like Stripe Checkout", "show me Apple-style uploaders"). Prefer this over list_components when the goal is discovery rather than enumeration.

Returns: JSON { query, count, matches: [{ name, category, description, inspiration }] }. Read-only, idempotent, case-insensitive.

Inputs: query (required).

search_docsA

Full-text search across every UploadKit docs page (88+ pages — getting-started, core-concepts, SDK reference, API reference, dashboard, guides). Ranks matches by keyword frequency in title, description, and body.

When to use: any question about UploadKit behaviour, configuration, or integration that the component tools do not answer — middleware, onUploadComplete callbacks, REST API endpoints, webhooks, presigned URLs, CSS theming variables, type-safety setup, migration from UploadThing, rate limits, etc.

Returns: JSON { query, count, indexGeneratedAt, matches: [{ path, url, title, description, snippet, score }] }. Sorted by score descending. Read-only. Bundled index (no network call) — results reflect docs at build time.

Inputs: query (required), limit.

transform_imageA

Generate a CDN-cached image variant for a file stored in UploadKit Cloud. Requires a paid plan, a live API key in the MCP process environment as UPLOADKIT_API_KEY, and an image key returned by UploadKit. BYOS files are not supported. Use signed delivery for private or temporary content and public delivery for stable URLs in websites, apps, srcset, CSS, or stored application data. Explicit formats consume 1 transformation unit; auto consumes 3 units.

When to use: after an image is uploaded and the user wants a resized, cropped, optimized, or converted delivery URL. The returned URL is safe to send to browsers; the API key remains server-side.

Returns: JSON { url, expiresAt, delivery, transform, usage }. Has the side effect of reserving monthly transformation units for a new unique variant.

Inputs: key (required), fit, width, format, +3 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.6/5.0

    Scored across 12 tools

    Disambiguation4/5

    Most tools are clearly distinct: docs tools (list/search/get), component tools (list/get/search), and scaffolding tools each target a distinct resource+action. The main overlap is get_quickstart versus the scaffold_route_handler + scaffold_provider + get_install_command trio (and get_byos_config emitting handler code similar to scaffold_route_handler), but the descriptions explicitly guide when to prefer each.

    Naming Consistency5/5

    All twelve names use snake_case with a consistent verb_noun pattern (scaffold_*, get_*, list_*, search_*, transform_*). Verbs map predictably to action semantics: list = enumerate, search = fuzzy discovery, get = fetch one, scaffold = generate file content.

    Tool Count5/5

    Twelve tools sit comfortably in the ideal 3-15 range, and each covers a discrete capability (docs discovery/fetch, component discovery/fetch, install/scaffold helpers, BYOS config, image transform). Nothing feels redundant or missing.

    Completeness4/5

    Strong lifecycle coverage for a dev-enablement server: documentation (list/search/get), component catalog (list/search/get), setup scaffolding (install, route handler, provider, quickstart), BYOS config, and image transforms. A minor gap is there is no tool to scaffold a full component file or handle actual upload/delete operations on stored files, but these are largely workable via get_component usage snippets and the docs.

    Maintenance

    ActivityMaintained
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers