Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/nayalsaurav/Storx/llms.txt

Use this file to discover all available pages before exploring further.

Storx is designed to be deployed on Vercel with three external services: Neon for serverless PostgreSQL, Clerk for authentication, and ImageKit for CDN file storage. This guide walks through provisioning each service, wiring up the required environment variables, and running your first production deployment.
1

Create a Neon database

  1. Go to neon.tech and sign in or create a free account.
  2. Click New Project, give it a name (e.g. storx-production), and select a region closest to your Vercel deployment region.
  3. Once the project is created, open the Connection Details panel and copy the Connection String. It looks like:
postgresql://user:password@ep-xxx.us-east-2.aws.neon.tech/neondb?sslmode=require
  1. This value becomes your DATABASE_URL environment variable.
2

Set up Clerk

  1. Go to clerk.com and sign in or create a free account.
  2. Click Create application, name it (e.g. Storx), and choose your desired sign-in methods (email/password, Google, GitHub, etc.).
  3. In the Clerk dashboard, navigate to API Keys and copy:
    • Publishable keyNEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
    • Secret keyCLERK_SECRET_KEY
  4. In Paths (under Configure → Paths), set the following redirect URLs to match the Next.js App Router pages:
    • Sign-in URL: /signin
    • Sign-up URL: /signup
    • After sign-in URL: /dashboard
    • After sign-up URL: /dashboard
  5. Set the corresponding environment variables:
NEXT_PUBLIC_CLERK_SIGN_IN_URL=/signin
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/signup
3

Configure ImageKit

  1. Go to imagekit.io and sign in or create a free account.
  2. From the Dashboard, navigate to Developer Options → API Keys.
  3. Copy the following three values:
    • Public KeyNEXT_PUBLIC_IMAGEKIT_PUBLIC_KEY
    • Private KeyIMAGEKIT_PRIVATE_KEY
    • URL EndpointNEXT_PUBLIC_IMAGEKIT_URL_ENDPOINT (e.g. https://ik.imagekit.io/your_imagekit_id)
  4. Storx automatically creates the folder structure /storex/{userId}/ inside ImageKit when the first file is uploaded by each user. No manual folder creation is required.
4

Deploy to Vercel

  1. Push your Storx repository to GitHub (or fork github.com/nayalsaurav/Storx).
  2. Go to vercel.com, click Add New → Project, and import your GitHub repository.
  3. In the Environment Variables section of the Vercel project settings, add all of the following variables before deploying:
DATABASE_URL=
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=
CLERK_SECRET_KEY=
NEXT_PUBLIC_CLERK_SIGN_IN_URL=/signin
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/signup
NEXT_PUBLIC_IMAGEKIT_PUBLIC_KEY=
IMAGEKIT_PRIVATE_KEY=
NEXT_PUBLIC_IMAGEKIT_URL_ENDPOINT=
  1. Click Deploy. Vercel will run next build and produce an optimized production bundle.
  2. Once the deployment succeeds, note your production URL (e.g. https://storx.vercel.app).
  3. Return to your Clerk dashboard and add your production domain to the Allowed origins and update any redirect URLs to use the production URL.
5

Run migrations

After the first deploy, run the Drizzle migrations locally pointed at your production Neon DATABASE_URL. This creates the files table in your production database.Update your local .env.local with the production DATABASE_URL, then run:
npm run db:migrate
A successful run prints:
🚀 Starting migrations...
✅ All migrations completed successfully.
The files table is now ready to accept records from your production Storx instance.
Never expose IMAGEKIT_PRIVATE_KEY or CLERK_SECRET_KEY in client-side code. Both variables are server-only secrets. In Next.js, any environment variable prefixed with NEXT_PUBLIC_ is embedded into the client bundle — the private keys deliberately omit this prefix so they remain server-side only. If these keys are accidentally committed to a public repository or exposed in a client bundle, rotate them immediately from the respective service dashboards.

Production Checklist

Confirm all eight environment variables are configured in your Vercel project settings before deploying:
VariableSource
DATABASE_URLNeon project → Connection Details
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEYClerk dashboard → API Keys
CLERK_SECRET_KEYClerk dashboard → API Keys
NEXT_PUBLIC_CLERK_SIGN_IN_URLSet to /signin
NEXT_PUBLIC_CLERK_SIGN_UP_URLSet to /signup
NEXT_PUBLIC_IMAGEKIT_PUBLIC_KEYImageKit dashboard → Developer Options
IMAGEKIT_PRIVATE_KEYImageKit dashboard → Developer Options
NEXT_PUBLIC_IMAGEKIT_URL_ENDPOINTImageKit dashboard → Developer Options
Verify that the files table exists in your Neon database before your first user signs in. You can confirm this by opening Drizzle Studio against your production database:
npm run db:studio
The files table should be present in the public schema with the following columns: id, name, size, type, file_url, thumbnail_url, imagekit_file_id, user_id, parent_id, is_folder, is_starred, is_trash, created_at, updated_at.The migration history is tracked in the __drizzle_migration table in the public schema.
In the Clerk dashboard under Configure → Paths, confirm the following URLs are set correctly for your production deployment:
SettingValue
Sign-in URL/signin
Sign-up URL/signup
After sign-in redirect URL/dashboard
After sign-up redirect URL/dashboard
Also ensure your production domain (e.g. https://storx.vercel.app) is listed under Allowed origins in your Clerk application settings to prevent CORS issues with Clerk’s authentication requests.
Storx stores all uploaded files under a per-user folder structure in ImageKit. When a file is uploaded to the root of a user’s drive, it is placed at:
/storex/{userId}/
When a file is uploaded inside a folder, it is nested under:
/storex/{userId}/folder/{parentId}/
These paths are constructed automatically by the upload API route (/api/files/upload) using the authenticated Clerk userId and the parentId from the request. No manual configuration in ImageKit is required — the folders are created on first upload. Ensure your ImageKit account has sufficient storage for the expected number of users and file sizes.

Build docs developers (and LLMs) love