Overview
This guide covers all available configuration options for your application using thecreateConfig function. Required fields are marked as such, while all others are optional.
Basic Settings
name (Required)
The name of your application. This is used for the website title, emails, and other branding elements throughout your app.
description (Required)
A brief description of your application. This appears in meta tags, search results, and other places where your app is described.
socials (Optional)
Social media links for your application. These are displayed in the website footer and can be used for sharing and promotion. Only include the social platforms you actually use.
Payments (Required)
Configure payment plans and subscription features for your application. The entire payments object is required.advantages (Required)
Define the feature advantages that differentiate your pricing plans. Each advantage must be defined as either "number" or "boolean" type.
defaultProduct (Required)
The free or default plan that users start with. This should include basic advantages that apply to all users. Note that productId is not required for the default product.
products (Required)
Define your paid subscription plans. Each product must have both production and development product IDs from your payment provider, and advantages that match your advantages definition.
Authentication (Required)
Configure how users can sign in to your application. The auth object is required, but its properties are optional.magicLink (Optional)
Enable passwordless authentication via email magic links. When enabled, the login page will show an email input for magic link authentication.
socialProviders (Optional)
Array of social OAuth providers for authentication. The login page will display a button for each enabled provider. The available providers are defined by your SocialProvider type.
Secondary Storage (Optional)
Configure additional storage and caching features for improved performance. Uses Upstash Redis for caching sessions and implementing rate limiting. When enabled, sessions are cached in Redis and rate limiting is handled by Upstash. If not set, sessions will be cached using cookies and the default rate limiter from Better Auth will be used instead.secondaryStorage
Enable secondary storage features like caching and rate limiting. This is recommended for production applications.
rateLimit (Optional)
Configure request rate limiting to protect your application from abuse. You can set different limits for page requests and API requests. This is only available when secondaryStorage is enabled.
Default values:
- page: For page requests
- max: 40 requests
- window: 60 seconds
- api: For API requests
- max: 10 requests
- window: 20 seconds
Note: Rate limiting is only enabled in production mode when secondary storage is enabled.
Testing Rate Limits in Development
If you want to test rate limiting in development mode, you can explicitly enable it by settingrateLimit.enabled to true: