Inventory System is configured entirely through environment variables. CopyDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/juadariasmar/inventory_project/llms.txt
Use this file to discover all available pages before exploring further.
.env.example to .env at the project root and fill in the values described below before running the development server or deploying to production. Variables marked required must be present at startup — the application will fail to connect to the database or authenticate users without them. Variables marked optional enable additional features but the system runs without them.
Database
Neon Postgres requires two separate connection strings: a pooled URL for application runtime (used by@prisma/adapter-neon via WebSockets) and an unpooled direct URL for the Prisma CLI and migrations (which require full SQL session support).
Pooled PostgreSQL connection string used by the application at runtime. This is the connection provided by Neon’s PgBouncer pooler. It is set as the
url in prisma/schema.prisma and used by @prisma/adapter-neon to open WebSocket connections inside Vercel’s serverless environment.Direct (non-pooled) PostgreSQL connection string. Set as the
directUrl in prisma/schema.prisma. Used exclusively by prisma migrate deploy, prisma db push, and the Neon adapter when a direct session is needed. Never use this URL in application code at runtime.Authentication (Neon Auth)
Inventory System uses Neon Auth (@neondatabase/auth) instead of a traditional NextAuth provider. The following variables connect the application to your Neon Auth deployment and secure its cookies and webhooks.
A random, secret string of at least 32 characters used to sign and verify JWTs issued by Neon Auth. Generate one with
openssl rand -base64 32. Keep this value secret — rotating it will invalidate all active sessions.The canonical public URL of the application, including scheme and port. Used by Neon Auth for redirect URLs and CORS validation. Set to
http://localhost:3000 locally and your Vercel deployment URL in production.The public base URL exposed to client-side code (browser). This is used when constructing absolute URLs in the frontend, such as invitation links and email confirmation redirects. Must match
NEXTAUTH_URL in most deployments.The base URL of your Neon Auth service, found in the Neon Console under Auth → Settings. It takes the form
https://<project-id>.neonauth.tech/<dbname>/auth. All Neon Auth SDK calls are routed through this URL.Secret used by the Neon Auth SDK to sign the session cookie stored in the browser. Must be a long, random string. Generate one independently of
NEXTAUTH_SECRET.Secret used to verify the HMAC signature on webhook payloads sent by Neon Auth to
POST /api/auth/webhook. Copy this value from the Neon Console webhook configuration. If this value is wrong, user-sync webhooks will be rejected with a 401.Admin Configuration
These variables control automatic role promotion at sign-in. When a verified user’s email matches one of these addresses, the system upgrades theirRol to the corresponding level without any manual action from an existing admin.
The email address that will be automatically promoted to
SUPER_ADMIN role on first sign-in. There can only be one SUPER_ADMIN address. This user can manage all companies and users across the entire platform.A comma-separated list of email addresses that will be automatically promoted to
ADMIN role on sign-in. Useful for pre-approving team members who manage specific companies without granting full platform access.Email (Resend)
Transactional emails — such as invitation links and password reset messages — are sent via Resend. These variables are optional; if omitted, email-dependent features will be disabled but the rest of the application continues to work.API key for the Resend transactional email service. Create one in the Resend dashboard under API Keys. Without this key, no outbound emails will be sent.
The sender address displayed in outbound transactional emails. Must be a verified domain or address in your Resend account.
Rate Limiting (Upstash Redis)
The middleware applies a sliding-window rate limit of 5 POST requests per minute per IP across all mutating API endpoints. Upstash Redis provides a distributed, serverless-compatible store for this counter. Both variables must be set together — providing only one has no effect.The REST API URL for your Upstash Redis database. Found in the Upstash Console under Database → REST API.
The REST API token that authenticates requests to Upstash Redis. Found in the same panel as
UPSTASH_REDIS_REST_URL.Upstash Redis is optional. When
UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN are absent, the middleware falls back to an in-memory Map for rate limiting. This fallback works correctly for local development and single-instance deployments, but it does not share state across multiple Vercel serverless function instances. Configure Upstash Redis for any production deployment that may run more than one instance concurrently.