Welcome to TanStack.com!

This site is built with TanStack Router!

• TanStack Router Docs

It's deployed automagically with Netlify!

• Netlify

Development

From your terminal:

pnpm install
pnpm dev

This starts your app in development mode, rebuilding assets on file changes.

Editing and previewing the docs of TanStack projects locally

The documentations for all TanStack projects except for React Charts are hosted on https://tanstack.com, powered by this TanStack Router app. In production, the markdown doc pages are fetched from the GitHub repos of the projects, but in development they are read from the local file system.

Follow these steps if you want to edit the doc pages of a project (in these steps we'll assume it's TanStack/form) and preview them locally :

1. Create a new directory called tanstack.

mkdir tanstack

2. Enter the directory and clone this repo and the repo of the project there.

cd tanstack
git clone [email protected]:TanStack/tanstack.com.git
git clone [email protected]:TanStack/form.git

Note

Your tanstack directory should look like this:

tanstack/
   |
   +-- form/
   |
   +-- tanstack.com/

Warning

Make sure the name of the directory in your local file system matches the name of the project's repo. For example, tanstack/form must be cloned into form (this is the default) instead of some-other-name, because that way, the doc pages won't be found.

3. Enter the tanstack/tanstack.com directory, install the dependencies and run the app in dev mode:

cd tanstack.com
pnpm i
# The app will run on https://localhost:3000 by default
pnpm dev

4. Now you can visit http://localhost:3000/form/latest/docs/overview in the browser and see the changes you make in tanstack/form/docs.

Note

The updated pages need to be manually reloaded in the browser.

Warning

You will need to update the docs/config.json file (in the project's repo) if you add a new doc page!

Access Token To - Project Setup and Configuration

This section describes the setup and configuration specific to the "Access Token To" application.

License

This project is licensed under the Business Source License 1.1 (BSL 1.1), a source-available license. You can find more information about BSL 1.1 and its requirements here.

Key Points:

• The source code is available for viewing and non-production use
• A license key is required for production use
• On June 23, 2029 (4 years from the time of this writing), this project will automatically transition to the MIT License
• The project will also transition to MIT License upon discontinuation of the product or winding-down of Naptha AI

Getting a License Key: To obtain a license key for production use, please contact the Naptha team via our Discord server: Join our Discord

Environment Variables and Secrets Management

The application requires several environment variables and secrets to function correctly.

Required Variables

You will need to provide values for the following:

1. Standard Environment Variables:

These are typically non-sensitive configuration values. For local development, they should be placed in an .env file in the project root.

• BETTER_AUTH_URL: The base URL for your app that better auth should use for redirects. Should be the same as LOCAL_URL below.
• LOG_LEVEL: The desired log level for the application (e.g., debug, info, warn, error).
• LOCAL_URL: The local URL where the application is running (e.g., http://localhost:3000).

2. Secrets:

These are sensitive values and are managed by SST's secrets system. For local development, you will first add them to your .env file, and then use a script to load them into SST's local secrets manager.

• DATABASE_URL: The connection string for your PostgreSQL database.
• BETTER_AUTH_SECRET: The secret key for your Better Auth integration.
• GITHUB_CLIENT_ID: Your GitHub OAuth application client ID.
• GITHUB_CLIENT_SECRET: Your GitHub OAuth application client secret.
• GOOGLE_CLIENT_ID: Your Google OAuth application client ID.
• GOOGLE_CLIENT_SECRET: Your Google OAuth application client secret.
• EVERVAULT_APP_ID: Your Evervault App ID for client-side encryption.
• EVERVAULT_API_KEY: Your Evervault API Key for server-side operations.
• AWS_ACCESS_KEY_ID: AWS Access Key ID (if needed for specific AWS SDK operations directly from app code, though typically SST manages AWS credentials for its resources).
• AWS_SECRET_ACCESS_KEY: AWS Secret Access Key (corresponding to the Access Key ID).

Local Development Setup

Step 1: Create .env file

1. In the root directory of the project, create a file named .env.

2. Add all the variables listed above to this file with their respective values. Example:

   # Standard Environment Variables
   BETTER_AUTH_URL=https://yourauth.example.com
   LOG_LEVEL=debug
   LOCAL_URL=http://localhost:3000
   
   # Secrets (to be loaded into SST)
   DATABASE_URL=postgresql://user:password@host:port/database
   BETTER_AUTH_SECRET=your_better_auth_secret
   GITHUB_CLIENT_ID=your_github_client_id
   GITHUB_CLIENT_SECRET=your_github_client_secret
   GOOGLE_CLIENT_ID=your_google_client_id
   GOOGLE_CLIENT_SECRET=your_google_client_secret
   EVERVAULT_APP_ID=your_evervault_app_id
   EVERVAULT_API_KEY=your_evervault_api_key
   AWS_ACCESS_KEY_ID=your_aws_access_key_id
   AWS_SECRET_ACCESS_KEY=your_aws_secret_access_key

   Note: Ensure this .env file is added to your .gitignore file to prevent committing sensitive credentials.

Step 2: Set SST Secrets Locally using the script

The secrets listed under the "Secrets" section above need to be set within SST's secret management for your local development stage. A script is provided to automate this using the values from your .env file.

1. Make the script executable (you only need to do this once):

   chmod +x scripts/set_sst_secrets.sh

2. Perform a dry run (recommended): This will show you what secrets the script would attempt to set and their values, without actually setting them. This helps verify that the script is reading your .env file correctly.

   bash scripts/set_sst_secrets.sh --dry-run

   Review the output to ensure the correct values are being picked up.

3. Run the script to set secrets: If the dry run looks good, run the script without the --dry-run flag to set the secrets in your local SST environment.

   bash scripts/set_sst_secrets.sh

   The script will use the sst secret set command for each secret. You might be prompted by SST if a secret is being overwritten.

Deployed Environments (e.g., Staging, Production)

For deployed environments, secrets should be set directly using the SST CLI, specifying the target stage:

sst secret set SECRET_NAME "your_secret_value" --stage your_stage_name

Standard environment variables (BETTER_AUTH_URL, LOG_LEVEL, LOCAL_URL) should be configured through your CI/CD pipeline's environment variable settings or directly in the SST environment configuration for the respective stage in sst.config.ts if not sourced from secrets.