file: ./src/content/docs/extension/ai.mdx
meta: {
  "title": "AI",
  "description": "Leverage AI in your TurboStarter extension."
}
        
When it comes to AI within the browser extension, we can differentiate two approaches:

* **Server + client**: Traditional implementation, same as for [web](/docs/web/ai/overview) and [mobile](/docs/mobile/ai), used to stream responses generated on the server to the client.
* **Chrome built-in AI**: An [experimental implementation](https://developer.chrome.com/docs/ai/built-in) of [Gemini Nano](https://blog.google/technology/ai/google-gemini-ai/#performance) that's built into new versions of the Google Chrome browser.

We recommend relying more on the traditional server + client approach, as it's more versatile and easier to implement. Chrome's built-in AI is a nice feature, but it's still experimental and has some limitations.

Of course, you can always implement a *hybrid* approach which combines both solutions to achieve the best results.

## Server + client

The traditional usage of AI integration in the browser extension is the same as for [web app](/docs/web/ai/configuration#client-side) and [mobile app](/docs/mobile/ai). We use the exact same [API endpoint](/docs/web/ai/configuration#api-endpoint), and we leverage streaming to display answers incrementally to the user as they're generated.

```tsx title="main.tsx"
import { useChat } from "ai/react";

const Popup = () => {
  const { messages } = useChat({
    api: "/api/ai/chat",
  });

  return (
    <div>
      {messages.map((message) => (
        <div key={message.id}>{message.content}</div>
      ))}
    </div>
  );
};

export default Popup;
```

It's the most reliable and recommended way to use AI in the browser extension. Feel free to reuse or modify it to suit your specific needs.

## Chrome built-in AI

<Callout type="warn">
  Chrome's implementation of [built-in AI with Gemini Nano](https://developer.chrome.com/docs/ai/built-in) is experimental and will change as they test and address feedback.
</Callout>

Chrome's built-in AI is a preview feature. To use it, you need Chrome version 127 or greater and you must enable these flags:

* [chrome://flags/#prompt-api-for-gemini-nano](chrome://flags/#prompt-api-for-gemini-nano): `Enabled`
* [chrome://flags/#optimization-guide-on-device-model](chrome://flags/#optimization-guide-on-device-model): `Enabled BypassPrefRequirement`
* [chrome://components/](chrome://components/): Click `Optimization Guide On Device Model` to download the model.

Once enabled, you'll be able to use `window.ai` to access the built-in AI and do things like this:

![Chrome built-in AI](/images/docs/extension/ai.gif)

You can even use a [dedicated provider](https://sdk.vercel.ai/providers/community-providers/chrome-ai) from the Vercel AI SDK ecosystem to simplify its usage. Please remember that this API is still in its early stages and might change in the future.

<Callout title="Available in every extension context!">
  The best thing is that you can use this API in every part of your extension, e.g., popup, background service worker, etc.

  It's completely safe to use on the client-side, as we're not exposing any sensitive data to the user (such as the API key in the traditional server + client approach).
</Callout>

To learn more, please check out the official [Chrome documentation](https://developer.chrome.com/docs/ai/built-in) and the articles listed below.

<Cards>
  <Card href="https://developer.chrome.com/docs/ai/built-in" title="Get started with built-in AI" description="developer.chrome.com" />

  <Card href="https://developer.chrome.com/docs/extensions/ai" title="Extensions and AI" description="developer.chrome.com" />
</Cards>


file: ./src/content/docs/extension/billing.mdx
meta: {
  "title": "Billing",
  "description": "Get started with billing in TurboStarter."
}
        
As you could guess, there is no sense in implementing the whole billing process inside the browser extension, so we're relying on the [web app](/docs/web/billing/overview) to handle it.

> You probably won't display pricing tables inside a popup window, right?

You can customize the whole flow and onboarding process when a user purchases a plan in your [web app](/docs/web/billing/overview).

Then you would be able to easily fetch customer data to ensure that the user has access to correct extension features.

## Fetching customer data

When your user has purchased a plan from your landing page or web app, you can easily fetch their data using the [API](/docs/extension/api/client).

To do so, just invoke the `getCustomer` query on the `billing` router:

```tsx title="customer-screen.tsx"
import { api } from "~/lib/api";

export default function CustomerScreen() {
  const { data: customer, isLoading } = useQuery({
    queryKey: ["customer"],
    queryFn: () => handle(api.billing.customer.$get()),
  });

  if (isLoading) return <p>Loading...</p>;

  return <p>{customer?.plan}</p>;
}
```

You may also want to ensure that user is logged in before fetching their billing data to avoid unnecessary API calls.

```tsx title="header.tsx"
import { api } from "~/lib/api";

export const User = () => {
  const {
    data: { user },
  } = useSession();

  const { data: customer } = useQuery({
    queryKey: ["customer"],
    queryFn: () => handle(api.billing.customer.$get()),
    enabled: !!user, // [!code highlight]
  });

  if (!user || !customer) {
    return null;
  }

  return (
    <div>
      <p>{user.email}</p>
      <p>{customer.plan}</p>
    </div>
  );
};
```

Read more about [auth in extension](/docs/extension/auth/overview).


file: ./src/content/docs/extension/cli.mdx
meta: {
  "title": "CLI",
  "description": "Start your new app project with a single command.",
  "icon": "Command",
  "mirror": "../web/cli.mdx"
}
        


file: ./src/content/docs/extension/database.mdx
meta: {
  "title": "Database",
  "description": "Get started with the database."
}
        
<Callout type="error" title="API deployment required">
  To enable communication between your WXT extension and the server in a production environment, the web application with Hono API must be deployed first.

  <Cards>
    <Card title="API" description="Learn more about the API." href="/docs/web/api/overview" />

    <Card title="Web deployment" description="Deploy your web application to production." href="/docs/web/deployment/checklist" />
  </Cards>
</Callout>

As browser extensions use only client-side code, **there's no way to interact with the database directly**.

Also, you should avoid any workarounds to interact with the database directly, because it can lead to leaking your database credentials and other security issues.

## Recommended approach

You can safely use the [API](/docs/extension/api/overview) and invoke procedures which will run queries on the database.

To do this you need to set up the database on the [web, server side](/docs/web/database/overview) and then use the [API client](/docs/extension/api/client) to interact with it.

Learn more about its configuration in the web part of the docs, especially in the following sections:

<Cards>
  <Card title="Overview" description="Get started with the database" href="/docs/web/database/overview" />

  <Card title="Schema" description="Learn about the database schema." href="/docs/web/database/schema" />

  <Card title="Migrations" description="Migrate your changes to the database." href="/docs/web/database/migrations" />

  <Card title="Database client" description="Use database client to interact with the database." href="/docs/web/database/client" />
</Cards>


file: ./src/content/docs/extension/extras.mdx
meta: {
  "title": "Extras",
  "description": "See what you get together with the code.",
  "icon": "Gift",
  "mirror": "../web/extras.mdx"
}
        


file: ./src/content/docs/extension/faq.mdx
meta: {
  "title": "FAQ",
  "description": "Find answers to common technical questions.",
  "icon": "Question",
  "mirror": "../web/faq.mdx"
}
        


file: ./src/content/docs/extension/index.mdx
meta: {
  "title": "Introduction",
  "description": "Get started with TurboStarter extension kit.",
  "icon": "Home",
  "index": true,
  "mirror": "../web/index.mdx"
}
        


file: ./src/content/docs/extension/internationalization.mdx
meta: {
  "title": "Internationalization",
  "description": "Learn how to internationalize your extension."
}
        
Turbostarter's extension uses [i18next](https://www.i18next.com/) and web cookies to store the language preference of the user. This allows the extension to be fully internationalized.

<Callout title="Why this combination?">
  We use i18next because it's a robust and widely-adopted internationalization framework that works seamlessly with React.

  The combination with web cookies allows us to persistently store language preferences across all extension contexts and share it with the web app while maintaining excellent performance and browser compatibility.
</Callout>

![i18next logo](/images/docs/i18next.jpg)

## Configuration

The global configuration is defined in the `@turbostarter/i18n` package and shared across all applications. You can read more about it in the [web configuration](/docs/web/internationalization/configuration) documentation.

By default, the locale is automatically detected based on the user's device settings. You can override it and set the default locale of your mobile app in the [app configuration](/docs/extension/configuration/app) file.

Also, the locale configuration is **shared between the web app and the extension** (same as [session](/docs/extension/auth/session)), which means that changing the locale in one place will automatically update it in the other. It's a common pattern for modern apps, simplifying the user experience and reducing the maintenance effort.

### Cookies

When a user first opens the [web app](/docs/web), the locale is detected and a cookie is set. This cookie is used to remember the user's language preference.

You can find its value in the *Cookies* tab of the developer tools of your browser:

![Locale cookie](/images/docs/extension/locale-cookie.png)

To enable your extension to read the cookie and that way share the locale settings with the web app, you need to set the cookies permission in the `wxt.config.ts` under `manifest.permissions` field:

```ts
export default defineConfig({
  manifest: {
    permissions: ["cookies"],
  },
});
```

And to be able to read the cookie from your app url, you need to set host\_permissions, which will include your app url:

```ts
export default defineConfig({
  manifest: {
    host_permissions: ["http://localhost/*", "https://your-app-url.com/*"],
  },
});
```

Then you would be able to share the cookie between your apps and also read its value using `browser.cookies` API.

<Callout title="Avoid &#x22;<all_urls>&#x22;" type="warn">
  Avoid using `<all_urls>` in `host_permissions`. It affects all urls and may cause security issues, as well as a [rejection](https://developer.chrome.com/docs/webstore/review-process#review-time-factors) from the destination store.
</Callout>

<Cards>
  <Card title="Declare permissions" href="https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions" description="developer.chrome.com" />

  <Card title="chrome.cookies" href="https://developer.chrome.com/docs/extensions/reference/api/cookies" description="developer.chrome.com" />
</Cards>

## Translating extension

To translate individual components and screens, you can use the well-known `useTranslation` hook.

```tsx
import { useTranslation } from "@turbostarter/i18n";

export const Popup = () => {
  const { t } = useTranslation();

  return <div>{t("hello")}</div>;
};
```

That's the recommended way to translate stuff inside your extension.

### Store presence

As we saw in the [manifest](/docs/extension/configuration/manifest#locales) section, you can also localize your extension's store presence (like title, description, and other metadata). This allows you to customize how your extension appears in different web stores based on the user's language.

Each store has specific requirements for localization:

* [Chrome Web Store](https://developer.chrome.com/docs/webstore/cws-dashboard-listing/) requires a `_locales` directory with JSON files for each language
* [Firefox Add-ons](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization) uses a similar structure but with some differences in the manifest

Although most of the config is abstracted behind common structure, please follow the store-specific guides below for detailed instructions on setting up localization for your extension's store listing.

<Cards>
  <Card title="I18n - WXT" href="https://wxt.dev/guide/essentials/i18n.html" description="wxt.dev" />

  <Card title="Chrome Web Store" href="https://developer.chrome.com/docs/webstore/cws-dashboard-listing" description="developer.chrome.com" />

  <Card title="Firefox Add-ons" href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization" description="developer.mozilla.org" />
</Cards>

## Language switcher

TurboStarter ships with a language switcher component that allows users to switch between languages in your extension. You can import and use the `LocaleSwitcher` component in your popup, options page, or any other extension view:

```tsx
import { LocaleSwitcher } from "@turbostarter/ui-web";

export const Popup = () => {
  return <LocaleSwitcher />;
};
```

<Callout title="This will change the locale of the web app as well" type="warn">
  As the web app and extension share the same i18n configuration (cookie), changing the language in one will affect the other. **This is intentional** and ensures a consistent experience across both platforms, since your extension likely serves as a companion to the web app and should maintain the same language preferences.
</Callout>

## Best practices

Here are key best practices for managing translations in your browser extension:

* Use descriptive, hierarchical translation keys

  ```ts
  // ✅ Good
  "popup.settings.language";
  "content.toolbar.save";

  // ❌ Bad
  "saveButton";
  "text1";
  ```

* Organize translations by extension views and features

  ```
  _locales/
  ├── en/
  │   ├── messages.json
  │   ├── popup.json
  │   └── options.json
  └── es/
      ├── messages.json
      ├── popup.json
      └── options.json
  ```

* Handle fallback languages gracefully

* Keep manifest descriptions localized for store listings

* Consider context in translations:

  ```ts
  // Context-aware messages
  t("button.save", { context: "document" }); // "Save document"
  t("button.save", { context: "settings" }); // "Apply changes"
  ```

* Use placeholders for dynamic content:

  ```ts
  // With variables
  t("status.saved", { time: "2 minutes ago" }); // "Last saved 2 minutes ago"

  // With plurals
  t("items", { count: 5 }); // "5 items"
  ```

* Keep translations in sync between extension views

* Cache translations for offline functionality


file: ./src/content/docs/extension/marketing.mdx
meta: {
  "title": "Marketing",
  "description": "Learn how to market your mobile application."
}
        
As you saw in the [Extras](/docs/extension/extras) section, TurboStarter comes with a lot of tips and tricks to make your product better and help you launch your extension faster with higher traffic.

The same applies to [submission tips](/docs/extension/extras#submission-tips) to help you get your extension approved by the browser stores faster.

We'll talk more about the whole process of deploying and publishing your extension in the [Publishing](/docs/extension/publishing/checklist) section, here we'll go through some guidelines that you need to follow to make your store's visibility higher.

## Before you submit

To help your extension approval go as smoothly as possible, review the common missteps listed below that can slow down the review process or trigger a rejection. This doesn't replace the official guidelines or guarantee approval, but making sure you can check every item on the list is a good start.

Make sure you:

* Test your extension thoroughly for crashes and bugs
* Ensure that all extension information and metadata is complete and accurate
* Update your contact information in case the review team needs to reach you
* Provide clear instructions on how to use your extension, including any special setup required
* If your extension requires an account, provide a demo account or a way to test all features without signing up
* Enable and test all backend services to ensure they're live and accessible during review
* Include detailed explanations of non-obvious features in the extension description
* Ensure your extension complies with the specific browser store's policies (e.g., [Chrome Web Store](https://developer.chrome.com/docs/webstore/program-policies/best-practices), [Firefox Add-ons](https://extensionworkshop.com/documentation/publish/add-on-policies/), etc.)
* Remove any references to features not supported in browser extensions (e.g., in-app purchases)

Following these basic steps during development and before submission will help you get your extension approved faster and with fewer issues.

## Guidelines

Each store has slightly different guidelines, but some of them are general and can be applied to all stores:

* **Security**: Your extension must not contain malicious code or behavior that can harm users' devices or data.
* **Performance**: Your extension must be performant and stable, with a smooth user experience.
* **Privacy**: Your extension must respect user privacy and not collect unnecessary data without explicit consent.
* **Compliance**: Your extension must comply with all relevant laws and regulations.

You can read more about official guidelines for each store in the following links:

* [Chrome Web Store](https://developer.chrome.com/docs/webstore/program-policies/best-practices)
* [Firefox Add-ons](https://extensionworkshop.com/documentation/publish/add-on-policies/)

## Common mistakes

There are a few common mistakes that you should avoid to make sure your extension can be accepted in the stores. The most common ones are:

* **Not enough description** - make sure to describe all the features of your extension and how it works in your store listing, that way users won't be confused about what your extension does. Also include detailed information in the single purpose field regarding your extension's primary functionality.
* **Privacy issues** - respect user privacy and require as least permissions as possible, don't ask for permissions that are not necessary for your extension to work
* **Customer support** - provide a way to contact you in case the user has any issues with your extension
* **Stay up-to-date** - keep your extension and its documentation up-to-date to ensure a smooth user experience and to prevent issues during the review process.

<Cards>
  <Card href="https://developer.chrome.com/docs/webstore/program-policies/best-practices" title="Best Practices and Guidelines" description="developer.chrome.com" />

  <Card href="https://extensionworkshop.com/documentation/publish/add-on-policies/" title="Add-on Policies" description="extensionworkshop.com" />
</Cards>


file: ./src/content/docs/extension/stack.mdx
meta: {
  "title": "Tech Stack",
  "description": "A detailed look at the technical details.",
  "icon": "Tools"
}
        
## Turborepo

[Turborepo](https://turbo.build/) is a monorepo tool that helps you manage your project's dependencies and scripts. We chose a monorepo setup to make it easier to manage the structure of different features and enable code sharing between different packages.

<Card href="https://turbo.build/" title="Turborepo - Make Ship Happen" description="turbo.build" />

## WXT (Vite)

> It's like Next.js for browser extensions.

[WXT](https://www.wxt.dev/) is a very lightweight and powerful framework (based on [Vite](https://vite.dev/)) for building browser extensions using most popular frontend tools. It provides a modern development experience with features like hot module reloading, TypeScript support, and automatic manifest generation.

WXT simplifies the process of creating cross-browser extensions, allowing you to focus on your extension's functionality rather than boilerplate setup.

<Cards>
  <Card href="https://www.wxt.dev/" title="WXT" description="wxt.dev" />

  <Card href="https://www.vite.dev/" title="Vite" description="vite.dev" />
</Cards>

## React

[React](https://reactjs.org/) is a JavaScript library for building user interfaces. It's the core technology we use for creating the UI of our browser extension, allowing for efficient updates and rendering of components.

<Card href="https://reactjs.org/" title="React" description="reactjs.org" />

## Tailwind CSS

[Tailwind CSS](https://tailwindcss.com) is a utility-first CSS framework that helps you build custom designs without writing any CSS. We also use [Radix UI](https://radix-ui.com) for our headless components library and [shadcn/ui](https://ui.shadcn.com) which enables you to generate pre-designed components with a single command.

<Cards className="grid-cols-2 sm:grid-cols-3">
  <Card href="https://tailwindcss.com" title="Tailwind CSS" description="tailwindcss.com" />

  <Card href="https://radix-ui.com" title="Radix UI" description="radix-ui.com" />

  <Card href="https://ui.shadcn.com" title="shadcn/ui" description="ui.shadcn.com" />
</Cards>

## Hono

[Hono](https://hono.dev) is a small, simple, and ultrafast web framework for the edge. It provides tools to help you build APIs and web applications faster. It includes an RPC client for making type-safe function calls from the frontend. We use Hono to build our serverless API endpoints.

<Card href="https://hono.dev" title="Hono" description="hono.dev" />

## Better Auth

[Better Auth](https://www.better-auth.com) is a modern authentication library for fullstack applications. It provides ready-to-use snippets for features like email/password login, magic links, OAuth providers, and more. We use Better Auth to handle all authentication flows in our application.

<Card href="https://www.better-auth.com" title="Better Auth" description="better-auth.com" />

## Drizzle

[Drizzle](https://orm.drizzle.team/) is a super fast [ORM](https://orm.drizzle.team/docs/overview) (Object-Relational Mapping) tool for databases. It helps manage databases, generate TypeScript types from your schema, and run queries in a fully type-safe way.

We use [PostgreSQL](https://www.postgresql.org) as our default database, but thanks to Drizzle's flexibility, you can easily switch to MySQL, SQLite or any [other supported database](https://orm.drizzle.team/docs/connect-overview) by updating a few configuration lines.

<Cards>
  <Card href="https://orm.drizzle.team/" title="Drizzle" description="orm.drizzle.team" />

  <Card href="https://www.postgresql.org" title="PostgreSQL" description="postgresql.org" />
</Cards>


file: ./src/content/docs/mobile/ai.mdx
meta: {
  "title": "AI",
  "description": "Learn how to use AI integration in your mobile app."
}
        
As AI integration for [web](/docs/web/ai/overview), [extension](/docs/extension/ai), and mobile is based on the same battle-tested [Vercel AI SDK](https://sdk.vercel.ai/docs/introduction), the implementation is very similar across platforms.

In this section, we'll focus on how to consume AI responses in the mobile app. For server-side implementation details, please refer to the [web documentation](/docs/web/ai/overview).

## Features

The most common AI integration features are also supported in the mobile app:

* **Chat**: Build chat interfaces inside native mobile apps.
* **Streaming**: Receive AI responses as soon as the model starts generating them, without waiting for the full response to be completed.
* **Image generation**: Generate images based on a given prompt.

You can easily compose your application using these building blocks or extend them to suit your specific needs.

## Usage

The usage of AI integration in the mobile app is the same as for [web app](/docs/web/ai/configuration#client-side) and [browser extension](/docs/extension/ai#server--client). We use the exact same [API endpoint](/docs/web/ai/configuration#api-endpoint), and since TurboStarter ships with built-in support for streaming on mobile, we can leverage it to display answers incrementally to the user as they're generated.

```tsx title="ai.tsx"
import { useChat } from "ai/react";

const AI = () => {
  const { messages } = useChat({
    api: "/api/ai/chat",
  });

  return (
    <View>
      {messages.map((message) => (
        <Text key={message.id}>{message.content}</Text>
      ))}
    </View>
  );
};

export default AI;
```

By leveraging this integration, we can easily manage the state of the AI request and update the UI as soon as the response is ready.

TurboStarter ships with a ready-to-use implementation of AI chat, allowing you to see this solution in action. Feel free to reuse or modify it according to your needs.


file: ./src/content/docs/mobile/billing.mdx
meta: {
  "title": "Billing",
  "description": "Get started with billing in TurboStarter."
}
        
<Callout title="Fully-featured billing on mobile is coming soon">
  For now, billing has a limited functionalities on mobile, we're mostly relying on the [web app](/docs/web/billing/overview) to handle billing.

  We are working on a fully-featured mobile billing to help you monetize your mobile app easier. Stay tuned for updates.

  [See roadmap](https://github.com/orgs/turbostarter/projects/1)
</Callout>

## Fetching customer data

When your user purchased a plan from your landing page or web app, you can easily fetch their data using the [API](/docs/mobile/api/client).

To do so, just call the `/api/billing/customer` endpoint:

```tsx title="customer-screen.tsx"
import { api } from "~/lib/api";

export default function CustomerScreen() {
  const { data: customer, isLoading } = useQuery({
    queryKey: ["customer"],
    queryFn: () => handle(api.billing.customer.$get()),
  });

  if (isLoading) return <Text>Loading...</Text>;

  return <Text>{customer?.plan}</Text>;
}
```

You may also want to ensure that user is logged in before fetching their billing data to avoid unnecessary API calls.

```tsx title="customer-screen.tsx"
import { api } from "~/lib/api";

export default function CustomerScreen() {
  const {
    data: { user },
  } = useSession();

  const { data: customer } = useQuery({
    queryKey: ["customer"],
    queryFn: () => handle(api.billing.customer.$get()),
    enabled: !!user, // [!code highlight]
  });

  if (!user || !customer) {
    return null;
  }

  return (
    <View>
      <Text>{user.email}</Text>
      <Text>{customer.plan}</Text>
    </View>
  );
}
```

<Callout title="Be cautious!" type="warn">
  Be mindful when implementing payment-related features in your mobile app. Apple has strict guidelines regarding external payment systems and **may reject your app** if you aggressively redirect users to web-based payment flows. Make sure to review the [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#payments) carefully and consider implementing native in-app purchases for iOS users to ensure compliance.

  We are currently working on a fully native payments system that will make it easier to comply with Apple's guidelines - stay tuned for updates!
</Callout>


file: ./src/content/docs/mobile/cli.mdx
meta: {
  "title": "CLI",
  "description": "Start your new project with a single command.",
  "icon": "Command",
  "mirror": "../web/cli.mdx"
}
        


file: ./src/content/docs/mobile/database.mdx
meta: {
  "title": "Database",
  "description": "Get started with the database."
}
        
<Callout type="error" title="API deployment required">
  To enable communication between your Expo app and the server in a production environment, the web application with Hono API must be deployed first.

  <Cards>
    <Card title="API" description="Learn more about the API." href="/docs/web/api/overview" />

    <Card title="Web deployment" description="Deploy your web application to production." href="/docs/web/deployment/checklist" />
  </Cards>
</Callout>

As a mobile app uses only client-side code, **there's no way to interact with the database directly**.

Also, you should avoid any workarounds to interact with the database directly, because it can lead to leaking your database credentials and other security issues.

## Recommended approach

You can safely use the [API](/docs/mobile/api/overview) and call the endpoints which will run queries on the database.

To do this you need to set up the database on the [web, server side](/docs/web/database/overview) and then use the [API client](/docs/mobile/api/client) to interact with it.

Learn more about its configuration in the web part of the docs, especially in the following sections:

<Cards>
  <Card title="Overview" description="Get started with the database" href="/docs/web/database/overview" />

  <Card title="Schema" description="Learn about the database schema." href="/docs/web/database/schema" />

  <Card title="Migrations" description="Migrate your changes to the database." href="/docs/web/database/migrations" />

  <Card title="Database client" description="Use database client to interact with the database." href="/docs/web/database/client" />
</Cards>


file: ./src/content/docs/mobile/extras.mdx
meta: {
  "title": "Extras",
  "description": "See what you get together with the code.",
  "icon": "Gift",
  "mirror": "../web/extras.mdx"
}
        


file: ./src/content/docs/mobile/faq.mdx
meta: {
  "title": "FAQ",
  "description": "Find answers to common technical questions.",
  "icon": "Question",
  "mirror": "../web/faq.mdx"
}
        


file: ./src/content/docs/mobile/index.mdx
meta: {
  "title": "Introduction",
  "description": "Get started with TurboStarter mobile kit.",
  "icon": "Home",
  "index": true,
  "mirror": "../web/index.mdx"
}
        


file: ./src/content/docs/mobile/internationalization.mdx
meta: {
  "title": "Internationalization",
  "description": "Learn how to internationalize your mobile app."
}
        
TurboStarter mobile uses [i18next](https://www.i18next.com/) and [expo-localization](https://docs.expo.dev/versions/latest/sdk/localization/) for internationalization. This powerful combination allows you to leverage both i18next's mature translation framework and Expo's native device locale detection.

<Callout title="Why this combination?">
  While i18next handles the translation management, expo-localization provides
  seamless integration with the device's locale settings. This means your app
  can automatically detect and adapt to the user's preferred language, while
  still maintaining the flexibility to override it when needed.
</Callout>

The mobile app's internationalization is configured to work out of the box with:

* Automatic device language detection
* Right-to-left (RTL) layout support
* Locale-aware date and number formatting
* Fallback language handling

You can read more about the underlying technologies in their documentation:

* [i18next documentation](https://www.i18next.com/overview/getting-started)
* [expo-localization documentation](https://docs.expo.dev/versions/latest/sdk/localization/)

![i18next logo](/images/docs/i18next.jpg)

## Configuration

The global configuration is defined in the `@turbostarter/i18n` package and shared across all applications. You can read more about it in the [web configuration](/docs/web/internationalization/configuration) documentation.

By default, the locale is automatically detected based on the user's device settings. You can override it and set the default locale of your mobile app in the [app configuration](/docs/mobile/configuration/app) file.

## Translating app

To translate individual components and screens, you can use the `useTranslation` hook.

```tsx
import { useTranslation } from "@turbostarter/i18n";

export default function MyComponent() {
  const { t } = useTranslation();

  return <Text>{t("hello")}</Text>;
}
```

It's a recommended way to translate your app.

### Store presence

If you plan on shipping your app to different countries or regions or want it to support various languages, you can provide localized strings for things like the display name and system dialogs.

To do so, check the [official Expo documentation](https://docs.expo.dev/guides/localization/) as it requires modifying your app configuration (`app.config.ts`).

You can find the resources below helpful in this process:

<Cards>
  <Card title="Expo Localization" href="https://docs.expo.dev/guides/localization/" description="docs.expo.dev" />

  <Card title="Apple App Store Localization" href="https://developer.apple.com/localization/" description="developer.apple.com" />

  <Card title="Google Play Localization" href="https://support.google.com/googleplay/android-developer/answer/9844778?hl=en" description="support.google.com" />
</Cards>

## Language switcher

TurboStarter ships with a language switcher component that allows you to switch between languages. You can import and use the `LocaleSwitcher` component and drop it anywhere in your application to allow users to change the language seamlessly.

```tsx
import { LocaleSwitcher } from "@turbostarter/ui-mobile";

export default function MyComponent() {
  return <LocaleSwitcher />;
}
```

The component automatically displays all languages configured in your i18n settings. When a user switches languages, it will be reflected in the app and saved into persistent storage to keep the language across app restarts.

## Best practices

Here are key best practices for managing translations in your mobile app:

* Use clear, hierarchical translation keys for easy maintenance

  ```ts
  // ✅ Good
  "screen.home.welcome";
  "component.button.submit";

  // ❌ Bad
  "welcomeText";
  ```

* Organize translations by app screens and features

  ```
  translations/
  ├── en/
  │   ├── layout.json
  │   └── common.json
  └── es/
      ├── layout.json
      └── common.json
  ```

* Consider device language settings and regional formats

* Cache translations locally for offline access

* Handle dynamic content for mobile contexts:

  ```ts
  // Device-specific messages
  t("errors.noConnection"); // "Check your internet connection"

  // Dynamic values
  t("storage.space", { gb: 2.5 }); // "2.5 GB available"
  ```

* Keep translations concise - mobile screens have limited space

* Test translations with different screen sizes and orientations


file: ./src/content/docs/mobile/marketing.mdx
meta: {
  "title": "Marketing",
  "description": "Learn how to market your mobile application."
}
        
As you saw in the [Extras](/docs/mobile/extras) section, TurboStarter comes with a lot of tips and tricks to make your product better and help you launch your app faster with higher traffic.

The same applies to [submission tips](/docs/mobile/extras#submission-tips) to help you get your app approved by Apple and Google faster.

We'll talk more about the whole process of deploying and publishing your app in the [Publishing](/docs/mobile/publishing/checklist) section, here we'll go through some guidelines that you need to follow to make your store's visibility higher.

## Before you submit

To help your app approval go as smoothly as possible, review the common missteps listed below that can slow down the review process or trigger a rejection. This doesn't replace the official guidelines or guarantee approval, but making sure you can check every item on the list is a good start.

Make sure you:

* Test your app for crashes and bugs
* Ensure that all app information and metadata is complete and accurate
* Update your contact information in case App Review needs to reach you
* Provide App Review with full access to your app. If your app includes account-based features, provide either an active demo account or fully-featured demo mode, plus any other hardware or resources that might be needed to review your app (e.g. login credentials or a sample QR code)
* Enable backend services so that they're live and accessible during review
* Include detailed explanations of non-obvious features and in-app purchases in the App Review notes, including supporting documentation where appropriate

Following these basic steps during development and before submission will help you get your app approved faster.

## App Store (iOS)

Apple reviews are much stricter than Google reviews, so you need to make sure your app is ready for the App Store.

### Guidelines

Apple has a set of [guidelines](https://developer.apple.com/app-store/review/guidelines/) that you need to follow to make sure your app can be accepted in the App Store.

These include:

* **Safety**: Your app must not contain content or behavior that is harmful, abusive, or threatening.
* **Performance**: Your app must be performant and stable, with a smooth user experience.
* **Business**: Your app must not engage in unethical or deceptive practices.
* **Design**: Your app must have a clean and intuitive design.
* **Legal**: Your app must comply with all relevant laws and regulations.

You can read more about each guideline in the [official App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/).

### Search optimization

App store optimization is the process of increasing an app or game's visibility in an app store, with the objective of increasing organic app downloads. Apps are more visible when they rank high on a wide variety of search terms, maintain a high position in the top charts, or get featured on the store.

There are a few actions that you can take to improve your app's visibility in the App Store:

* **Choose accurate keywords**: Use relevant keywords in your app's store listing.
* **Create a compelling app name, subtitle, and description**: Your app's title should be catchy and descriptive, the same applies to the subtitle and description.
* **Assign the right categories**: Make sure your app is categorized in the right category, this will help you reach the right audience.
* **Foster positive ratings**: Ratings and reviews appear on your product page and influence how your app ranks in search results. They can encourage people to engage with your app, so focus on providing a great app experience that motivates users to leave positive reviews.
* **Publish in-app events**: You can publish in-app events to promote your app and encourage users to engage with your app. (e.g. game competitions)
* **Promote in-app purchases**: Your promoted in-app purchases appear in search results on the App Store. Tapping an in-app purchase leads to your product page, which displays your app's description, screenshots, app previews, and in-app events — and lets people initiate an in-app purchase.

Read more about App Store Optimization in the [official documentation](https://developer.apple.com/app-store/search/).

<Cards>
  <Card title="App Review Guidelines" href="https://developer.apple.com/app-store/review/guidelines/" description="Official Apple App Store Review Guidelines" />

  <Card title="Search Optimization" href="https://developer.apple.com/app-store/search/" description="Apple's guide on App Store Search Optimization" />
</Cards>

## Google Play Store (Android)

Google reviews are less stringent than Apple reviews and usually take less time to review, but you still need to make sure your app is ready for the Play Store.

### Guidelines

Google has its own guidelines that apps must adhere to. Some important aspects to consider include:

* **Spam, functionality, and user experience**: Your app must not be spammy, must work as expected and must provide a good user experience.
* **Restricted content**: Before submitting an app to Google Play, ensure it complies with these content policies and with local laws.
* **Privacy**: Apps that are deceptive, malicious, or intended to abuse or misuse any network, device, or personal data are strictly prohibited
* **Monetization**: Your app must not engage in unethical or deceptive practices.

For more detailed information and an interactive checklist, check the [Google requirements page](https://developers.google.com/workspace/marketplace/about-app-review).

### Search optimization

Ensuring that your app and store listing is thorough and optimized is an important factor in getting discovered by users on Google Play.

Follow these steps to optimize your app's visibility on Google Play:

* **Build a comprehensive store listing**: This includes providing accurate **title**, **description** and **promo text**.
* **Use high-quality graphics and images**: App icons, images, and screenshots help make your app stand out in search results, categories, and featured app lists.
* **Diversify your audience**: Google provides automated machine translations of store listings that you don't explicitly define for your app. However, using a professional translation service for your *Description* can lead to better search results and discoverability for worldwide users.
* **Create a great user experience**: Google Play search factors in the overall experience of your app based on user behavior and feedback. Apps are ranked based on a combination of ratings, reviews, downloads, and other factors.

<Cards>
  <Card title="Prepare your app for review" href="https://support.google.com/googleplay/android-developer/answer/9859455" description="Google Play's guide on preparing your app for review" />

  <Card title="Get discovered on Google Play search" href="https://support.google.com/googleplay/android-developer/answer/4448378" description="Google's guide on improving app discoverability" />
</Cards>

## Common mistakes

There are a few common mistakes that you should avoid to make sure your app can be accepted in the stores. Apple reports that, on average, over **40%** of unresolved issues relate to [guideline 2.1: App Completeness](https://developer.apple.com/app-store/review/guidelines/#2.1), so make sure to avoid these:

* **Crashes and bugs**
* **Broken links**
* **Placeholder content**
* **Incomplete information**
* **Privacy policy issues**
* **Inaccurate screenshots**
* **Repeated submission of similar apps**

Don't worry if your first submission is rejected, improve it, fix all the mentioned issues and try again.


file: ./src/content/docs/mobile/push-notifications.mdx
meta: {
  "title": "Push notifications",
  "description": "Engage your users with personalized notifications."
}
        
<Callout title="Push notifications are coming soon" type="info">
  We are working on push notifications to help you engage your users. Stay tuned for updates.

  [See roadmap](https://github.com/orgs/turbostarter/projects/1)
</Callout>


file: ./src/content/docs/mobile/stack.mdx
meta: {
  "title": "Tech Stack",
  "description": "A detailed look at the technical details.",
  "icon": "Tools"
}
        
## Turborepo

[Turborepo](https://turbo.build/) is a monorepo tool that helps you manage your project's dependencies and scripts. We chose a monorepo setup to make it easier to manage the structure of different features and enable code sharing between different packages.

<Card href="https://turbo.build/" title="Turborepo - Make Ship Happen" description="turbo.build" />

## React Native + Expo

[React Native](https://reactnative.dev/) is an open-source mobile application development framework created by Facebook. It is used to develop applications for Android and iOS by enabling developers to use [React](https://react.dev) along with native platform capabilities.

> It's like Next.js for mobile development.

[Expo](https://expo.dev/) is a framework and a platform built around React Native. It provides a set of tools and services that help you develop, build, deploy, and quickly iterate on iOS, Android, and web apps from the same JavaScript/TypeScript codebase. It's like Next.js for mobile development.

<Cards className="grid-cols-2">
  <Card href="https://reactnative.dev/" title="React Native" description="reactnative.dev" />

  <Card href="https://expo.dev/" title="Expo" description="expo.dev" />
</Cards>

## Tailwind CSS

[NativeWind](https://www.nativewind.dev/) uses Tailwind CSS as scripting language to create a universal style system for React Native. It allows you to use Tailwind CSS classes in your React Native components, providing a familiar styling experience for web developers. We also use [React Native Reusables](https://github.com/mrzachnugent/react-native-reusables) for our headless components library with support of CLI to generate pre-designed components with a single command.

<Cards className="grid-cols-2">
  <Card href="https://www.nativewind.dev/" title="NativeWind" description="nativewind.dev" />

  <Card href="https://github.com/mrzachnugent/react-native-reusables" title="react-native-reusables" description="github.com" />
</Cards>

## Hono

[Hono](https://hono.dev) is a small, simple, and ultrafast web framework for the edge. It provides tools to help you build APIs and web applications faster. It includes an RPC client for making type-safe function calls from the frontend. We use Hono to build our serverless API endpoints.

<Card href="https://hono.dev" title="Hono" description="hono.dev" />

## Better Auth

[Better Auth](https://www.better-auth.com) is a modern authentication library for fullstack applications. It provides ready-to-use snippets for features like email/password login, magic links, OAuth providers, and more. We use Better Auth to handle all authentication flows in our application.

<Card href="https://www.better-auth.com" title="Better Auth" description="better-auth.com" />

## Drizzle

[Drizzle](https://orm.drizzle.team/) is a super fast [ORM](https://orm.drizzle.team/docs/overview) (Object-Relational Mapping) tool for databases. It helps manage databases, generate TypeScript types from your schema, and run queries in a fully type-safe way.

We use [PostgreSQL](https://www.postgresql.org) as our default database, but thanks to Drizzle's flexibility, you can easily switch to MySQL, SQLite or any [other supported database](https://orm.drizzle.team/docs/connect-overview) by updating a few configuration lines.

<Cards>
  <Card href="https://orm.drizzle.team/" title="Drizzle" description="orm.drizzle.team" />

  <Card href="https://www.postgresql.org" title="PostgreSQL" description="postgresql.org" />
</Cards>

## EAS (Expo Application Services)

[EAS](https://expo.dev/eas) is a set of cloud services provided by Expo for React Native app development. It includes tools for building, submitting, and updating your app, as well as over-the-air updates and analytics.

<Card href="https://expo.dev/eas" title="EAS (Expo Application Services)" description="expo.dev/eas" />


file: ./src/content/docs/web/cli.mdx
meta: {
  "title": "CLI",
  "description": "Start your new project with a single command.",
  "icon": "Command"
}
        
<CliDemo />

To help you get started with TurboStarter **as quickly as possible**, we've developed a [CLI](https://www.npmjs.com/package/@turbostarter/cli) that enables you to create a new project (with all the configuration) in seconds.

The CLI is a set of commands that will help you create a new project, generate code, and manage your project efficiently.

Currently, the following action is available:

* **Starting a new project** - Generate starter code for your project with all necessary configurations in place (billing, database, emails, etc.)

**The CLI is in beta**, and we're actively working on adding more commands and actions. Soon, the following features will be available:

* **Translations** - Translate your project, verify translations, and manage them effectively
* **Installing plugins** - Easily install plugins for your project
* **Dynamic code generation** - Generate dynamic code based on your project structure

## Installation

You can run commands using `npx`:

```bash
npx turbostarter <command>
npx @turbostarter/cli@latest <command>
```

<Callout>
  If you don't want to install the CLI globally, you can simply replace the examples below with `npx @turbostarter/cli@latest` instead of `turbostarter`.

  This also allows you to always run the latest version of the CLI without having to update it.
</Callout>

## Usage

Running the CLI without any arguments will display the general information about the CLI:

```bash
Usage: turbostarter [options] [command]

Your Turbo Assistant for starting new projects, adding plugins and more.

Options:
  -v, --version   display the version number
  -h, --help      display help for command

Commands:
  new             create a new TurboStarter project
  help [command]  display help for command
```

You can also display help for it or check the actual version.

### Starting a new project

Use the `new` command to initialize configuration and dependencies for a new project.

```bash
npx turbostarter new
```

You will be asked a few questions to configure your project:

```bash
✔ All prerequisites are satisfied, let's start! 🚀

? What do you want to ship? ›
    ◉   Web app
    ◉   Mobile app
    ◯   Browser extension
? Enter your project name. ›
? How do you want to use database? ›
    Local (powered by Docker)
    Cloud
? What do you want to use for billing? ›
    Stripe
    Lemon Squeezy

...

🎉 You can now get started. Open the project and just ship it! 🎉

Problems? https://turbostarter.dev/docs
```

It will create a new project, configure providers, install dependencies and start required services in development mode.


file: ./src/content/docs/web/extras.mdx
meta: {
  "title": "Extras",
  "description": "See what you get together with the code.",
  "icon": "Gift"
}
        
## Tips and Tricks

In many places, next to the code you will find some marketing tips, design suggestions, and potential risks. This is to help you build a better product and avoid common pitfalls.

```tsx title="Hero.tsx"
import Hero from "~/components/Hero";

return (
  <header>
    {/* 💡 Use something that user can visualize e.g. 
    "Ship your startup while on the toilet" */}
    <h1>Best startup on the world</h1>
  </header>
);
```

### Submission tips

When it comes to mobile app and browser extension, you must submit your product to review from Apple/Google etc. We have some tips for you to make sure your submission goes smoothly.

```json title="app.json"
{
  "ios": {
    "infoPlist": {
      /* 🍎 add descriptive justification of using this permission on iOS */
      "NSCameraUsageDescription": "This app uses the camera to scan barcodes on event tickets."
    }
  }
}
```

As well as providing you with the info on how to make your store listings better:

```json title="package.json"
{
  "manifest": {
    /* 💡 Use localized messages to get more visibility in web stores */
    "name": "__MSG_extensionName__",
    "default_locale": "en"
  }
}
```

## Discord community

We have a Discord community where you can ask questions and share your projects. It's a great place to get help and meet other developers.

<DiscordCta />

![Discord](/images/docs/discord.png)

## 25+ SaaS Ideas

Not sure what to build? We have a list of **25+** SaaS ideas that you can use to get started.

Grouped by category, these ideas are a great way to get inspired and start building your next project.

Including design, copies, marketing tips and potential risks, this list is a great resource for anyone looking to build a SaaS product.

![SaaS Ideas](/images/docs/saas-ideas.png)


file: ./src/content/docs/web/faq.mdx
meta: {
  "title": "FAQ",
  "description": "Find answers to common technical questions.",
  "icon": "Question"
}
        
## Why isn't everything hidden and configured with one BIG config file?

TurboStarter intentionally exposes the underlying code rather than hiding it behind configuration files (like some starters do). This design choice follows our **you own your code** philosophy, giving you full control and flexibility over your codebase.

While a single config file might seem simpler initially, it often becomes restrictive when you need to customize functionality beyond what the config allows. With direct access to the code, you can modify any part of the system to match your specific requirements.

## I don't know some technology! Should I buy TurboStarter?

You should be prepared for a learning curve or consider learning it first. However, TurboStarter will still work for you if you're willing to learn.

Even without knowing some technologies, you can still use the rest of the features.

## I don't need mobile app or browser extension, what should I do?

You can simply ignore the mobile app and browser extension parts of the project. You can remove the `apps/mobile` and `apps/extension` directories from the project.

The modular nature of TurboStarter allows you to remove parts of the project that you don't need without affecting the rest of the stack.

## I want to use a different provider for X

Sure! TurboStarter is designed to be modular, so configuring new provider (e.g. for emails, billing or any other service) is straightforward. You just need to make sure your configuration is compatible with common interface to be able to plug it into the codebase.

## Will you add more packages in the future?

Yes, we will keep updating TurboStarter with new packages and features. This kit is designed to be modular, allowing for new features and packages to be added without interfering with your existing code. You can always [update your project](/docs/web/installation/update) to the latest version.

## Does it set up the production instance for me?

No, TurboStarter does not set up the production instance for you. This includes setting up databases, Stripe, or any other services you need. TurboStarter does not have access to your Stripe or Resend accounts, so setup on your end is required. TurboStarter provides the codebase and documentation to help you set up your SaaS project.

## Does the starter include Solito?

No. Solito will not be included in this repo. It is a great tool if you want to share code between your Next.js and Expo app. However, the main purpose of this repo is not the integration between Next.js and Expo — it's the code splitting of your SaaS platforms into a monorepo. You can utilize the monorepo with multiple apps, and it can be any app such as Vite, Electron, etc.

Integrating Solito into this repo isn't hard, and there are a few [official templates](https://github.com/nandorojo/solito/tree/master/example-monorepos) by the creators of Solito that you can use as a reference.

## Does this pattern leak backend code to my client applications?

No, it does not. The `api` package should only be a production dependency in the Next.js application where it's served. The Expo app, browser extension, and all other apps you may add in the future should only add the `api` package as a dev dependency. This lets you have full type safety in your client applications while keeping your backend code safe.

If you need to share runtime code between the client and server, you can create a separate `shared` package for this and import it on both sides.

## How do I get support if I encounter issues?

For support, you can:

1. Visit our [Discord](https://discord.gg/KjpK2uk3JP)
2. Contact us via support email ([hello@turbostarter.dev](mailto:hello@turbostarter.dev))

## How do I deploy my application?

Please check the [production checklist](/docs/web/deployment/checklist) for more information.

## How do I update my project when a new version of the boilerplate is released?

Please read the [documentation for updating your TurboStarter code](/docs/web/installation/update).

## Can I use the React package X with this kit?

Yes, you can use any React package with this kit. The kit is based on React, so you are generally only constrained by the underlying technologies and not by the kit itself. Since you own and can edit all the code, you can adapt the kit to your needs. However, if there are limitations with the underlying technology, you might need to work around them.


file: ./src/content/docs/web/index.mdx
meta: {
  "title": "Introduction",
  "description": "Get started with TurboStarter web kit.",
  "icon": "Home",
  "index": true
}
        
Welcome to the TurboStarter documentation. This is your starting point for learning about the starter kit, its structure, features, and how to use it for your app development.

![TurboStarter demo](/images/docs/demo.png)

## What is TurboStarter?

TurboStarter is a fullstack starter kit that helps you build scalable and production-ready web apps, mobile apps, and browser extensions in minutes.

## Principles

TurboStarter is built with the following principles:

* **As simple as possible** - It should be easy to understand, easy to use, and strongly avoid overengineering things.
* **As few dependencies as possible** - It should have as few dependencies as possible to allow you to take full control over every part of the project.
* **As performant as possible** - It should be fast and light without any unnecessary overhead.

## Features

Before diving into the technical details, let's overview the features TurboStarter provides.

### Multi-platform development

* [Web](/docs/web/stack): Build web apps with React, Next.js, and Tailwind CSS.
* [Mobile](/docs/mobile/stack): Build mobile apps with React Native and Expo.
* [Browser extension](/docs/extension/stack): Build browser extensions with React and WXT.

<Callout title="Available. Everywhere.">
  Most features are available on all platforms. You can use the **same codebase** to build web, mobile, and browser extension apps.
</Callout>

### Authentication

<Cards>
  <Card title="Ready-to-use components and views" description="Pre-built authentication components and pages that match your brand's unique style." className="shadow-none" />

  <Card title="Email/password authentication" description="Traditional email and password auth implementing validation and security best practices." className="shadow-none" />

  <Card title="Magic links" description="Passwordless authentication through secure email-based magic links, including rate limiting." className="shadow-none" />

  <Card title="Password recovery" description="Complete password reset flow including email verification and secure token handling." className="shadow-none" />

  <Card title="OAuth providers" description="Pre-configured social authentication for Google and GitHub, ready to use." className="shadow-none" />
</Cards>

### Billing

<Cards>
  <Card title="Subscriptions" description="Recurring billing system supporting multiple plans, pricing tiers and usage metrics." className="shadow-none" />

  <Card title="One-time payments" description="Simple payment processing featuring secure checkout and payment confirmation." className="shadow-none" />

  <Card title="Webhooks" description="Real-time billing event handling and payment provider data synchronization." className="shadow-none" />

  <Card title="Custom plans" description="Create and manage custom pricing plans offering flexible billing options." className="shadow-none" />

  <Card title="Billing components" description="Ready-made components for pricing, checkout and billing management." className="shadow-none" />

  <Card title="Multiple providers" description="Seamless integration of Stripe and LemonSqueezy payment systems." className="shadow-none" />
</Cards>

### API

<Cards>
  <Card title="Serverless architecture" description="Modern serverless infrastructure offering auto-scaling and high availability." className="shadow-none" />

  <Card title="Single source of truth" description="Unified data management across all apps through shared types and validation." className="shadow-none" />

  <Card title="Protected routes" description="Secure API endpoints implementing role-based access control and rate limiting." className="shadow-none" />

  <Card title="Feature-based access" description="Access control based on features and subscription plans." className="shadow-none" />

  <Card title="Typesafe client" description="Fully typesafe frontend client featuring automatic type generation." className="shadow-none" />
</Cards>

### AI

<Cards>
  <Card title="Multiple providers" description="Seamless integration of OpenAI, Anthropic, Groq, Mistral, and Gemini." className="shadow-none" />

  <Card title="Ready components" description="Pre-built chatbot and assistant components supporting real-time streaming." className="shadow-none" />

  <Card title="Streaming responses" description="Real-time AI response delivery including progress indicators." className="shadow-none" />
</Cards>

### Internationalization

<Cards>
  <Card title="Locale routing" description="Smart routing based on user locale and automatic language detection." className="shadow-none" />

  <Card title="Multiple languages" description="Comprehensive multi-language support and translation management." className="shadow-none" />

  <Card title="Language switching" description="One-click language changes and persistent preferences." className="shadow-none" />

  <Card title="Mail templates" description="Multi-language email templates including fallback options." className="shadow-none" />
</Cards>

### Emails

<Cards>
  <Card title="Transactional emails" description="Automated email delivery including tracking and analytics capabilities." className="shadow-none" />

  <Card title="Marketing emails" description="Create and send marketing campaigns using beautiful templates." className="shadow-none" />

  <Card title="Email templates" description="Responsive email templates supporting dark mode customization." className="shadow-none" />

  <Card title="Multiple providers" description="Easy integration of SendGrid, Resend, and Nodemailer services." className="shadow-none" />
</Cards>

### Marketing

<Cards>
  <Card title="SEO" description="Complete SEO toolkit including automatic sitemap generation." className="shadow-none" />

  <Card title="Meta tags" description="Flexible meta tag system supporting social media previews." className="shadow-none" />

  <Card title="Tips and tricks" description="Comprehensive tips and tricks for optimizing marketing of your app." className="shadow-none" />

  <Card title="Blog" description="Full-featured blog system including categories and RSS feed." className="shadow-none" />

  <Card title="Legal pages" description="Pre-built legal templates including version control." className="shadow-none" />

  <Card title="Contact form" description="Smart contact form featuring spam protection and auto-responses." className="shadow-none" />
</Cards>

### Storage

<Cards>
  <Card title="File uploads" description="Complete file upload system including progress tracking and validation." className="shadow-none" />

  <Card title="S3 storage" description="S3-compatible storage offering automatic file optimization." className="shadow-none" />
</Cards>

### CMS

<Cards>
  <Card title="Blog pages" description="Complete blog management system including categories and tags." className="shadow-none" />

  <Card title="MDX content collections" description="Organized content structure using MDX-based collections and custom frontmatter." className="shadow-none" />
</Cards>

### Theming

<Cards>
  <Card title="Built-in themes" description="10+ pre-built themes offering customizable color schemes." className="shadow-none" />

  <Card title="Dark mode" description="Built-in dark mode supporting system preference detection." className="shadow-none" />

  <Card title="Component CLI" description="Component generation tools following best practices and TypeScript standards." className="shadow-none" />

  <Card title="Design system" description="Complete atomic design system including accessibility features." className="shadow-none" />
</Cards>

### Analytics

<Cards>
  <Card title="Event tracking" description="Custom event tracking plus automatic session management." className="shadow-none" />

  <Card title="Page views" description="Automatic page view capture including bounce rate metrics." className="shadow-none" />

  <Card title="User identification" description="Cross-device user tracking and session management." className="shadow-none" />

  <Card title="Multiple providers" description="Seamless integration of Google Analytics and PostHog platforms." className="shadow-none" />
</Cards>

### Deployment

<Cards>
  <Card title="One-click deploy" description="Simple deployment to your preferred cloud provider." className="shadow-none" />

  <Card title="Submission guide" description="Comprehensive guide for app store submissions and requirements." className="shadow-none" />

  <Card title="CI/CD workflows" description="Pre-configured deployment pipelines including automated testing." className="shadow-none" />
</Cards>

## Use like LEGO blocks

The biggest advantage of TurboStarter is its modularity. You can use the entire stack or just the parts you need. It's like LEGO blocks - you can build anything you want with it.

If you don't need a specific feature, feel free to remove it without affecting the rest of the stack.

This approach allows for:

* 🧩 **Easy feature integration** - Plug new features into the kit with minimal changes.
* 🛠️ **Simplified maintenance** - Keep the codebase clean and maintainable.
* 🎯 **Core feature separation** - Distinguish between core features and custom features.
* 🌟 **Additional modules** - Easily add modules like billing, CMS, monitoring, logger, mailer, and more.

## Scope of this documentation

While building a SaaS application involves many moving parts, this documentation focuses specifically on TurboStarter. For in-depth information on the underlying technologies, please refer to their respective official documentation.

This documentation will guide you through configuring, running, and deploying the kit, and will provide helpful links to the official documentation of technologies where necessary.

## Enjoy!

This documentation is designed to be easy to follow and understand. If you have any questions or need help, feel free to reach out to us at [hello@turbostarter.dev](mailto:hello@turbostarter.dev).

Explore new features, build amazing apps, and have fun! 🚀


file: ./src/content/docs/web/stack.mdx
meta: {
  "title": "Tech Stack",
  "description": "A detailed look at the technical details.",
  "icon": "Tools"
}
        
## Turborepo

[Turborepo](https://turbo.build/) is a monorepo tool that helps you manage your project's dependencies and scripts. We chose a monorepo setup to make it easier to manage the structure of different features and enable code sharing between different packages.

<Card href="https://turbo.build/" title="Turborepo - Make Ship Happen" description="turbo.build" />

## Next.js

[Next.js](https://nextjs.org) is one of the most popular [React](https://react.dev) frameworks that enables server-side rendering, static site generation, and more. We chose Next.js for its flexibility and ease of use. We're also using it to host our serverless API.

<Cards>
  <Card href="https://react.dev" title="React" description="react.dev" />

  <Card href="https://nextjs.org" title="Next.js" description="nextjs.org" />
</Cards>

## Hono

[Hono](https://hono.dev) is a small, simple, and ultrafast web framework for the edge. It provides tools to help you build APIs and web applications faster. It includes an RPC client for making type-safe function calls from the frontend. We use Hono to build our serverless API endpoints.

<Card href="https://hono.dev" title="Hono" description="hono.dev" />

## Better Auth

[Better Auth](https://www.better-auth.com) is a modern authentication library for fullstack applications. It provides ready-to-use snippets for features like email/password login, magic links, OAuth providers, and more. We use Better Auth to handle all authentication flows in our application.

<Card href="https://www.better-auth.com" title="Better Auth" description="better-auth.com" />

## Tailwind CSS

[Tailwind CSS](https://tailwindcss.com) is a utility-first CSS framework that helps you build custom designs without writing any CSS. We also use [Radix UI](https://radix-ui.com) for our headless components library and [shadcn/ui](https://ui.shadcn.com), which enables you to generate pre-designed components with a single command.

<Cards className="grid-cols-2 sm:grid-cols-3">
  <Card href="https://tailwindcss.com" title="Tailwind CSS" description="tailwindcss.com" />

  <Card href="https://radix-ui.com" title="Radix UI" description="radix-ui.com" />

  <Card href="https://ui.shadcn.com" title="shadcn/ui" description="ui.shadcn.com" />
</Cards>

## Drizzle

[Drizzle](https://orm.drizzle.team/) is a super fast [ORM](https://orm.drizzle.team/docs/overview) (Object-Relational Mapping) tool for databases. It helps manage databases, generate TypeScript types from your schema, and run queries in a fully type-safe way.

We use [PostgreSQL](https://www.postgresql.org) as our default database, but thanks to Drizzle's flexibility, you can easily switch to MySQL, SQLite or any [other supported database](https://orm.drizzle.team/docs/connect-overview) by updating a few configuration lines.

<Cards>
  <Card href="https://orm.drizzle.team/" title="Drizzle" description="orm.drizzle.team" />

  <Card href="https://www.postgresql.org" title="PostgreSQL" description="postgresql.org" />
</Cards>


file: ./src/content/docs/extension/analytics/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure extension analytics in TurboStarter."
}
        
The `@turbostarter/analytics-extension` package offers a streamlined and flexible approach to tracking events in your TurboStarter extension using various analytics providers. It abstracts the complexities of different analytics services and provides a consistent interface for event tracking.

In this section, we'll guide you through the configuration process for each supported provider.

Note that the configuration is validated against a schema, so you'll see error messages in the console if anything is misconfigured.

## Providers

Below, you'll find detailed information on how to set up and use each supported provider. Choose the one that best suits your needs and follow the instructions in the respective accordion section.

<Accordions>
  <Accordion title="Google Analytics" id="google-analytics">
    To use Google Analytics as your analytics provider, you need to [create a Google Analytics account](https://analytics.google.com/) and [set up a property](https://support.google.com/analytics/answer/9304153).

    Next, add a data stream in your Google Analytics account settings:

    1. Navigate to [Google Analytics](https://analytics.google.com/).
    2. In the *Admin* section, under *Data collection and modification*, click on *Data Streams*.
    3. Click *Add stream*.
    4. Select *Web* as the platform.
    5. Enter the required details for the stream (at minimum, provide a name and website URL).
    6. Click *Create stream*.

    After creating the stream, you'll need two pieces of information:

    1. Your [Measurement ID](https://support.google.com/analytics/answer/12270356) (it should look like `G-XXXXXXXXXX`):

    ![Google Analytics Measurement ID](/images/docs/web/analytics/google/id.png)

    2. Your [Measurement Protocol API secret](https://support.google.com/analytics/answer/9814495):

    ![Google Analytics Measurement Protocol API secret](/images/docs/web/analytics/google/api-secret.png)

    Set these values in your `.env.local` file in the `apps/extension` directory and in your CI/CD provider secrets:

    ```dotenv
    VITE_GOOGLE_ANALYTICS_MEASUREMENT_ID="your-measurement-id"
    VITE_GOOGLE_ANALYTICS_SECRET="your-measurement-protocol-api-secret"
    ```

    Also, make sure to activate the Google Analytics provider as your analytics provider:

    ```dotenv
    VITE_ANALYTICS_PROVIDER="google-analytics"
    ```

    To customize the provider, you can find its definition in `packages/analytics/extension/src/providers/google-analytics` directory.

    For more information, please refer to the [Google Analytics documentation](https://developers.google.com/analytics).

    ![Google Analytics dashboard](/images/docs/web/analytics/google/dashboard.jpg)
  </Accordion>
</Accordions>


file: ./src/content/docs/extension/analytics/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with extension analytics in TurboStarter.",
  "index": true
}
        
When it comes to extension analytics, we can distinguish between two types:

* **Store listing analytics**: Used to track the performance of your extension's store listing (e.g., how many people have viewed your extension in the store or how many have installed it).
* **In-extension analytics**: Tracks user actions within your extension (e.g., how many users triggered your popup, how many users modified extension settings, etc.).

The `@turbostarter/analytics-extension` package provides a set of tools to easily implement both types of analytics in your extension.

## Store listing analytics

Interpreting your extension's store listing metrics can help you evaluate how changes to your extension and store listing affect conversion rates. For example, you can identify countries with a high number of visitors to prioritize supporting languages for those regions.

While each store implements a different set of metrics, there are some common ones you should be aware of:

* **Active installs**: The number of users who have installed your extension.
* **Active users**: The number of users who have used your extension.
* **Page views**: The number of times users have viewed your extension's detail page on the respective store.

To track more detailed metrics, you can opt in to Google Analytics in the Chrome Web Store's developer dashboard.

You can find this option under *Additional metrics* on the *Store listing* tab of your extension's control panel:

![Chrome Web Store - Store listing - Additional metrics](/images/docs/extension/analytics/opt-in-analytics.png)

<Callout>
  The Chrome Web Store manages the account for you and makes the data available
  in the Google Analytics dashboard.
</Callout>

By enabling this feature, you can optimize your extension's store listing based on metrics such as bounce rate, time on page, and more. This can lead to more installs and ultimately more users for your extension.

To learn more about the limitations of this type of analytics and how to adjust event details, please refer to the following sections in the official documentation:

<Cards>
  <Card title="Analyze your store listing metrics" description="developer.chrome.com" href="https://developer.chrome.com/docs/webstore/metrics" />

  <Card title="Use your Google Analytics account with the Chrome Web Store" description="developer.chrome.com" href="https://developer.chrome.com/docs/webstore/google-analytics" />
</Cards>

## In-extension analytics

TurboStarter comes with built-in support for tracking in-extension analytics. To learn more about each supported provider and how to configure them, see their respective sections:

<Cards>
  <Card title="Google Analytics" href="/docs/extension/analytics/configuration#google-analytics" />
</Cards>

All configuration and setup is built-in with a unified API, allowing you to switch between providers without changing your code. You can even introduce your own provider without breaking any tracking-related logic.

In the following sections, we'll cover how to set up each provider and how to track events in your extension.


file: ./src/content/docs/extension/analytics/tracking.mdx
meta: {
  "title": "Tracking events",
  "description": "Learn how to track events in your TurboStarter extension."
}
        
The strategy for tracking events, that every provider has to implement, is extremely simple:

```ts
export type AllowedPropertyValues = string | number | boolean;

type TrackFunction = (
  event: string,
  data?: Record<string, AllowedPropertyValues>,
) => void;

export interface AnalyticsProviderStrategy {
  track: TrackFunction;
}
```

<Callout>
  You don't need to worry much about this implementation, as all the providers are already configured for you. However, it's useful to be aware of this structure if you plan to add your own custom provider.
</Callout>

As shown above, each provider must supply the `track` function. This function is responsible for sending event data to the provider.

To track an event in any part of your extension, simply call the `track` method, passing the event name and an optional data object:

```tsx title="main.tsx"
import { track } from "@turbostarter/analytics-extension";

const Popup = () => {
  return (
    <button onClick={() => track("popup.button.click", { country: "US" })}>
      Track event
    </button>
  );
};

export default Popup;
```

Congratulations! You've now mastered event tracking in your TurboStarter extension. With this knowledge, you're well-equipped to analyze user behaviors and gain valuable insights into your extension's usage patterns. Happy analyzing! 📊


file: ./src/content/docs/extension/api/client.mdx
meta: {
  "title": "Using API client",
  "description": "How to use API client to interact with the API."
}
        
In browser extension code, you can only access the API client from the **client-side.**

When you create a new component or piece of your extension and want to fetch some data, you can use the API client to do so.

## Creating a client

We're creating a client-side API client in `apps/extension/src/lib/api/index.tsx` file. It's a simple wrapper around the [@tanstack/react-query](https://tanstack.com/query/latest/docs/framework/react/overview) that fetches or mutates data from the API.

It also requires wrapping your views in a `ApiProvider` component to provide the API client to the rest of the components.

We recommend to create a separate layout file, which will be used to wrap your pages. TurboStarter comes with a `layout.tsx` file in the `components/layout` folder, which you can use as a template:

```tsx title="layout.tsx"
export const Layout = ({
  children,
  loadingFallback,
  errorFallback,
}: LayoutProps) => {
  return (
    <ErrorBoundary fallback={errorFallback}>
      <Suspense fallback={loadingFallback}>
        <ApiProvider>{children}</ApiProvider>
      </Suspense>
    </ErrorBoundary>
  );
};
```

Remember that every part of your extension will be mounted as a **separate** React component, so you need to wrap each of them in the `ApiProvider` component if you want to use the API client inside:

```tsx title="app/popup/main.tsx"
import { Layout } from "~/components/layout/layout";

export default function Popup() {
  return <Layout>{/* your popup code here */}</Layout>;
}
```

<Callout type="warn" title="Ensure correct API url">
  Inside the `apps/extension/src/lib/api/index.tsx` we're calling a function to get base url of your api, so make sure it's set correctly (especially on production) and your web api endpoint is corresponding with the name there.

  ```tsx title="index.tsx"
  const getBaseUrl = () => {
    return env.VITE_SITE_URL;
  };
  ```

  As you can see we're mostly relying on the [environment variables](/docs/extension/configuration/environment-variables) to get it, so there shouldn't be any issues with it, but in case, please be aware where to find it 😉
</Callout>

## Queries

Of course, everything comes already configured for you, so you just need to start using `api` in your components/screens.

For example, to fetch the list of posts you can use the `useQuery` hook:

```tsx title="posts.tsx"
import { api } from "~/lib/api";

export const Posts = () => {
  const { data: posts, isLoading } = useQuery({
    queryKey: ["posts"],
    queryFn: async () => {
      const response = await api.posts.$get();

      if (!response.ok) {
        throw new Error("Failed to fetch posts!");
      }

      return response.json();
    },
  });

  if (isLoading) {
    return <p>Loading...</p>;
  }

  /* do something with the data... */
  return (
    <div>
      <p>{JSON.stringify(posts)}</p>
    </div>
  );
};
```

It's using the `@tanstack/react-query` [useQuery API](https://tanstack.com/query/latest/docs/framework/react/reference/useQuery), so you shouldn't have any troubles with it.

<Cards>
  <Card title="Hono RPC" description="hono.dev" href="https://hono.dev/docs/guides/rpc" />

  <Card title="useQuery hook | Tanstack Query" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/reference/useQuery" />
</Cards>

## Mutations

If you want to perform a mutation in your extension code, you can use the `useMutation` hook that comes straight from the integration with [Tanstack Query](https://tanstack.com/query):

```tsx title="components/popup/form.tsx"
import { api } from "~/lib/api";

export const CreatePost = () => {
  const queryClient = useQueryClient();
  const { mutate } = useMutation({
    mutationFn: async (post: PostInput) => {
      const response = await api.posts.$post(post);

      if (!response.ok) {
        throw new Error("Failed to create post!");
      },
    },
    onSuccess: () => {
      toast.success("Post created successfully!");
      queryClient.invalidateQueries({ queryKey: ["posts"] });
    },
  });

  return <form onSubmit={onSubmit(mutate)} />;
};
```

Here, we're also invalidating the query after the mutation is successful. This is a very important step to make sure that the data is updated in the UI.

<Cards>
  <Card title="useMutation hook" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/reference/useMutation" />

  <Card title="Query invalidation" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation" />
</Cards>

## Handling responses

As you can see in the examples above, the [Hono RPC](https://hono.dev/docs/guides/rpc) client returns a plain `Response` object, which you can use to get the data or handle errors. However, implementing this handling in every query or mutation can be tedious and will introduce unnecessary boilerplate in your codebase.

That's why we've developed the `handle` function that unwraps the response for you, handles errors, and returns the data in a consistent format. You can safely use it with any procedure from the API client:

<Tabs items={["Queries", "Mutations"]}>
  <Tab value="Queries">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api";

    export const Posts = () => {
      const { data: posts, isLoading } = useQuery({
        queryKey: ["posts"],
        queryFn: handle(api.posts.$get),
      });

      if (isLoading) {
        return <p>Loading...</p>;
      }

      /* do something with the data... */
      return (
        <div>
          <p>{JSON.stringify(posts)}</p>
        </div>
      );
    };
    ```
  </Tab>

  <Tab value="Mutations">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/client";

    export const CreatePost = () => {
      const queryClient = useQueryClient();
      const { mutate } = useMutation({
        mutationFn: handle(api.posts.$post),
        onSuccess: () => {
          toast.success("Post created successfully!");
          queryClient.invalidateQueries({ queryKey: ["posts"] });
        },
      });

      return <form onSubmit={onSubmit(mutate)} />;
    };
    ```
  </Tab>
</Tabs>

With this approach, you can focus on the business logic instead of repeatedly writing code to handle API responses in your browser extension components, making your extension's codebase more readable and maintainable.

The same error handling and response unwrapping benefits apply whether you're building web, mobile, or extension interfaces - allowing you to keep your data fetching logic consistent across all platforms.


file: ./src/content/docs/extension/api/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with the API.",
  "index": true
}
        
<Callout type="error" title="API deployment required">
  To enable communication between your WXT extension and the server in a production environment, the web application with Hono API must be deployed first.

  <Cards>
    <Card title="API" description="Learn more about the API." href="/docs/web/api/overview" />

    <Card title="Web deployment" description="Deploy your web application to production." href="/docs/web/deployment/checklist" />
  </Cards>
</Callout>

TurboStarter is designed to be a scalable and production-ready full-stack starter kit. One of its core features is a dedicated and extensible API layer. To enable this in a type-safe manner, we chose [Hono](https://hono.dev) as the API server and client library.

<Callout title="Why Hono?">
  Hono is a small, simple, and ultrafast web framework that gives you a way to
  define your API endpoints with full type safety. It provides built-in
  middleware for common needs like validation, caching, and CORS. It also
  includes an [RPC client](https://hono.dev/docs/guides/rpc) for making
  type-safe function calls from the frontend. Being edge-first, it's optimized
  for serverless environments and offers excellent performance.
</Callout>

All API endpoints and their resolvers are defined in the `packages/api/` package. Here you will find a `modules` folder that contains the different feature modules of the API. Each module has its own folder and exports all its resolvers.

For each module, we create a separate Hono route in the `packages/api/index.ts` file and aggregate all sub-routers into one main router.

The API is then exposed as a route handler that will be provided as a Next.js API route:

```ts title="apps/web/src/app/api/[...route]/route.ts"
import { handle } from "hono/vercel";

import { appRouter } from "@turbostarter/api";

const handler = handle(appRouter);
export { handler as GET, handler as POST };
```

Learn more about how to use the API in your browser extension code in the following sections:


file: ./src/content/docs/extension/auth/overview.mdx
meta: {
  "title": "Overview",
  "description": "Learn how to authenticate users in your extension."
}
        
TurboStarter uses [Better Auth](https://better-auth.com) to handle authentication. It's a secure, production-ready authentication solution that integrates seamlessly with many frameworks and provides enterprise-grade security out of the box.

<Callout title="Why Better Auth?">
  One of the core principles of TurboStarter is to do things **as simple as possible**, and to make everything **as performant as possible**.

  Better Auth provides an excellent developer experience with minimal configuration required, while maintaining enterprise-grade security standards. Its framework-agnostic approach and focus on performance makes it the perfect choice for TurboStarter.
</Callout>

![Better Auth](/images/docs/better-auth.png)

You can read more about Better Auth in the [official documentation](https://better-auth.com/docs).

<Callout type="info" title="IMPORTANT: Shared authentication">
  To keep things simple and secure, **the extension shares the same authentication session with your web app.**

  This is a common approach used by popular services like [Notion](https://www.notion.so) and [Google Workspace](https://workspace.google.com/). The benefits include:

  * Users only need to sign in once through the web app
  * The extension automatically inherits the authenticated session
  * Sign out actions are synchronized across platforms
  * Reduced security surface area and complexity
</Callout>

Before setting up extension authentication, make sure to first [configure authentication for your web app](/docs/web/auth/overview) and then head back to the extension code.

The following sections cover everything you need to know about authentication in your extension:

<Cards>
  <Card title="Configuration" description="Configure authentication for your application." href="/docs/web/auth/configuration" />

  <Card title="User flow" description="Discover the authentication flow in Turbostarter." href="/docs/web/auth/flow" />

  <Card title="OAuth" description="Get started with social authentication." href="/docs/web/auth/oauth" />

  <Card title="Session" description="Learn how to manage auth session in your extension." href="/docs/extension/auth/session" />
</Cards>


file: ./src/content/docs/extension/auth/session.mdx
meta: {
  "title": "Session",
  "description": "Learn how to manage the user session in your extension."
}
        
We're not implementing fully-featured auth flow in the extension. Instead, **we're sharing the same auth session with the web app.**

It's a common practice in the industry used e.g. by [Notion](https://www.notion.so) and [Google Workspace](https://workspace.google.com/).

That way, when the user is signed in to the web app, the extension can use the same session to authenticate the user, so he doesn't have to sign in again. Also signing out from the extension will affect both platforms.

<Callout title="Remember to add your extension scheme as trusted origin">
  For browser extensions, we need to define an [authentication trusted origin](https://www.better-auth.com/docs/reference/security#trusted-origins) using an extension scheme.

  Extension schemes (like `chrome-extension://...`) are used for redirecting users to specific screens after authentication and sharing the auth session with the web app.

  To find your extension ID, open Chrome and go to `chrome://extensions/`, enable Developer Mode in the top right, and look for your extension's ID. Then add it to your auth server configuration:

  ```tsx title="server.ts"
  export const auth = betterAuth({
    ...

    trustedOrigins: ["chrome-extension://your-extension-id"],

    ...
  });
  ```

  Adding your extension scheme to the trusted origins list is crucial for security - it prevents CSRF attacks and blocks malicious open redirects by ensuring only requests from approved origins (your extension) are allowed through.

  [Read more about auth security in Better Auth's documentation.](https://www.better-auth.com/docs/reference/security)
</Callout>

## Cookies

When the user signs in to the [web app](/docs/web) through our [Better Auth API](/docs/web/auth/configuration#api), web app is setting the cookie with the session token under your app's domain, which is later used to validate the session on the server.

You can find your cookie in *Cookies* tab in the browser's developer tools (remember to be logged in to the app to check it):

![Session cookie](/images/docs/extension/auth/cookie.png)

To enable your extension to read the cookie and that way share the session with the web app, you need to set the `cookies` permission in the `wxt.config.ts` under `manifest.permissions` field:

```ts title="wxt.config.ts"
export default defineConfig({
  manifest: {
    permissions: ["cookies"],
  },
});
```

And to be able to read the cookie from your app url, you need to set `host_permissions`, which will include your app url:

```ts title="wxt.config.ts"
export default defineConfig({
  manifest: {
    host_permissions: ["http://localhost/*", "https://your-app-url.com/*"],
  },
});
```

Then you would be able to share the cookie with API requests and also read its value using `browser.cookies` API.

<Callout title="Avoid &#x22;<all_urls>&#x22;" type="warn">
  Avoid using `<all_urls>` in `host_permissions`. It affects all urls and may cause security issues, as well as a [rejection](https://developer.chrome.com/docs/webstore/review-process#review-time-factors) from the destination store.
</Callout>

<Cards>
  <Card title="Declare permissions" href="https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions" description="developer.chrome.com" />

  <Card title="chrome.cookies" href="https://developer.chrome.com/docs/extensions/reference/api/cookies" description="developer.chrome.com" />
</Cards>

## Reading session

You **don't** need to worry about reading, parsing, or validating the session cookie. TurboStarter comes with a pre-built solution that ensures your session is correctly shared with the web app.

It also ensures that appropriate cookies are passed to [API](/docs/web/api/overview) requests, so you can safely use [protected endpoints](/docs/web/api/protected-routes) (that require authentication) in your extension.

To get session details in your extension code (e.g., inside a popup window), you can leverage the `useSession` hook provided by the [auth client](https://www.better-auth.com/docs/basic-usage#client-side) (which is also used in the web and mobile apps):

```tsx title="user.tsx"
import { useSession } from "~/lib/auth";

const User = () => {
  const {
    data: { user, session },
    isPending,
  } = useSession();

  if (isPending) {
    return <p>Loading...</p>;
  }

  /* do something with the session data... */
  return <p>{user?.email}</p>;
};
```

That's how you can access user details right in your extension.

## Signing out

Signing out from the extension also involves using the well-known `signOut` function that is derived from our [auth client](https://www.better-auth.com/docs/basic-usage#signout):

```tsx title="logout.tsx"
import { signOut } from "~/lib/auth";

export const Logout = () => {
  return <button onClick={() => signOut()}>Log out</button>;
};
```

The session is automatically invalidated, so the next use of `useSession` or any other query that depends on the session will return `null`. The UI for both the extension and the web app will be updated to show the user as logged out.

<Callout title="This will sign out the user from the web app as well" type="warn">
  As web app is using the same session cookie, the user will be signed out from the web app as well. **This is intentional**, as your extension will most probably serves as an add-on for the web app and it doesn't make sense to keep the user signed in there if the extension is not used.
</Callout>

![Sign out](/images/docs/web/auth/sign-out.png)


file: ./src/content/docs/extension/configuration/app.mdx
meta: {
  "title": "App configuration",
  "description": "Learn how to setup the overall settings of your extension."
}
        
The application configuration is set at `apps/extension/src/config/app.ts`. This configuration stores some overall variables for your application.

This allows you to host multiple apps in the same monorepo, as every application defines its own configuration.

The recommendation is to **not update this directly** - instead, please define the environment variables and override the default behavior. The configuration is strongly typed so you can use it safely accross your codebase - it'll be validated at build time.

```ts title="apps/extension/src/config/app.ts"
import { env } from "~/lib/env";

export const appConfig = {
  name: env.VITE_PRODUCT_NAME,
  url: env.VITE_SITE_URL,
  locale: env.VITE_DEFAULT_LOCALE,
  theme: {
    mode: env.VITE_THEME_MODE,
    color: env.VITE_THEME_COLOR,
  },
} as const;
```

For example, to set the extension default theme color, you'd update the following variable:

```dotenv title=".env.local"
VITE_THEME_COLOR="yellow"
```

<Callout type="warn" title="Do NOT use process.env!">
  Do NOT use `process.env` to get the values of the variables. Variables
  accessed this way are not validated at build time, and thus the wrong variable
  can be used in production.
</Callout>

## WXT config

To configure framework-specific settings, you can use the `wxt.config.ts` file. You can configure a lot of options there, such as [manifest](/docs/extension/configuration/manifest), [project structure](https://wxt.dev/guide/essentials/project-structure.html) or even [underlying Vite config](https://wxt.dev/guide/essentials/config/vite.html):

```ts title="wxt.config.ts"
import { defineConfig } from "wxt";

export default defineConfig({
  srcDir: "src",
  entrypointsDir: "app",
  outDir: "build",
  modules: [],
  manifest: {
    // Put manifest changes here
  },
  vite: () => ({
    // Override config here, same as `defineConfig({ ... })`
    // inside vite.config.ts files
  }),
});
```

Make sure to setup it correctly, as it's the main source of config for your development, build and publishing process.


file: ./src/content/docs/extension/configuration/environment-variables.mdx
meta: {
  "title": "Environment variables",
  "description": "Learn how to configure environment variables."
}
        
Environment variables are defined in the `.env` file in the root of the repository and in the root of the `apps/extension` package.

* **Shared environment variables**: Defined in the **root** `.env` file. These are shared between environments (e.g., development, staging, production) and apps (e.g., web, extension).
* **Environment-specific variables**: Defined in `.env.development` and `.env.production` files. These are specific to the development and production environments.
* **App-specific variables**: Defined in the app-specific directory (e.g., `apps/extension`). These are specific to the app and are not shared between apps.
* **Bundle-specific variables**: Specific to the [bundle target](https://wxt.dev/guide/essentials/config/environment-variables.html#built-in-environment-variables) (e.g. `.env.safari`, `.env.firefox`) or [bundle tag](https://wxt.dev/guide/essentials/config/environment-variables.html#built-in-environment-variables) (e.g. `.env.testing`)
* **Build environment variables**: Not stored in the `.env` file. Instead, they are stored in the environment variables of the CI/CD system.
* **Secret keys**: They're not stored on the extension side, instead [they're defined on the web side.](/docs/web/configuration/environment-variables#secret-keys)

## Shared variables

Here you can add all the environment variables that are shared across all the apps.

To override these variables in a specific environment, please add them to the specific environment file (e.g. `.env.development`, `.env.production`).

```dotenv title=".env.local"
# Shared environment variables

# The database URL is used to connect to your database.
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres"

# The name of the product. This is used in various places across the apps.
PRODUCT_NAME="TurboStarter"

# The url of the web app. Used mostly to link between apps.
URL="http://localhost:3000"

...
```

## App-specific variables

Here you can add all the environment variables that are specific to the app (e.g. `apps/extension`).

You can also override the shared variables defined in the root `.env` file.

```dotenv title="apps/extension/.env.local"
# App-specific environment variables

# Env variables extracted from shared to be exposed to the client in WXT (Vite) extension
VITE_SITE_URL="${URL}"
VITE_DEFAULT_LOCALE="${DEFAULT_LOCALE}"

# Theme mode and color
VITE_THEME_MODE="system"
VITE_THEME_COLOR="orange"

...
```

<Callout title="VITE_ prefix">
  To make environment variables available in the browser extension code, you need to prefix them with `VITE_`. They will be injected to the code during the build process.

  Only environment variables prefixed with `VITE_` will be injected.

  [Read more about Vite environment variables.](https://vite.dev/guide/env-and-mode.html#env-files)
</Callout>

## Bundle-specific variables

WXT also provides environment variables specific to a certain [build target](https://wxt.dev/guide/essentials/config/environment-variables.html#built-in-environment-variables) or [build tag](https://wxt.dev/guide/essentials/config/environment-variables.html#built-in-environment-variables) when creating the final bundle. Given the following build command:

```json title="package.json"
"scripts": {
  "build": "wxt build -b firefox --mode testing"
}
```

The following env files will be considered, ordered by priority:

* `.env.firefox`
* `.env.testing`
* `.env`

You shouldn't worry much about this, as TurboStarter comes with already configured build processes for all the major browsers.

## Build environment variables

To allow your extension to build properly on CI you need to define your environment variables on your CI/CD system (e.g. [Github Actions](https://docs.github.com/en/actions/learn-github-actions/environment-variables)).

TurboStarter comes with predefined Github Actions workflow used to build and submit your extension to the stores. It's located in `.github/workflows/publish-extension.yml` file.

To correctly set up the build environment variables, you need to define them under `env` section and then add them as a [secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets-and-variables) to your repository.

```yaml title="publish-extension.yml"
...

jobs:
  extension:
    name: 🚀 Publish extension
    runs-on: ubuntu-latest
    environment: Production
    env:
      VITE_SITE_URL: ${{ secrets.SITE_URL }}

  ...

```

We'll go through the whole process of building and publishing the extension in the [publishing guide](/docs/extension/publishing/checklist).

## Secret keys

Secret keys and sensitive information are to be **never** stored on the extension app code.

<Callout title="What does this mean?">
  It means that you will need to add the secret keys to the **web app, where the API is deployed.**

  The browser extension should only communicate with the backend API, which is typically part of the web app. The web app is responsible for handling sensitive operations and storing secret keys securely.

  [See web documentation for more details.](/docs/web/configuration/environment-variables#secret-keys)

  This is not a TurboStarter-specific requirement, but a best practice for security for any
  application. Ultimately, it's your choice.
</Callout>


file: ./src/content/docs/extension/configuration/manifest.mdx
meta: {
  "title": "Manifest",
  "description": "Learn how to configure the manifest of your extension."
}
        
As a requirement from web stores, every extension must have a `manifest.json` file in its root directory that lists important information about the structure and behavior of that extension.

It's a JSON file that contains metadata about the extension, such as its name, version, and permissions.

You can read more about it in the [official documentation](https://developer.chrome.com/docs/extensions/reference/manifest).

## Where is the `manifest.json` file?

WXT **abstracts away** the manifest file. The framework generates the manifest under the hood based on your source files and configurations you export from your code, similar to how Next.js abstracts page routing and SSG with the file system and page components.

That way, you don't have to manually create the `manifest.json` file and worry about correctly setting all the fields.

Most of the common properties are taken from the `package.json` and `wxt.config.ts` files:

| Manifest Field           | Abstractions                                                  |
| ------------------------ | ------------------------------------------------------------- |
| icons                    | Auto generated with the `icon.png` in the `/assets` directory |
| action, browser\_actions | Popup window                                                  |
| options\_ui              | Options page                                                  |
| content\_scripts         | Content scripts                                               |
| background               | Background service worker                                     |
| version                  | set by the `version` field in `package.json`                  |
| name                     | set by the `name` field in `wxt.config.ts`                    |
| description              | set by the `description` field in `wxt.config.ts`             |
| author                   | set by the `author` field in `wxt.config.ts`                  |
| homepage\_url            | set by the `homepage` field in `wxt.config.ts`                |

WXT build process centralizes common metadata and resolves any static file references (such as popup, background, content scripts, and so on) automatically.

This enables you to focus on the metadata that matters, such as name, description, OAuth, and so on.

## Overriding manifest

Sometimes, you want to override the default manifest fields (e.g. because you need to add a new permission that is required for your extension to work).

You'll need to modify your project's `wxt.config.ts` like so:

```ts title="apps/extension/wxt.config.ts"
export default defineConfig({
  manifest: {
    permissions: ["activeTab"],
  },
});
```

Then, your settings will be merged with the settings auto-generated by WXT.

### Environment variables

You can use environment variables inside the manifest overrides:

```ts title="apps/extension/wxt.config.ts"
export default defineConfig({
  manifest: {
    browser_specific_settings: {
      gecko: {
        id: import.meta.env.VITE_FIREFOX_EXT_ID,
      },
    },
  },
});
```

If the environment variable could not be found, the field will be removed completely from the manifest.

### Locales

TurboStarter extension supports [extension localization](https://developer.chrome.com/docs/extensions/reference/api/i18n) out-of-the-box. You can customize e.g. your extension's name and description based on the language of the user's browser.

Locales are defined in the `/public/_locales` directory. The directory should contain a `messages.json` file for each language you want to support (e.g. `/public/_locales/en/messages.json` and `/public/_locales/es/messages.json`).

By default, the first locale alphabetically available is used as default. However, you can specify a `default_locale` in your manifest like so:

```ts title="apps/extension/wxt.config.ts"
export default defineConfig({
  manifest: {
    default_locale: "en",
  },
});
```

To reference a locale string inside your manifest overrides, wrap the key inside `__MSG_<key>__`:

```ts title="apps/extension/wxt.config.ts"
export default defineConfig({
  manifest: {
    name: "__MSG_extensionName__",
    description: "__MSG_extensionDescription__",
  },
});
```

Apart of this, we also configure [in-extension internationalization](/docs/extension/internationalization) out-of-the-box to easily translate your components and views.

<Cards>
  <Card title="Manifest file format" href="https://developer.chrome.com/docs/extensions/reference/manifest" description="developer.chrome.com" />

  <Card title="WXT Manifest" href="https://wxt.dev/guide/essentials/config/manifest.html" description="wxt.dev" />

  <Card title="chrome.i18n" href="https://developer.chrome.com/docs/extensions/reference/api/i18n" description="developer.chrome.com" />

  <Card title="WXT i18n" href="https://wxt.dev/guide/essentials/i18n.html" description="wxt.dev" />
</Cards>


file: ./src/content/docs/extension/customization/add-app.mdx
meta: {
  "title": "Adding apps",
  "description": "Learn how to add apps to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new app to your TurboStarter project within your monorepo and want to keep pulling updates from the TurboStarter repository.
</Callout>

In some ways - creating a new repository may be the easiest way to manage your application. However, if you want to keep your application within the monorepo and pull updates from the TurboStarter repository, you can follow these instructions.

To pull updates into a separate application outside of `extension` - we can use [git subtree](https://www.atlassian.com/git/tutorials/git-subtree).

Basically, we will create a subtree at `apps/extension` and create a new remote branch for the subtree. When we create a new application, we will pull the subtree into the new application. This allows us to keep it in sync with the `apps/extension` folder.

To add a new app to your TurboStarter project, you need to follow these steps:

<Steps>
  <Step>
    ## Create a subtree

    First, we need to create a subtree for the `apps/extension` folder. We will create a branch named `extension-branch` and create a subtree for the `apps/extension` folder.

    ```bash
    git subtree split --prefix=apps/extension --branch extension-branch
    ```
  </Step>

  <Step>
    ## Create a new app

    Now, we can create a new application in the `apps` folder.

    Let's say we want to create a new app `ai-chat` at `apps/ai-chat` with the same structure as the `apps/extension` folder (which acts as the template for all new apps).

    ```bash
    git subtree add --prefix=apps/ai-chat origin extension-branch --squash
    ```

    You should now be able to see the `apps/ai-chat` folder with the contents of the `apps/extension` folder.
  </Step>

  <Step>
    ## Update the app

    When you want to update the new application, follow these steps:

    ### Pull the latest updates from the TurboStarter repository

    The command below will update all the changes from the TurboStarter repository:

    ```bash
    git pull upstream main
    ```

    ### Push the `extension-branch` updates

    After you have pulled the updates from the TurboStarter repository, you can split the branch again and push the updates to the extension-branch:

    ```bash
    git subtree split --prefix=apps/extension --branch extension-branch
    ```

    Now, you can push the updates to the `extension-branch`:

    ```bash
    git push origin extension-branch
    ```

    ### Pull the updates to the new application

    Now, you can pull the updates to the new application:

    ```bash
    git subtree pull --prefix=apps/ai-chat origin extension-branch --squash
    ```
  </Step>
</Steps>

That's it! You now have a new application in the monorepo 🎉


file: ./src/content/docs/extension/customization/add-package.mdx
meta: {
  "title": "Adding packages",
  "description": "Learn how to add packages to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new package to your TurboStarter application instead of adding a folder to your application in `apps/web` or modify existing packages under `packages`. You don't need to do this to add a new page or component to your application.
</Callout>

To add a new package to your TurboStarter application, you need to follow these steps:

<Steps>
  <Step>
    ## Generate a new package

    First, enter the command below to create a new package in your TurboStarter application:

    ```bash
    turbo gen
    ```

    Turborepo will ask you to enter the name of the package you want to create. Enter the name of the package you want to create and press enter.

    If you don't want to add dependencies to your package, you can skip this step by pressing enter.

    The command will have generated a new package under packages named `@turbostarter/<package-name>`. If you named it `example`, the package will be named `@turbostarter/example`.
  </Step>

  <Step>
    ## Export a module from your package

    By default, the package exports a single module using the `index.ts` file. You can add more exports by creating new files in the package directory and exporting them from the `index.ts` file or creating export files in the package directory and adding them to the `exports` field in the `package.json` file.

    ### From `index.ts` file

    The easiest way to export a module from a package is to create a new file in the package directory and export it from the `index.ts` file.

    ```ts title="packages/example/src/module.ts"
    export function example() {
      return "example";
    }
    ```

    Then, export the module from the `index.ts` file.

    ```ts title="packages/example/src/index.ts"
    export * from "./module";
    ```

    ### From `exports` field in `package.json`

    **This can be very useful for tree-shaking.** Assuming you have a file named `module.ts` in the package directory, you can export it by adding it to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./module": "./src/module.ts"
      }
    }
    ```

    **When to do this?**

    1. when exporting two modules that don't share dependencies to ensure better tree-shaking. For example, if your exports contains both client and server modules.
    2. for better organization of your package

    For example, create two exports `client` and `server` in the package directory and add them to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./client": "./src/client.ts",
        "./server": "./src/server.ts"
      }
    }
    ```

    1. The `client` module can be imported using `import { client } from '@turbostarter/example/client'`
    2. The `server` module can be imported using `import { server } from '@turbostarter/example/server'`
  </Step>

  <Step>
    ## Use the package in your extension

    You can now use the package in your extension by importing it using the package name:

    ```ts title="app/popup/index.tsx"
    import { example } from "@turbostarter/example";

    console.log(example());
    ```
  </Step>
</Steps>

Et voilà! You have successfully added a new package to your TurboStarter extension. 🎉


file: ./src/content/docs/extension/customization/components.mdx
meta: {
  "title": "Components",
  "description": "Manage and customize your extension components.",
  "mirror": "../../web/customization/components.mdx"
}
        


file: ./src/content/docs/extension/customization/styling.mdx
meta: {
  "title": "Styling",
  "description": "Get started with styling your extension."
}
        
To build the extension interface TurboStarter comes with [Tailwind CSS](https://tailwindcss.com/) and [Radix UI](https://www.radix-ui.com/) pre-configured.

<Callout title="Why Tailwind CSS and Radix UI?" type="info">
  The combination of Tailwind CSS and Radix UI gives ready-to-use, accessible UI components that can be fully customized to match your brands design.
</Callout>

## Tailwind configuration

In the `tooling/tailwind/config` directory you will find shared Tailwind CSS configuration files. To change some global styles you can edit the files in this folder.

Here is an example of a shared Tailwind configuration file:

```ts title="tooling/tailwind/config/base.ts"
import type { Config } from "tailwindcss";

export default {
  darkMode: "class",
  content: ["src/**/*.{ts,tsx}"],
  theme: {
    extend: {
      colors: {
        ...
        primary: {
          DEFAULT: "hsl(var(--color-primary))",
          foreground: "hsl(var(--color-primary-foreground))",
        },
        secondary: {
          DEFAULT: "hsl(var(--color-secondary))",
          foreground: "hsl(var(--color-secondary-foreground))",
        },
        success: {
          DEFAULT: "hsl(var(--color-success))",
          foreground: "hsl(var(--color-success-foreground))",
        },
        ...
      },
    },
  },
  plugins: [animate, containerQueries, typography],
} satisfies Config;
```

For the colors part, we bet stricly on [CSS Variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) in [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) format to allow for easy theme management without a need for any JavaScript.

Also, each app has its own `tailwind.config.ts` file which extends the shared config and allows you to override the global styles.

Here is an example of an app's `tailwind.config.ts` file:

```ts title="apps/mobile/tailwind.config.ts"
import type { Config } from "tailwindcss";
import { fontFamily } from "tailwindcss/defaultTheme";

import baseConfig from "@turbostarter/tailwind-config/web";

export default {
  // We need to append the path to the UI package to the content array so that
  // those classes are included correctly.
  content: [
    ...baseConfig.content,
    "../../packages/ui/{shared,web}/src/**/*.{ts,tsx}",
  ],
  presets: [baseConfig],
  theme: {
    extend: {
      fontFamily: {
        sans: ["DM Sans", ...fontFamily.sans],
        mono: ["DM Mono", ...fontFamily.mono],
      },
    },
  },
} satisfies Config;
```

That way we can have a separation of concerns and a clear structure for the Tailwind CSS configuration.

## Themes

TurboStarter comes with **9+** predefined themes which you can use to quickly change the look and feel of your app.

They're defined in `packages/ui/shared/src/styles/themes` directory. Each theme is a set of variables that can be overridden:

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

Each variable is stored as a [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) array, which is then converted to a CSS variable at build time (by our custom build script). That way we can ensure full type-safety and reuse themes across parts of our apps (e.g. use the same theme in emails).

Feel free to add your own themes or override the existing ones to match your brand's identity.

To apply a theme to your app, you can use the `data-theme` attribute on your layout wrapper for each part of the extension:

```tsx title="components/layout/layout.tsx"
import { StorageKey, useStorage } from "~/lib/storage";

export const Layout = ({ children }: { children: React.ReactNode }) => {
  const { data } = useStorage(StorageKey.THEME);

  return (
    <div id="root" data-theme={data.color}>
      {children}
    </div>
  );
};
```

In TurboStarter, we're using [Storage API](/docs/extension/structure/storage) to persist the user's theme selection and then apply it to the root `div` element.

## Dark mode

The starter kit comes with a built-in dark mode support.

Each theme has a corresponding dark mode variables which are used to change the theme to its dark mode counterpart.

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {},
  dark: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

As we define the `darkMode` as `class` in the shared Tailwind configuration, we need to add the `dark` class to the root wrapper element to apply the dark mode styles.

The same as for the theme, we're using [Storage API](/docs/extension/structure/storage) to persist the user's dark mode selection and then apply correct class name to the root `div` element:

```tsx title="components/layout/layout.tsx"
import { StorageKey, useStorage } from "~/lib/storage";

export const Layout = ({ children }: { children: React.ReactNode }) => {
  const { data } = useStorage(StorageKey.THEME);

  return (
    <div
      id="root"
      data-theme={data.color}
      className={cn({
        dark:
          data.mode === THEME_MODE.DARK ||
          (data.mode === THEME_MODE.SYSTEM &&
            window.matchMedia("(prefers-color-scheme: dark)").matches),
      })}
    >
      {children}
    </div>
  );
};
```

We can define the default theme mode and color in [app configuration](/docs/extension/configuration/app).

<Cards>
  <Card title="Tailwind CSS" description="tailwindcss.com" href="https://tailwindcss.com/" />

  <Card title="Radix UI" description="radix-ui.com" href="https://www.radix-ui.com/" />
</Cards>


file: ./src/content/docs/extension/installation/clone.mdx
meta: {
  "title": "Cloning repository",
  "description": "Get the code to your local machine and start developing your extension.",
  "mirror": "../../web/installation/clone.mdx"
}
        


file: ./src/content/docs/extension/installation/commands.mdx
meta: {
  "title": "Common commands",
  "description": "Learn about common commands you need to know to work with the extension project.",
  "mirror": "../../web/installation/commands.mdx"
}
        


file: ./src/content/docs/extension/installation/conventions.mdx
meta: {
  "title": "Conventions",
  "description": "Some standard conventions used across TurboStarter codebase.",
  "mirror": "../../web/installation/conventions.mdx"
}
        


file: ./src/content/docs/extension/installation/dependencies.mdx
meta: {
  "title": "Managing dependencies",
  "description": "Learn how to manage dependencies in your project.",
  "mirror": "../../web/installation/dependencies.mdx"
}
        


file: ./src/content/docs/extension/installation/development.mdx
meta: {
  "title": "Development",
  "description": "Get started with the code and develop your browser extension."
}
        
## Prerequisites

To get started with TurboStarter, ensure you have the following installed and set up:

* [Node.js](https://nodejs.org/en) (20.x or higher)
* [Docker](https://www.docker.com) (only if you want to use local database)
* [pnpm](https://pnpm.io)

## Project development

<Steps>
  <Step>
    ### Install dependencies

    Install the project dependencies by running the following command:

    ```bash
    pnpm i
    ```

    <Callout title="Why pnpm?">
      It is a fast, disk space efficient package manager that uses hard links and symlinks to save one version of a module only ever once on a disk. It also has a great [monorepo support](https://pnpm.io/workspaces). Of course, you can change it to use [Bun](https://bunpkg.com), [yarn](https://yarnpkg.com) or [npm](https://www.npmjs.com) with minimal effort.
    </Callout>
  </Step>

  <Step>
    ### Setup environment variables

    Create a `.env.local` files from `.env.example` files and fill in the required environment variables.

    Check [Environment variables](/docs/extension/configuration/environment-variables) for more details on setting up environment variables.
  </Step>

  <Step>
    ### Start database

    If you want to use local database (**recommended for development purposes**), ensure Docker is running, then setup your database with:

    ```bash
    pnpm db:setup
    ```

    This command initiates the PostgreSQL container and runs migrations, ensuring your database is up to date and ready to use.
  </Step>

  <Step>
    ### Start development server

    To start the application development server, run:

    ```bash
    pnpm dev
    ```

    Your development server should now be running 🎉

    WXT will create a dev bundle for your extension and a live-reloading development server, automatically updating your extension bundle on file changes and reloading your browser on source code changes.

    It also makes the icon grayscale to distinguish between development and production extension bundles.
  </Step>

  <Step>
    ### Load the extension

    <Tabs items={["Chrome", "Firefox"]}>
      <Tab value="Chrome">
        Head over to `chrome://extensions` and enable **Developer Mode**.

        ![Developer mode](/images/docs/extension/chrome/developer-mode.webp)

        Click on "Load Unpacked" and navigate to your extension's `apps/extension/build/chrome-mv3` directory.

        To see your popup, click on the puzzle piece icon on the Chrome toolbar, and click on your extension.

        ![Pin to toolbar](/images/docs/extension/chrome/pin.png)

        <Callout title="Pro tip">
          Pin your extension to the Chrome toolbar for easy access by clicking the pin button.
        </Callout>
      </Tab>

      <Tab value="Firefox">
        Head over to `about:debugging` and click on "This Firefox".

        Click on "Load Temporary Add-on" and navigate to your extension's `apps/extension/build/firefox-mv2` directory. Pick any file to load the extension.

        ![Load temporary add-on](/images/docs/extension/firefox/load.png)

        The extension now installs, and remains installed until you restart Firefox.

        To see your popup, click on your extension icon on the Firefox toolbar.

        ![Popup](/images/docs/extension/firefox/popup.png)

        <Callout title="Pro tip">
          Loaded extension starts as pinned on the Firefox toolbar. Don't remove it to easily access it later.
        </Callout>
      </Tab>
    </Tabs>

    <Callout title="Automatic browser startup">
      You can easily configure your development server to automatically start the browser when you start the server. To do it, create a `web-ext.config.ts` file in a root of your extension and configure it with your browser [binaries](https://wxt.dev/guide/essentials/config/browser-startup.html#set-browser-binaries) and [argumens](https://wxt.dev/guide/essentials/config/browser-startup.html#persist-data).

      Learn more in the [official documentation](https://wxt.dev/guide/essentials/config/browser-startup.html).
    </Callout>
  </Step>

  <Step>
    ### Publish to stores

    When you're ready to publish the project to the stores, follow the [guidelines](/docs/extension/marketing) and [checklist](/docs/extension/publishing/checklist) to ensure everything is set up correctly.
  </Step>
</Steps>


file: ./src/content/docs/extension/installation/editor-setup.mdx
meta: {
  "title": "Editor setup",
  "description": "Learn how to set up your editor for the fastest development experience.",
  "mirror": "../../web/installation/editor-setup.mdx"
}
        


file: ./src/content/docs/extension/installation/structure.mdx
meta: {
  "title": "Project structure",
  "description": "Learn about the project structure and how to navigate it."
}
        
The main directories in the project are:

* `apps` - the location of the main apps
* `packages` - the location of the shared code and the API

### `apps` Directory

This is where the apps live. It includes web app (Next.js), mobile app (React Native - Expo), and the browser extension (WXT - Vite + React). Each app has its own directory.

### `packages` Directory

This is where the shared code and the API for packages live. It includes the following:

* shared libraries (database, mailers, cms, billing, etc.)
* shared features (auth, mails, billing, ai etc.)
* UI components (buttons, forms, modals, etc.)

All apps can use and reuse the API exported from the packages directory. This makes it easy to have one, or many apps in the same codebase, sharing the same code.

## Repository structure

By default the monorepo contains the following apps and packages:

<Files>
  <Folder name="apps" defaultOpen>
    <Folder name="web - Web app (Next.js)" />

    <Folder name="mobile - Mobile app (React Native - Expo)" />

    <Folder name="extension - Browser extension (WXT - Vite + React)" />
  </Folder>

  <Folder name="packages" defaultOpen>
    <Folder name="api - API server (including all features logic)" />

    <Folder name="auth - Authentication setup" />

    <Folder name="billing - Billing config and providers" />

    <Folder name="cms - CMS setup and providers" />

    <Folder name="db - Database setup" />

    <Folder name="email - Mail templates and providers" />

    <Folder name="i18n - Internationalization setup" />

    <Folder name="shared - Shared utilities and helpers" />

    <Folder name="storage - Storage setup" />

    <Folder name="ui - Atomic UI components">
      <Folder name="shared" />

      <Folder name="web" />

      <Folder name="mobile" />
    </Folder>
  </Folder>

  <Folder name="tooling" defaultOpen>
    <Folder name="eslint - ESLint config" />

    <Folder name="github - Github actions" />

    <Folder name="prettier - Prettier config" />

    <Folder name="tailwind - Tailwind CSS config" />

    <Folder name="typescript - TypeScript config" />
  </Folder>
</Files>

## Browser extension application structure

The browser extension application is located in the `apps/extension` folder. It contains the following folders:

<Files>
  <Folder name="src" defaultOpen>
    <Folder name="app" defaultOpen>
      <Folder name="background - Background service worker" />

      <Folder name="content - Content scripts" />

      <Folder name="devtools - Devtools page with custom panels" />

      <Folder name="newtab - New tab page" />

      <Folder name="options - Options page" />

      <Folder name="popup - Popup window" />

      <Folder name="sidepanel - Side panel" />

      <Folder name="tabs - Custom pages shipped with the extension" />
    </Folder>

    <Folder name="assets - Optimized static assets" />

    <Folder name="components - Components for modules" />

    <Folder name="config - App config" />

    <Folder name="lib - Communication with packages" />

    <Folder name="public - Static assets" />
  </Folder>

  <File name=".env.local" />

  <File name="package.json" />

  <File name="tsconfig.json" />

  <File name="turbo.json" />

  <File name="wxt.config.ts" />
</Files>


file: ./src/content/docs/extension/installation/update.mdx
meta: {
  "title": "Updating codebase",
  "description": "Learn how to update your codebase to the latest version.",
  "mirror": "../../web/installation/update.mdx"
}
        


file: ./src/content/docs/extension/publishing/checklist.mdx
meta: {
  "title": "Checklist",
  "description": "Let's publish your TurboStarter extension to stores!"
}
        
When you're ready to publish your TurboStarter extension to stores, follow this checklist.

This process may take a few hours and some trial and error, so buckle up — you're almost there!

<Steps>
  <Step>
    ## Create database instance

    **Why it's necessary?**

    A production-ready database instance is essential for storing your application's data securely and reliably in the cloud. [PostgreSQL](https://www.postgresql.org/) is the recommended database for TurboStarter due to its robustness, features, and wide support.

    **How to do it?**

    You have several options for hosting your PostgreSQL database:

    * [Supabase](https://supabase.com/) - Provides a fully managed Postgres database with additional features
    * [Vercel Postgres](https://vercel.com/storage/postgres) - Serverless SQL database optimized for Vercel deployments
    * [Neon](https://neon.tech/) - Serverless Postgres with automatic scaling
    * [Turso](https://turso.tech/) - Edge database built on libSQL with global replication
    * [DigitalOcean](https://www.digitalocean.com/products/managed-databases) - Managed database clusters with automated failover

    Choose a provider based on your needs for:

    * Pricing and budget
    * Geographic region availability
    * Scaling requirements
    * Additional features (backups, monitoring, etc.)
  </Step>

  <Step>
    ## Migrate database

    **Why it's necessary?**

    Pushing database migrations ensures that your database schema in the remote database instance is configured to match TurboStarter's requirements. This step is crucial for the application to function correctly.

    **How to do it?**

    You basically have two possibilities for doing a migration:

    <Tabs items={["Using GitHub Actions (recommended)", "Running locally"]}>
      <Tab value="Using GitHub Actions (recommended)">
        TurboStarter comes with a predefined GitHub Action to handle database migrations. You can find its definition in the `.github/workflows/publish-db.yml` file.

        What you need to do is set your `DATABASE_URL` as a [secret for your GitHub repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).

        Then, you can run the workflow which will publish the database schema to your remote database instance.

        [Check how to run GitHub Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
      </Tab>

      <Tab value="Running locally">
        You can also run your migrations locally, although this is not recommended for production.

        To do so, set the `DATABASE_URL` environment variable to your database URL (that comes from your database provider) in the `.env.local` file and run the following command:

        ```bash
        pnpm db:migrate
        ```

        This command will run the migrations and apply them to your remote database.

        [Learn more about database migrations.](/docs/web/database/migrations)
      </Tab>
    </Tabs>
  </Step>

  <Step>
    ## Set up web backend API

    **Why it's necessary?**

    Setting up the backend is necessary to have a place to store your data and to have other features work properly (e.g., auth, billing).

    **How to do it?**

    Please refer to the [web deployment checklist](/docs/web/deployment/checklist) on how to set up and deploy the web app backend to production.
  </Step>

  <Step>
    ## Environment variables

    **Why it's necessary?**

    Setting the correct environment variables is essential for the extension to function correctly. These variables include API keys, database URLs, and other configuration details required for your extension to connect to various services.

    **How to do it?**

    Use our `.env.example` files to get the correct environment variables for your project. Then add them to your CI/CD provider as a [secret](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).
  </Step>

  <Step>
    ## Build your app

    **Why it's necessary?**

    Building your extension is necessary to create a standalone extension bundle that can be published to the stores.

    **How to do it?**

    You basically have two possibilities to build a bundle for your extension:

    <Tabs items={["Using GitHub Actions (recommended)", "Running locally"]}>
      <Tab value="Using GitHub Actions (recommended)">
        TurboStarter comes with a predefined GitHub Action to handle building your extension for submission. You can find its definition in the `.github/workflows/publish-extension.yml` file.

        [Check how to run GitHub Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)

        This will also save the `.zip` file as an [artifact](https://docs.github.com/en/actions/guides/storing-workflow-data-as-artifacts) of the workflow run, so you can download it from there and submit your extension to stores (if configured).
      </Tab>

      <Tab value="Running locally">
        You can also run your build locally, although this is not recommended for production.

        To do it, run the following command:

        ```bash
        pnpm turbo build --filter=extension
        ```

        This will build the extension and package it into a `.zip` file. You can find the output in the `build` folder.
      </Tab>
    </Tabs>
  </Step>

  <Step>
    ## Submit to stores

    **Why it's necessary?**

    Submitting your extension to the stores is necessary to make it available to your users. That's the only way to get your extension in front of your users.

    **How to do it?**

    We've prepared dedicated guides for each store that TurboStarter supports out-of-the-box, please refer to the following pages:

    <Cards>
      <Card title="Google Chrome Web Store" href="/docs/extension/publishing/chrome" description="Publish your extension to Google Chrome Web Store." />

      <Card title="Mozilla Add-ons" href="/docs/extension/publishing/mozilla" description="Publish your extension to Mozilla Add-ons." />
    </Cards>
  </Step>
</Steps>

That's it! Your extension is now live and accessible to your users, good job! 🎉

<Callout title="Other things to consider">
  * Optimize your store listing description, keywords, and other relevant information for the stores.
  * Remove the placeholder content in the extension or replace it with your own.
  * Update the favicon, scheme, store images, and logo with your own branding.
</Callout>


file: ./src/content/docs/extension/publishing/chrome.mdx
meta: {
  "title": "Chrome Web Store",
  "description": "Publish your extension to Google Chrome Web Store."
}
        
[Chrome Web Store](https://chromewebstore.google.com/) is the most popular store for browser extensions, as it makes them available in any Chromium-based browser, including Google Chrome, Edge, Brave, and many others.

To submit your extension to Chrome Web Store, you'll need to complete a few steps. Here, we'll go through them.

<Callout title="Prerequisite" type="warn">
  Make sure your extension follows the [guidelines](/docs/extension/marketing) and other requirements to increase your chances of getting approved.
</Callout>

## Developer account

Before you can publish items on the Chrome Web Store, you must register as a CWS developer and pay a one-time registration fee. You must provide a developer email when you create your developer account.

To register, just access the [developer console](https://chrome.google.com/webstore/devconsole). The first time you do this, the following registration screen will appear. First, agree to the developer agreement and policies, then pay the registration fee.

![Chrome registration fee](/images/docs/extension/chrome/fee.png)

Once you pay the registration fee and agree to the terms, your account will be created, and you'll be able to proceed to fill out additional information about it.

![Chrome developer account](/images/docs/extension/chrome/account.png)

There are a few fields that you'll need to fill in:

* **Publisher name**: Appears under the title of each of your extensions. If you are a verified publisher, you can display an official publisher URL instead.
* **Verified email**: Verifying your contact email address is required when you set up a new developer account. It's only displayed under your extensions' contact information. Any notifications will be sent to your Chrome Web Store developer account email.
* **Physical address**: Only items that offer functionality to purchase items, additional features, or subscriptions must include a physical address.

<Cards>
  <Card title="Register your developer account" href="https://developer.chrome.com/docs/webstore/register" description="developer.chrome.com" />
</Cards>

## Submission

After registering your developer account, setting it up, and preparing your extension, you're ready to publish it to the store.

You can submit your extension in two ways:

* **Manually**: By uploading your extension's bundle directly to the store.
* **Automatically**: By using GitHub Actions to submit your extension to the stores.

**The first submission must be done manually, while subsequent updates can be submitted automatically.** We'll go through both approaches.

### Manual submission

To manually submit your extension to stores, you will first need to get your extension bundle. If you ran the build step locally, you should already have the `.zip` file in your extension's `build` folder.

If you used GitHub Actions to build your extension, you can find the results in the workflow run. Download the artifacts and save them on your local machine.

Then, use the following steps to upload your item:

1. Go to the [Chrome Web Store Developer Dashboard](https://chrome.google.com/webstore/devconsole/).
2. Sign in to your developer account.
3. Click on the *Add new item* button.
4. Click *Choose file* > *your zip file* > *Upload*. If your item's manifest and other contents are valid, you will see a new item in the dashboard.

![Chrome extension page](/images/docs/extension/chrome/extension-page.png)

After you upload the bundle, you'll need to fill in the extension's details, such as the icons, privacy settings, permissions justification, and other information.

Please refer to the official guides on how to set up your extension's details.

<Cards>
  <Card title="Complete your listing information" href="https://developer.chrome.com/docs/webstore/cws-dashboard-listing" description="developer.chrome.com" />

  <Card title="Fill out the privacy fields" description="developer.chrome.com" href="https://developer.chrome.com/docs/webstore/cws-dashboard-privacy" />

  <Card title="Declare payment and set visibility" description="developer.chrome.com" href="https://developer.chrome.com/docs/webstore/cws-dashboard-distribution" />
</Cards>

### Automated submission

<Callout title="First submission must be done manually" type="warn">
  The first submission of your extension to Chrome Web Store must be done manually because you need to provide the store's credentials and extension ID to automation, which will be available only after the first bundle upload.
</Callout>

TurboStarter comes with a pre-configured GitHub Actions workflow to submit your extension to web stores automatically. It's located in the `.github/workflows/publish-extension.yml` file.

What you need to do is fill the environment variables with your store's credentials and extension's details and set them as a [secrets in your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions) under correct names:

```yaml title="publish-extension.yml"
env:
  CHROME_EXTENSION_ID: ${{ secrets.CHROME_EXTENSION_ID }}
  CHROME_CLIENT_ID: ${{ secrets.CHROME_CLIENT_ID }}
  CHROME_CLIENT_SECRET: ${{ secrets.CHROME_CLIENT_SECRET }}
  CHROME_REFRESH_TOKEN: ${{ secrets.CHROME_REFRESH_TOKEN }}
```

Please refer to the [official guide](https://github.com/PlasmoHQ/bms/blob/main/tokens.md#chrome-web-store-api) to learn how to get these credentials correctly.

That's it! You can [run the workflow](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow) and it will submit your extension to the Chrome Web Store 🎉

<Callout title="Automated submission to review">
  This workflow will also try to send your extension to review, but it's not guaranteed to happen. You need to have all required information filled in your extension's details page to make it possible.

  Even then, when you introduce some **breaking change** (e.g. add another permission), you'll need to update your extension store metadata and automatic submit won't be possible.

  To opt out of this behavior (and use only automatic uploading to store, but not sending to review) you can set `--chrome-skip-submit-review` flag in the `publish-extension.yml` file for the `wxt submit` command:

  ```yaml title="publish-extension.yml"
  // [!code word:--chrome-skip-submit-review]
  - name: 💨 Publish!
    run: |
      npx wxt submit \
        --chrome-zip apps/extension/build/*-chrome.zip --chrome-skip-submit-review
  ```

  Then, your extension bundle will be uploaded to the store, but you will need to send it to review manually.

  Check out the [official documentation](https://wxt.dev/api/cli/wxt-submit) for more customization options.
</Callout>

<Cards>
  <Card title="Use the Chrome Web Store Publish API" href="https://developer.chrome.com/docs/webstore/using-api" description="developer.chrome.com" />

  <Card title="How to generate Google API tokens?" href="https://github.com/PlasmoHQ/chrome-webstore-api/blob/main/token.md" description="github.com" />
</Cards>

## Review

After filling out the information about your item, you are ready to send it to review. Click on *Submit for review* button and confirm that you want to submit your item in the following dialog:

![Chrome submit for review](/images/docs/extension/chrome/send-to-review.png)

The confirmation dialog shown above also lets you control the timing of your item's publishing. If you uncheck the checkbox, your item will **not** be published immediately after its review is complete. Instead, you'll be able to manually publish it at a time of your choosing once the review is complete.

After you submit the item for review, it will undergo a review process. The time for this review depends on the nature of your item. See [Understanding the review process](https://developer.chrome.com/docs/webstore/review-process) for more details.

There are important emails like take down or rejection notifications that are enabled by default. To receive an email notification when your item is published or staged, you can enable notifications on the *Account page*.

![Chrome notifications](/images/docs/extension/chrome/notifications.png)

The review status of your item appears in the [developer dashboard](https://chrome.google.com/webstore/devconsole) next to each item. The status can be one of the following:

* **Published**: Your item is available to all users.
* **Pending**: Your item is under review.
* **Rejected**: Your item was rejected by the store.
* **Taken Down**: Your item was taken down by the store.

![Chrome extension status](/images/docs/extension/chrome/review-status.png)

You'll receive an email notification when the status of your item changes.

<Callout title="Your submission might be rejected" type="error">
  If your extension has been determined to violate one or more terms or policies, you will receive an email notification that contains the violation description and instructions on how to rectify it.

  If you did not receive an email within a week, check the status of your item. If your item has been rejected, you can see the details on the *Status* tab of your item.

  ![Chrome extension rejected](/images/docs/extension/chrome/rejection.png)

  You'll need to fix the issues and upload a new version of your extension, make sure to follow the [guidelines](/docs/extension/marketing) or check [publishing troubleshooting](/docs/extension/troubleshooting/publishing) for more info.

  If you have been informed about a violation and you do not rectify it, your item will be taken down. See [Violation enforcement](https://developer.chrome.com/docs/webstore/review-process#enforcement) for more details.
</Callout>

You can learn more about the review process in the official guides listed below.

<Cards>
  <Card title="Chrome Web Store review process" href="https://developer.chrome.com/docs/webstore/review-process" description="developer.chrome.com" />

  <Card title="Troubleshooting Chrome Web Store violations" href="https://developer.chrome.com/docs/webstore/troubleshooting" description="developer.chrome.com" />
</Cards>


file: ./src/content/docs/extension/publishing/mozilla.mdx
meta: {
  "title": "Mozilla Add-ons",
  "description": "Publish your extension to Mozilla Add-ons."
}
        
Mozilla Firefox doesn't share extensions with [Google Chrome](/docs/extension/publishing/chrome), so you'll need to publish your extension to it separately.

Here, we'll go through the process of publishing an extension to [Mozilla Add-ons](https://addons.mozilla.org/).

<Callout title="Prerequisite" type="warn">
  Make sure your extension follows the [guidelines](/docs/extension/marketing) and other requirements to increase your chances of getting approved.
</Callout>

## Developer account

Before you can publish items on Mozilla Add-ons, you must register a developer account. In comparison to the Chrome Web Store, Mozilla Add-ons doesn't require a registration fee.

To register, go to [addons.mozilla.org](https://addons.mozilla.org/) and click on the *Register* button.

![Mozilla registration](/images/docs/extension/firefox/portal.png)

It's important to set at least a display name on your profile to increase transparency with users, add-on reviewers, and the greater community.

You can do it in the *Edit My Profile* section:

![Mozilla profile](/images/docs/extension/firefox/profile.png)

<Cards>
  <Card title="Developer accounts" href="https://extensionworkshop.com/documentation/publish/developer-accounts/" description="extensionworkshop.com" />
</Cards>

## Submission

After registering your developer account, setting it up, and preparing your extension, you're ready to publish it to the store.

You can submit your extension in two ways:

* **Manually**: By uploading your extension's bundle directly to the store.
* **Automatically**: By using GitHub Actions to submit your extension to the stores.

**The first submission must be done manually, while subsequent updates can be submitted automatically.** We'll go through both approaches.

### Manual submission

To manually submit your extension to stores, you will first need to get your extension bundle. If you ran the build step locally, you should already have the `.zip` file in your extension's `build` folder.

If you used GitHub Actions to build your extension, you can find the results in the workflow run. Download the artifacts and save them on your local machine.

Then, use the following steps to upload your item:

<Steps>
  <Step>
    #### Sign in to your developer account

    Go to the [Add-ons Developer Hub](https://addons.mozilla.org/developers/) and sign in to your developer account.
  </Step>

  <Step>
    #### Choose distribution method

    You should reach the following page:

    ![Mozilla distribution](/images/docs/extension/firefox/distribution.png)

    Here, you have two ways of distributing your extension:

    * **On this site**, if you want your add-on listed on AMO (Add-ons Manager).
    * **On your own**, if you plan to distribute the add-on yourself and don't want it listed on AMO.

    We recommend going with the first option, as it will allow you to reach more users and get more feedback. If you decide to go with the second option, please refer to the [official documentation](https://extensionworkshop.com/documentation/publish/self-distribution/) for more details.
  </Step>

  <Step>
    #### Submit your extension

    On the next page, click on *Select file* and choose your extension's `.zip` bundle.

    ![Mozilla upload](/images/docs/extension/firefox/upload.png)

    Once you upload the bundle, the validator checks the add-on for issues and the page updates:

    ![Mozilla validation](/images/docs/extension/firefox/validation.png)

    If your add-on passes all the checks, you can proceed to the next step.

    <Callout type="warn">
      You may receive a message that you only have warnings. It's advisable to address these warnings, particularly those flagged as security or privacy issues, as they may result in your add-on failing review. However, **you can continue with the submission**.
    </Callout>

    If the validation fails, you'll need to address the issues and upload a new version of your add-on.
  </Step>

  <Step>
    #### Submit source code (if needed)

    You'll need to indicate whether you need to provide the source code of your extension:

    ![Mozilla source code](/images/docs/extension/firefox/source-code.png)

    If you select *Yes*, a section displays describing what you need to submit. Click *Browse* and locate and upload your source code package. See [Source code submission](https://extensionworkshop.com/documentation/publish/source-code-submission/) for more information.

    <Callout type="warn">
      You may receive a message that you only have warnings. It's advisable to address these warnings, particularly those flagged as security or privacy issues, as they may result in your add-on failing review. However, **you can continue with the submission**.
    </Callout>

    If the validation fails, you'll need to address the issues and upload a new version of your add-on.
  </Step>

  <Step>
    #### Add metadata

    On the next page, you'll need to provide the following additional information about your extension:

    ![Mozilla additional information](/images/docs/extension/firefox/additional-info.png)

    * **Name**: Your add-on's name.
    * **Add-on URL**: The URL for your add-on on AMO. A URL is automatically assigned based on your add-on's name. To change this, click Edit. The URL must be unique. You will be warned if another add-on is using your chosen URL, and you must enter a different one.
    * **Summary**: A useful and descriptive short summary of your add-on.
    * **Description**: A longer description that provides users with details of the extension's features and functionality.
    * **This add-on is experimental**: Indicate if your add-on is experimental or otherwise not ready for general use. The add-on will be listed but with reduced visibility. You can remove this flag when your add-on is ready for general use.
    * **This add-on requires payment, non-free services or software, or additional hardware**: Indicate if your add-on requires users to make an additional purchase for it to work fully.
    * **Select up to 2 Firefox categories for this add-on**: Select categories that describe your add-on.
    * **Select up to 2 Firefox for Android categories for this add-on**: Select categories that describe your add-on.
    * **Support email and Support website**: Provide an email address and website where users can get in touch when they have questions, issues, or compliments.
    * **License**: Select the appropriate license for your add-on. Click Details to learn more about each license.
    * **This add-on has a privacy policy**: If any data is being transmitted from the user's device, a privacy policy explaining what is being sent and how it's used is required. Check this box and provide the privacy policy.
    * **Notes for Reviewers**: Provide information to assist the AMO reviewer, such as login details for a dummy account, source code information, or similar.
  </Step>

  <Step>
    #### Finalize the process

    Once you're ready, click on the *Submit Version* button.

    ![Mozilla submit](/images/docs/extension/firefox/submit.png)

    You can still edit your add-on's details from the dedicated page after submission.
  </Step>
</Steps>

<Cards>
  <Card title="Resources for publishers" href="https://extensionworkshop.com/documentation/manage/resources-for-publishers/" description="extensionworkshop.com" />

  <Card title="Source code submission" href="https://extensionworkshop.com/documentation/publish/source-code-submission/" description="extensionworkshop.com" />
</Cards>

<Callout title="First submission must be done manually" type="warn">
  The first submission of your extension to Mozilla Add-ons must be done manually because you need to provide the store's credentials and extension ID to automation, which will be available only after the first bundle upload.
</Callout>

TurboStarter comes with a pre-configured GitHub Actions workflow to submit your extension to web stores automatically. It's located in the `.github/workflows/publish-extension.yml` file.

What you need to do is fill the environment variables with your store's credentials and extension's details and set them as a [secrets in your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions) under correct names:

```yaml title="publish-extension.yml"
env:
  FIREFOX_EXTENSION_ID: ${{ secrets.FIREFOX_EXTENSION_ID }}
  FIREFOX_JWT_ISSUER: ${{ secrets.FIREFOX_JWT_ISSUER }}
  FIREFOX_JWT_SECRET: ${{ secrets.FIREFOX_JWT_SECRET }}
```

Please refer to the [official guide](https://github.com/PlasmoHQ/bms/blob/main/tokens.md#firefox-add-ons-api) to learn how to get these credentials correctly.

That's it! You can [run the workflow](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow) and it will submit your extension to the Mozilla Add-ons 🎉

<Callout title="Automated submission to review">
  This workflow will also try to send your extension to review, but it's not guaranteed to happen. You need to have all required information filled in your extension's details page to make it possible.

  Even then, when you introduce some **breaking change** (e.g., add another permission), you'll need to update your extension store metadata and automatic submission won't be possible.
</Callout>

<Cards>
  <Card title="A new API for submitting and updating add-ons" href="https://blog.mozilla.org/addons/2022/03/17/new-api-for-submitting-and-updating-add-ons/" description="blog.mozilla.org" />

  <Card title="Mozilla API keys" href="https://addons.mozilla.org/en-US/developers/addon/api/key/" description="addons.mozilla.org" />
</Cards>

## Review

Once you submit your extension bundle, it's automatically sent to review and will undergo a review process. The time for this review depends on the nature of your item.

The add-on review process includes the following phases:

1. **Automatic Review**: Upon upload, the add-on undergoes several automatic validation steps to ensure its general safety.
2. **Content Review**: Shortly after submission, a human reviewer inspects the add-on to ensure that the listing adheres to content review guidelines, including metadata such as the add-on name and description.
3. **Technical Code Review**: The add-on's source code is examined to ensure compliance with review policies.
4. **Basic Functionality Testing**: After the source code is verified as safe, the add-on undergoes basic functionality testing to confirm it operates as described.

There are important emails like takedown or rejection notifications that are enabled by default. To receive an email notification when your item is published or staged, you can enable notifications in the *Account Settings*.

![Mozilla notifications](/images/docs/extension/firefox/notifications.png)

The review status of your item appears in the [developer hub](https://addons.mozilla.org/en-US/firefox/) next to each item.

![Mozilla review status](/images/docs/extension/firefox/review-status.png)

You'll receive an email notification when the status of your item changes.

<Callout title="Your submission might be rejected" type="error">
  If your extension has been determined to violate one or more terms or policies, you will receive an email notification that contains the violation description and instructions on how to rectify it.

  You can also check the reason behind the rejection on the *Status* page of your item.

  ![Mozilla extension rejected](/images/docs/extension/firefox/rejection.png)

  You'll need to fix the issues and upload a new version of your extension. Make sure to follow the [guidelines](/docs/extension/marketing) or check [publishing troubleshooting](/docs/extension/troubleshooting/publishing) for more info.
</Callout>

You can learn more about the review process in the official guides listed below.

<Cards>
  <Card title="Add-ons/Reviewers/Guide/Reviewing" href="https://wiki.mozilla.org/Add-ons/Reviewers/Guide/Reviewing" description="wiki.mozilla.org" />

  <Card title="Add-ons/Reviewers/Content Review Guidelines" href="https://wiki.mozilla.org/Add-ons/Reviewers/Content_Review_Guidelines" description="wiki.mozilla.org" />
</Cards>


file: ./src/content/docs/extension/publishing/updates.mdx
meta: {
  "title": "Updates",
  "description": "Learn how to update your published extension."
}
        
When you publish your extension to the stores, you can update it later to give your users new features and bug fixes.

TurboStarter comes with ready-to-use way to update your extensions, we'll quickly go through it.

## Uploading new version

The best way to update your extension is to submit a new version to the stores. This is the most reliable way to update your extension, but it can take a while for the new version to be approved and available to the users.

To submit a new version, you just need to change the version number in the `package.json` file:

```json title="package.json"
{
    ...
    "version": "1.0.1",
    ...
}
```

Then, follow the exact same steps as [when you initially published your extension](/docs/extension/publishing/checklist), and, when you'll submit your extension to review, provide release notes for the new version.


file: ./src/content/docs/extension/structure/background.mdx
meta: {
  "title": "Background service worker",
  "description": "Configure your extension's background service worker."
}
        
An extension's service worker is a powerful script that runs in the background, separate from other parts of the extension. It's loaded when it is needed, and unloaded when it goes dormant.

Once loaded, an extension service worker generally runs as long as it is actively receiving events, though it [can shut down](https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle#idle-shutdown). Like its web counterpart, an extension service worker cannot access the DOM, though you can use it if needed with [offscreen documents](https://developer.chrome.com/docs/extensions/reference/api/offscreen).

Extension service workers are more than network proxies (as web service workers are often described), they run in a separate [service worker context](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers). For example, when in this context, you no longer need to worry about CORS and can fetch resources from any origin.

In addition to the [standard service worker events](https://developer.mozilla.org/docs/Web/API/ServiceWorkerGlobalScope#events), they also respond to extension events such as navigating to a new page, clicking a notification, or closing a tab. They're also registered and updated differently from web service workers.

**It's common to offload heavy computation to the background service worker**, so you should always try to do resouce-expensive operations there and send results using [Messages API](/docs/extension/structure/messaging) to other parts of the extension.

Code for the background service worker is located at `src/app/background` directory - you need to use `defineBackground` within `index.ts` file inside to allow WXT to include your script in the build.

```ts title="src/app/background/index.ts"
import { defineBackground } from "wxt/sandbox";

const main = () => {
  console.log(
    "Background service worker is running! Edit `src/app/background` and save to reload.",
  );
};

export default defineBackground(main);
```

To see the service worker in action, reload the extension, then open its "Service Worker inspector":

![Service Worker inspector](/images/docs/extension/structure/sw-inspector.png)

You should see what we've logged in the console:

![Service Worker console](/images/docs/extension/structure/sw-log.png)

To communicate with the service worker from other parts of the extension, you can use the [Messaging API](/docs/extension/structure/messaging).

## Persisting state

<Callout>
  Service workers in `dev` mode always remain in `active` state.
</Callout>

The worker becomes idle after a few seconds of inactivity, and the browser will kill its process entirely after 5 minutes. This means all state (variables, etc.) is lost unless you use a storage engine.

The simplest way to persist your background service worker's state is to use the [storage API](/docs/extension/structure/storage).

The more advanced way is to send the state to a remote database via our [backend API](/docs/extension/api/overview).

<Cards>
  <Card title="Using service workers" href="https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers" description="developer.mozilla.org" />

  <Card title="Migrate to a service worker" href="https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers" description="developer.chrome.com" />

  <Card title="Extension service worker basics" href="https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/basics" description="developer.chrome.com" />

  <Card title="The extension service worker lifecycle" href="https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle" description="developer.chrome.com" />
</Cards>


file: ./src/content/docs/extension/structure/content-scripts.mdx
meta: {
  "title": "Content scripts",
  "description": "Learn more about content scripts."
}
        
Content scripts run in the context of web pages in an isolated world. This allows multiple content scripts from various extensions to coexist without conflicting with each other's execution and to stay isolated from the page's JavaScript.

A script that ends with `.ts` will not have front-end runtime (e.g. react) bundled with it and won't be treated as a ui script, while a script that ends in `.tsx` will be.

There are many use cases for content scripts:

* Injecting a custom stylesheet into the page
* Scraping data from the current web page
* Selecting, finding, and styling elements from the current web page
* Injecting UI elements into current web page

Code for the content scripts is located in `src/app/content` directory - you need to define `.ts` or `.tsx` file inside and use `defineContentScript` to allow WXT to include your script in the build.

```ts title="src/app/content/index.ts"
export default defineContentScript({
  matches: ["<all_urls>"],
  async main(ctx) {
    console.log(
      "Content script is running! Edit `app/content` and save to reload.",
    );
  },
});
```

Reload your extension, open a web page, then open its inspector:

![Content Script](/images/docs/extension/structure/content-script.png)
To learn more about content scripts, e.g. how to configure only specific pages to load content scripts, how to inject them into `window` object or how to fetch data inside, please check [the official documentation](https://wxt.dev/guide/essentials/content-scripts.html).

## UI scripts

WXT has first-class support for mounting React components into the current webpage. This feature is called content scripts UI (CSUI).

![CSUI](/images/docs/extension/structure/csui.png)

An extension can have as many CSUI as needed, with each CSUI targeting a group of webpages or a specific webpage.

To get started with CSUI, create a `.tsx` file in `src/app/content` directory and use `defineContentScript` allow WXT to include your script in the build and mount your component into the current webpage:

```tsx title="src/app/content/index.tsx"
const ContentScriptUI = () => {
  return (
    <Button onClick={() => alert("This is injected UI!")}>
      Content script UI
    </Button>
  );
};

export default defineContentScript({
  matches: ["<all_urls>"],
  cssInjectionMode: "ui",
  async main(ctx) {
    const ui = await createShadowRootUi(ctx, {
      name: "turbostarter-extension",
      position: "overlay",
      anchor: "body",
      onMount: (container) => {
        const app = document.createElement("div");
        container.append(app);

        const root = ReactDOM.createRoot(app);
        root.render(<ContentScriptUI />);
        return root;
      },
      onRemove: (root) => {
        root?.unmount();
      },
    });

    ui.mount();
  },
});
export default ContentScriptUI;
```

<Callout title="File extensions matters!" type="warn">
  The `.tsx` extension is essential to differentiate between Content Scripts UI and regular Content Scripts. Make sure to check if you're using appropriate type of content script for your use case.
</Callout>

To learn more about content scripts UI, e.g. how to inject custom styles, fonts or the whole lifecycle of a component, please check [the official documentation](https://wxt.dev/guide/essentials/content-scripts.html#ui).

<Callout title="How does it work?">
  Under the hood, the component is wrapped inside the component that implements the Shadow DOM technique, together with many helpful features. This isolation technique prevents the web page's style from affecting your component's styling and vice-versa.

  [Read more about the lifecycle of CSUI](https://docs.plasmo.com/framework/content-scripts-ui/life-cycle)
</Callout>


file: ./src/content/docs/extension/structure/messaging.mdx
meta: {
  "title": "Messaging",
  "description": "Communicate between your extension's components."
}
        
Messaging API makes communication between different parts of your extension easy. To make it simple and scalable, we're leveraging `@webext-core/messaging` library.

It provides a declarative, type-safe, functional, promise-based API for sending, relaying, and receiving messages between your extension components.

## Handling messages

Based on our convention, we implemented a little abstraction on top of `@webext-core/messaging` to make it easier to use. That's why all types and keys are stored inside `lib/messaging` directory:

```ts title="lib/messaging/index.ts"
import { defineExtensionMessaging } from "@webext-core/messaging";

export const Message = {
  HELLO: "hello",
} as const;

export type Message = (typeof Message)[keyof typeof Message];

interface Messages {
  [Message.HELLO]: (message: string) => string;
}

export const { onMessage, sendMessage } = defineExtensionMessaging<Messages>();
```

There you need to define what will be handled under each key. To make it more secure, only `Message` enum and `onMessage` and `sendMessage` functions are exported from the module.

All message handlers are located in `src/app/background/messaging` directory under respective subdirectories.

To create a message handler, create a TypeScript module in the `background/messaging` directory. Then, include your handlers for all keys related to the message:

```ts title="app/background/messaging/hello.ts"
import { onMessage, Message } from "~/lib/messaging";

onMessage(Message.HELLO, (req) => {
  const result = await querySomeApi(req.body.id);

  return result;
});
```

<Callout title="Don't forget to import!" type="warn">
  To make your handlers available across your extension, you need to import them
  in the `background/index.ts` file. That way they could be interpreted by the
  build process facilitated by WXT.
</Callout>

## Sending messages

Extension pages, content scripts, or tab pages can send messages to the handlers using the `sendMessage` function. Since we orchestrate your handlers behind the scenes, the message names are typed and will enable autocompletion in your editor:

```tsx title="app/popup/index.tsx"
import { sendMessage, Message } from "~/lib/messaging";

...

const response = await sendMessage(Message.HELLO, "Hello, world!");

console.log(response);

...
```

As it's an asynchronous operation, it's advisable to use [@tanstack/react-query](https://tanstack.com/query/latest/docs/framework/react/overview) integration to handle the response on the client side.

We're already doing it that way when fetching auth session in the `User` component:

```tsx title="hello.tsx"
export const Hello = () => {
  const { data, isLoading } = useQuery({
    queryKey: [Message.HELLO],
    queryFn: () => sendMessage(Message.HELLO, "Hello, world!"),
  });

  if (isLoading) {
    return <p>Loading...</p>;
  }

  /* do something with the data... */
  return <p>{data?.message}</p>;
};
```

<Cards>
  <Card href="https://webext-core.aklinker1.io/messaging/installation/" title="Messaging API" description="webext-core.aklinker1.io" />

  <Card title="Message passing" description="developer.chrome.com" href="https://developer.chrome.com/docs/extensions/develop/concepts/messaging" />
</Cards>


file: ./src/content/docs/extension/structure/overview.mdx
meta: {
  "title": "Overview",
  "description": "Learn about the structure of the extension app.",
  "index": true
}
        
Every browser extension is different and can include different parts, removing the ones that are not needed.

TurboStarter ships with all the things you need to start developing your own extension including:

* **Popup window** - a small window that appears when the user clicks the extension icon.
* **Options page** - a page that appears when user enters extension settings.
* **Side panel** - a panel that appears when the user clicks sidepanel.
* **New tab page** - a page that appears when the user opens a new tab.
* **Devtools page** - a page that appears when the user opens the browser's devtools.
* **Tab pages** - custom pages shipped with the extension.
* **Content scripts** - injected scripts that run in the browser page.
* **Background scripts** - scripts that run in the background.
* **Message passing** - a way to communicate between different parts of the extension.
* **Storage** - a way to store data in the extension.

All the entrypoints are defined in `apps/extension/src/app` directory (it's similar to file-based routing in Next.js and Expo).

This directory acts as a source for WXT framework which is used to build the extension. It has the following structure:

<Files>
  <Folder name="app" defaultOpen>
    <Folder name="background - Background service worker" />

    <Folder name="content - Content scripts" />

    <Folder name="devtools - Devtools page with custom panels" />

    <Folder name="newtab - New tab page" />

    <Folder name="options - Options page" />

    <Folder name="popup - Popup window" />

    <Folder name="sidepanel - Side panel" />

    <Folder name="tabs - Custom pages shipped with the extension" />
  </Folder>
</Files>

By structurizing it this way, we can easily add new entrypoints in the future and extend rest of the extension independently from each other.

We'll go through each part and explain the purpose of it, check following sections for more details:


file: ./src/content/docs/extension/structure/pages.mdx
meta: {
  "title": "Pages",
  "description": "Get started with your extension's pages."
}
        
Extension pages are built-in pages recognized by the browser. They include the extension's popup, options, sidepanel and newtab pages.

<Callout>
  As WXT is based on Vite, it has very powerful [HMR support](https://vite.dev/guide/features#hot-module-replacement). This means that you don't need to refresh the extension manually when you make changes to the code.
</Callout>

## Popup

The popup page is a small dialog window that opens when a user clicks on the extension's icon in the browser toolbar. It is the most common type of extension page.

![Popup window](/images/docs/extension/structure/popup.png)

<Cards>
  <Card title="Add a popup" href="https://developer.chrome.com/docs/extensions/develop/ui/add-popup" description="developer.chrome.com" />

  <Card title="Entrypoints" href="https://wxt.dev/guide/essentials/entrypoints.html" description="wxt.dev" />
</Cards>

## Options

The options page is meant to be a dedicated place for the extension's settings and configuration.

![Options page](/images/docs/extension/structure/options.png)

<Card title="Give users options" href="https://developer.chrome.com/docs/extensions/develop/ui/options-page" description="developer.chrome.com" />

## Devtools

The devtools page is a custom page (including panels) that opens when a user opens the extension's devtools panel.

![Devtools page](/images/docs/extension/structure/devtools.png)

<Card title="Extend devtools" href="https://developer.chrome.com/docs/extensions/how-to/devtools/extend-devtools" description="developer.chrome.com" />

## New tab

The new tab page is a custom page that opens when a user opens a new tab in the browser.

![New tab page](/images/docs/extension/structure/newtab.png)

<Card title="Override Chrome pages" href="https://developer.chrome.com/docs/extensions/develop/ui/override-chrome-pages" description="developer.chrome.com" />

## Side panel

The side panel is a custom page that opens when a user clicks on the extension's icon in the browser toolbar.

![Side panel](/images/docs/extension/structure/sidepanel.png)

<Card title="Side panel" href="https://developer.chrome.com/docs/extensions/reference/api/sidePanel" description="developer.chrome.com" />

## Tabs

Unlike traditional extension pages, tab (unlisted) pages are just regular web pages shipped with your extension bundle. Extensions generally redirect to or open these pages programmatically, but you can link to them as well.

They could be useful for following cases:

* when you want to show a some page when user first installs your extension
* when you want to have dedicated pages for authentication
* when you need more advanced routing setup

![Tab page](/images/docs/extension/structure/tabs.png)

Your tab page will be available under the `/tabs` path in the extension bundle. It will be accessible from the browser under the URL:

```
chrome-extension://<your-extension-id>/tabs/your-tab-page.html
```

<Card title="Unlisted pages" href="https://wxt.dev/guide/essentials/entrypoints.html#unlisted-pages" description="wxt.dev" />


file: ./src/content/docs/extension/structure/storage.mdx
meta: {
  "title": "Storage",
  "description": "Learn how to store data in your extension."
}
        
TurboStarter leverages `wxt/storage` library to handle persistent storage for your extension. It's a utility library from that abstracts the persistent storage API available to browser extensions.

It falls back to localStorage when the extension storage API is unavailable, allowing for state sync between extension pages, content scripts, background service workers and web pages.

<Callout>
  To use the `wxt/storage` API, the "storage" permission **must** be added to the manifest:

  ```ts title="wxt.config.ts"
  export default defineConfig({
    manifest: {
      permissions: ["storage"],
    },
  });
  ```
</Callout>

## Storing data

The base Storage API is designed to be easy to use. It is usable in every extension runtime such as background service workers, content scripts and extension pages.

TurboStarter ships with predefined storage used to handle [theming](/docs/extension/customization/styling) in your extension, but you can create your own storage as well.

All storage-related methods and types are located in `lib/storage` directory.

```ts title="lib/storage/index.ts"
export const StorageKey = {
  THEME: "local:theme",
} as const;

export type StorageKey = (typeof StorageKey)[keyof typeof StorageKey];
```

Then, to make it available around your extension, we're setting it up and providing default values:

```ts title="lib/storage/index.ts"
import { storage as browserStorage } from "wxt/storage";

import { appConfig } from "~/config/app";

import type { ThemeConfig } from "@turbostarter/ui";

const storage = {
  [StorageKey.THEME]: browserStorage.defineItem<ThemeConfig>(StorageKey.THEME, {
    fallback: appConfig.theme,
  }),
} as const;
```

To learn more about customizing your storage, syncing state or setup automatic backups please refer to the [official documentation](https://wxt.dev/storage.html).

## Consuming storage

To consume storage in your extension, you can use the `useStorage` React hook that is automatically provided to every part of the extension. The hook API is designed to streamline the state-syncing workflow between the different pieces of an extension.

Here is an example on how to consume our theme storage in `Layout` component:

```tsx title="components/layout/layout.tsx"
import { StorageKey, useStorage } from "~/lib/storage";

export const Layout = ({ children }: { children: React.ReactNode }) => {
  const { data } = useStorage(StorageKey.THEME);

  return (
    <div id="root" data-theme={data.color}>
      {children}
    </div>
  );
};
```

Congrats! You've just learned how to persist and consume global data in your extension 🎉

For more advanced use cases, please refer to the [official documentation](https://wxt.dev/storage.html).

### Usage with Firefox

To use the storage API on Firefox during development you need to add an addon ID to your manifest, otherwise, you will get this error:

> Error: The storage API will not work with a temporary addon ID. Please add an explicit addon ID to your manifest. For more information see [https://mzl.la/3lPk1aE](https://mzl.la/3lPk1aE)

To add an addon ID to your manifest, add this to your package.json:

```ts title="wxt.config.ts"
export default defineConfig({
  manifest: {
    browser_specific_settings: {
      gecko: {
        id: "your-id@example.com",
      },
    },
  },
});
```

During development, you may use any ID. If you have published your extension, you need to use the ID assigned by [Mozilla Addons](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons).

<Cards>
  <Card title="Storage API" href="https://wxt.dev/storage.html" description="wxt.dev" />

  <Card title="chrome.storage" href="https://developer.chrome.com/docs/extensions/reference/api/storage" description="developer.chrome.com" />
</Cards>


file: ./src/content/docs/extension/troubleshooting/installation.mdx
meta: {
  "title": "Installation",
  "description": "Find answers to common extension installation issues."
}
        
## Cannot clone the repository

Issues related to cloning the repository are usually related to a Git misconfiguration in your local machine. The commands displayed in this guide using SSH: these will work only if you have setup your SSH keys in Github.

If you run into issues, [please make sure you follow this guide to set up your SSH key in Github.](https://docs.github.com/en/authentication/connecting-to-github-with-ssh)

If this also fails, please use HTTPS instead. You will be able to see the commands in the repository's Github page under the "Clone" dropdown.

Please also make sure that the account that accepted the invite to TurboStarter, and the locally connected account are the same.

## Local database doesn't start

If you cannot run the local database container, it's likely you have not started [Docker](https://docs.docker.com/get-docker/) locally. Our local database requires Docker to be installed and running.

Please make sure you have installed Docker (or compatible software such as [Colima](https://github.com/abiosoft/colima), [Orbstack](https://github.com/orbstack/orbstack)) and that is running on your local machine.

Also, make sure that you have enough [memory and CPU allocated](https://docs.docker.com/engine/containers/resource_constraints/) to your Docker instance.

## Permissions issues

If some feature of your extension is not working, it's possible that you're missing a permission in the manifest config.

Make sure to check the [permissions](/docs/extension/configuration/manifest#overriding-manifest) section in the manifest config file.

## I don't see my translations

If you don't see your translations appearing in the application, there are a few common causes:

1. Check that your translation `.json` files are properly formatted and located in the correct directory
2. Verify that the language codes in your configuration match your translation files
3. Enable debug mode (`debug: true`) in your i18next configuration to see detailed logs

[Read more about configuration for translations](/docs/extension/internationalization#configuration)

## "Module not found" error

This issue is mostly related to either dependency installed in the wrong package or issues with the file system.

The most common cause is incorrect dependency installation. Here's how to fix it:

1. Clean the workspace:

   ```bash
   pnpm clean
   ```

2. Reinstall the dependencies:
   ```bash
   pnpm i
   ```

If you're adding new dependencies, make sure to install them in the correct package:

```bash
# For main app dependencies
pnpm install --filter mobile my-package

# For a specific package
pnpm install --filter @turbostarter/ui my-package
```

If the issue persists, please check the file system for any issues.

### Windows OneDrive

OneDrive can cause file system issues with Node.js projects due to its file syncing behavior. If you're using Windows with OneDrive, you have two options to resolve this:

1. Move your project to a location outside of OneDrive-synced folders (recommended)
2. Disable OneDrive sync specifically for your development folder

This prevents file watching and symlink issues that can occur when OneDrive tries to sync Node.js project files.


file: ./src/content/docs/extension/troubleshooting/publishing.mdx
meta: {
  "title": "Publishing",
  "description": "Find answers to common publishing issues."
}
        
## My extension submission was rejected

If your extension submission was rejected, you probably got an email with the reason. You'll need to fix the issues and upload a new build of your extension to the store and send it for review again.

Make sure to follow the [guidelines](/docs/extension/marketing) when submitting your extension to ensure that everything is setup correctly.

## Version number mismatch

If you get version number conflicts when submitting:

1. Ensure your `manifest.json` version matches what's in the store
2. Increment the version number appropriately for each new submission
3. Make sure the version follows semantic versioning (e.g., `1.0.1`)

## Missing permissions in manifest

If your extension is rejected due to permission issues:

1. Review the permissions declared in your `manifest.json`
2. Ensure all permissions are properly justified in your submission
3. Remove any unused permissions that aren't essential
4. Consider using optional permissions where possible

[Learn more about permissions](/docs/extension/configuration/manifest#permissions)

## Content Security Policy (CSP) violations

If your extension is rejected due to CSP issues:

1. Check your manifest's `content_security_policy` field
2. Ensure all external resources are properly whitelisted
3. Remove any unsafe inline scripts or eval usage
4. Use more secure alternatives like `browser.scripting.executeScript`


file: ./src/content/docs/mobile/analytics/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure mobile analytics in TurboStarter."
}
        
The `@turbostarter/analytics-mobile` package offers a streamlined and flexible approach to tracking events in your TurboStarter mobile app using various analytics providers. It abstracts the complexities of different analytics services and provides a consistent interface for event tracking.

In this section, we'll guide you through the configuration process for each supported provider.

Note that the configuration is validated against a schema, so you'll see error messages in the console if anything is misconfigured.

## Permissions

First and foremost, to start tracking any metrics from your app (and to do so legally), you need to ask your users for permission. It's [required](https://support.apple.com/en-us/102420), and you're not allowed to collect any data without it.

To make this process as simple as possible, TurboStarter comes with a `useTrackingPermissions` hook that you can use to access the user's consent status. It will handle asking for permission automatically as well as process updates made through the general phone settings.

```tsx
import { useTrackingPermissions } from "@turbostarter/analytics-mobile";

export const MyComponent = () => {
  const granted = useTrackingPermissions();

  if (granted) {
    // Start tracking
  } else {
    // Disable tracking
  }
};
```

Also, for Apple, you must declare the tracking justification via [App Tracking Transparency](https://developer.apple.com/documentation/apptrackingtransparency). It comes pre-configured in TurboStarter via the [Expo Config Plugin](https://docs.expo.dev/versions/latest/config/app/#plugins), where you can provide a custom message to the user:

```tsx title="app.config.ts"
export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  plugins: [
    [
      "expo-tracking-transparency",
      {
        /* 🍎 Describe why you need access to the user's data */
        userTrackingPermission:
          "This identifier will be used to deliver personalized ads to you.",
      },
    ],
  ],
});
```

This way, we ensure that the user is aware of the data we collect and can make an informed decision. If you don't provide this information, your app is likely to be rejected by Apple and/or Google during the [review process](/docs/mobile/publishing/checklist#send-to-review).

## Providers

TurboStarter supports multiple analytics providers, each with its own unique configuration. Below, you'll find detailed information on how to set up and use each supported provider. Choose the one that best suits your needs and follow the instructions in the respective accordion section.

<Accordions>
  <Accordion title="Google Analytics" id="google-analytics">
    To use Google Analytics as your analytics provider, you need to [configure and link a Firebase project to your app](/docs/mobile/installation/firebase).

    After that, you can proceed with the installation of the analytics package:

    ```bash
    pnpm add --filter @turbostarter/analytics-mobile @react-native-firebase/analytics
    ```

    Also, make sure to activate the Google Analytics provider as your analytics provider:

    ```dotenv
    EXPO_PUBLIC_ANALYTICS_PROVIDER="google-analytics"
    ```

    To customize the provider, you can find its definition in `packages/analytics/mobile/src/providers/google-analytics` directory.

    For more information, please refer to the [React Native Firebase documentation](https://rnfirebase.io/analytics/usage).

    ![Google Analytics dashboard](/images/docs/web/analytics/google/dashboard.jpg)
  </Accordion>

  <Accordion title="PostHog" id="posthog">
    To use PostHog as your analytics provider, you need to configure a PostHog instance. You can obtain the [Cloud](https://app.posthog.com/signup) instance by [creating an account](https://app.posthog.com/signup) or [self-host](https://posthog.com/docs/self-host) it.

    Then, create a project and, based on your [project settings](https://app.posthog.com/project/settings), fill the following environment variables in your `.env.local` file in `apps/mobile` directory and your `eas.json` file:

    ```dotenv
    EXPO_PUBLIC_POSTHOG_KEY="your-posthog-api-key"
    EXPO_PUBLIC_POSTHOG_HOST="your-posthog-instance-host"
    ```

    Also, make sure to activate the PostHog provider as your analytics provider:

    ```dotenv
    EXPO_PUBLIC_ANALYTICS_PROVIDER="posthog"
    ```

    To customize the provider, you can find its definition in `packages/analytics/mobile/src/providers/posthog` directory.

    For more information, please refer to the [PostHog documentation](https://posthog.com/docs).

    ![PostHog dashboard](/images/docs/web/analytics/posthog.png)
  </Accordion>
</Accordions>

## Context

To enable tracking events, capturing screen views and other analytics features, you need to wrap your app with the `Provider` component that's implemented by every provider and available through the `@turbostarter/analytics-mobile` package:

```tsx title="providers.tsx"
// [!code word:AnalyticsProvider]
import { memo } from "react";

import { Provider as AnalyticsProvider } from "@turbostarter/analytics-mobile";

interface ProvidersProps {
  readonly children: React.ReactNode;
}

export const Providers = memo<ProvidersProps>(({ children }) => {
  return (
    <OtherProviders>
      <AnalyticsProvider>{children}</AnalyticsProvider>
    </OtherProviders>
  );
});

Providers.displayName = "Providers";
```

By implementing this setup, you ensure that all analytics events are properly tracked from your mobile app code. This configuration allows you to safely utilize the [Analytics API](/docs/mobile/analytics/tracking) within your components, enabling comprehensive event tracking and data collection.


file: ./src/content/docs/mobile/analytics/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with mobile analytics in TurboStarter.",
  "index": true
}
        
When it comes to mobile app analytics, we can distinguish between two types:

* **Store listing analytics**: Used to track the performance of your mobile app's store listing (e.g., how many people have viewed your app in the store or how many have installed it).
* **In-app analytics**: Tracks user actions within your mobile app (e.g., how many users entered a specific screen, how many users clicked on a specific button, etc.).

The `@turbostarter/analytics-mobile` package provides a set of tools to easily implement both types of analytics in your mobile app.

## Store listing analytics

Interpreting your mobile app's store listing metrics can help you evaluate how changes to your app and store listing affect conversion rates. For example, you can identify keywords that users are searching for to optimize your app's store listing.

While each store implements a different set of metrics, there are some common ones you should be aware of:

* **Downloads**: The total number of times your app was downloaded, including both first-time downloads and re-downloads.
* **Sales**: The total number of pre-orders, first-time app downloads, in-app purchases, and their associated sales.
* **Usage**: A variety of user engagement metrics, such as installations, sessions, crashes, and active devices.

To learn more about these or other metrics (e.g., how to create custom reports or KPIs), please refer to the official documentation of the store you're publishing to:

<Cards>
  <Card title="Overview of reporting tools" description="developer.apple.com" href="https://developer.apple.com/help/app-store-connect/measure-app-performance/overview-of-reporting-tools" />

  <Card title="View app statistics" description="support.google.com" href="https://support.google.com/googleplay/android-developer/answer/139628?hl=en&co=GENIE.Platform%3DDesktop&oco=1" />
</Cards>

## In-app analytics

TurboStarter comes with built-in analytics support for multiple providers as well as a unified API for tracking events. This API enables you to easily and consistently track user behavior and app usage across your mobile application.

To learn more about each provider and how to configure them, see their respective sections:

<Cards>
  <Card title="Google Analytics" href="/docs/mobile/analytics/configuration#google-analytics" />

  <Card title="PostHog" href="/docs/mobile/analytics/configuration#posthog" />
</Cards>

All configuration and setup is built-in with a unified API, allowing you to switch between providers without changing your code. You can even introduce your own provider without breaking any tracking-related logic.

In the following sections, we'll cover how to set up each provider and how to track events in your application.


file: ./src/content/docs/mobile/analytics/tracking.mdx
meta: {
  "title": "Tracking events",
  "description": "Learn how to track events in your TurboStarter mobile app."
}
        
The strategy for tracking events, that every provider has to implement, is extremely simple:

```ts
export type AllowedPropertyValues = string | number | boolean;

type TrackFunction = (
  event: string,
  data?: Record<string, AllowedPropertyValues>,
) => void;

export interface AnalyticsProviderStrategy {
  Provider: ({ children }: { children: React.ReactNode }) => React.ReactNode;
  track: TrackFunction;
}
```

<Callout>
  You don't need to worry much about this implementation, as all the providers are already configured for you. However, it's useful to be aware of this structure if you plan to add your own custom provider.
</Callout>

As shown above, each provider must supply two key elements:

1. `Provider` - a component that [wraps your app](/docs/mobile/analytics/configuration#context).
2. `track` - a function responsible for sending event data to the provider.

To track an event, you simply need to invoke the `track` method, passing the event name and an optional data object:

```tsx
import { track } from "@turbostarter/analytics-mobile";

export const MyComponent = () => {
  return (
    <Pressable onPress={() => track("button.click", { country: "US" })}>
      Track event
    </Pressable>
  );
};
```

Congratulations! You've now mastered event tracking in your TurboStarter mobile app. With this knowledge, you're well-equipped to analyze user behaviors and gain valuable insights into your application's usage patterns. Happy analyzing! 📊


file: ./src/content/docs/mobile/api/client.mdx
meta: {
  "title": "Using API client",
  "description": "How to use API client to interact with the API."
}
        
In mobile app code, you can only access the API client from the **client-side.**

When you create a new component or screen and want to fetch some data, you can use the API client to do so.

## Creating a client

We're creating a client-side API client in `apps/mobile/src/lib/api/index.tsx` file. It's a simple wrapper around the [@tanstack/react-query](https://tanstack.com/query/latest/docs/framework/react/overview) that fetches or mutates data from the API.

It also requires wrapping your app in a `ApiProvider` component to provide the API client to the rest of the app:

```tsx title="_layout.tsx"
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <ApiProvider>
      <SafeAreaProvider>
        <Stack>
          ...
          <Stack.Screen name="index" />
          ...
        </Stack>
        <StatusBar barStyle="light-content" />
      </SafeAreaProvider>
    </ApiProvider>
  );
}
```

<Callout type="warn" title="Ensure correct API url">
  Inside the `apps/mobile/src/lib/api/utils.ts` file we're calling a function to get base url of your api, so make sure it's set correctly (especially on production) and your web api endpoint is corresponding with the name there.

  ```tsx title="utils.ts"
  const getBaseUrl = () => {
    /**
     * Gets the IP address of your host-machine. If it cannot automatically find it,
     * you'll have to manually set it. NOTE: Port 3000 should work for most but confirm
     * you don't have anything else running on it, or you'd have to change it.
     *
     * **NOTE**: This is only for development. In production, you'll want to set the
     * baseUrl to your production API URL.
     */
    const debuggerHost = Constants.expoConfig?.hostUri;
    const localhost = debuggerHost?.split(":")[0];

    if (!localhost) {
      console.warn("Failed to get localhost. Pointing to production server...");
      return env.EXPO_PUBLIC_SITE_URL;
    }
    return `http://${localhost}:3000`;
  };
  ```

  As you can see we're relying on your machine IP address for local development (in case you want to open the app from another device) or on the [environment variables](/docs/mobile/configuration/environment-variables) in production to get it, so there shouldn't be any issues with it, but in case, please be aware where to find it 😉
</Callout>

## Queries

Of course, everything comes already configured for you, so you just need to start using `api` in your components/screens.

For example, to fetch the list of posts you can use the `useQuery` hook:

```tsx title="app/(tabs)/tab-one.tsx"
import { api } from "~/lib/api";

export default function TabOneScreen() {
  const { data: posts, isLoading } = useQuery({
    queryKey: ["posts"],
    queryFn: async () => {
      const response = await api.posts.$get();

      if (!response.ok) {
        throw new Error("Failed to fetch posts!");
      }

      return response.json();
    },
  });

  if (isLoading) {
    return <Text>Loading...</Text>;
  }

  /* do something with the data... */
  return (
    <View>
      <Text>{JSON.stringify(posts)}</Text>
    </View>
  );
}
```

It's using the `@tanstack/react-query` [useQuery API](https://tanstack.com/query/latest/docs/framework/react/reference/useQuery), so you shouldn't have any troubles with it.

<Cards>
  <Card title="Hono RPC" description="hono.dev" href="https://hono.dev/docs/guides/rpc" />

  <Card title="useQuery hook | Tanstack Query" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/reference/useQuery" />
</Cards>

## Mutations

If you want to perform a mutation in your mobile code, you can use the `useMutation` hook that comes straight from the integration with [Tanstack Query](https://tanstack.com/query):

```tsx title="form.tsx"
import { api } from "~/lib/api";

export function CreatePost() {
  const queryClient = useQueryClient();
  const { mutate } = useMutation({
    mutationFn: async (post: PostInput) => {
      const response = await api.posts.$post(post);

      if (!response.ok) {
        throw new Error("Failed to create post!");
      },
    },
    onSuccess: () => {
      toast.success("Post created successfully!");
      queryClient.invalidateQueries({ queryKey: ["posts"] });
    },
  });

  return (
    <Form>
      <Button onPress={onSubmit(mutate)}>Submit</Button>
    </Form>
  );
}
```

Here, we're also invalidating the query after the mutation is successful. This is a very important step to make sure that the data is updated in the UI.

<Cards>
  <Card title="useMutation hook" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/reference/useMutation" />

  <Card title="Query invalidation" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation" />
</Cards>

## Handling responses

As you can see in the examples above, the [Hono RPC](https://hono.dev/docs/guides/rpc) client returns a plain `Response` object, which you can use to get the data or handle errors. However, implementing this handling in every query or mutation can be tedious and will introduce unnecessary boilerplate in your codebase.

That's why we've developed the `handle` function that unwraps the response for you, handles errors, and returns the data in a consistent format. You can safely use it with any procedure from the API client:

<Tabs items={["Queries", "Mutations"]}>
  <Tab value="Queries">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api";

    export default function TabOneScreen() {
      const { data: posts, isLoading } = useQuery({
        queryKey: ["posts"],
        queryFn: handle(api.posts.$get),
      });

      if (isLoading) {
        return <Text>Loading...</Text>;
      }

      /* do something with the data... */
      return (
        <View>
          <Text>{JSON.stringify(posts)}</Text>
        </View>
      );
    }
    ```
  </Tab>

  <Tab value="Mutations">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/client";

    export default function CreatePost() {
      const queryClient = useQueryClient();
      const { mutate } = useMutation({
        mutationFn: handle(api.posts.$post),
        onSuccess: () => {
          toast.success("Post created successfully!");
          queryClient.invalidateQueries({ queryKey: ["posts"] });
        },
      });

      return (
        <Form>
          <Button onPress={onSubmit(mutate)}>Submit</Button>
        </Form>
      );
    }
    ```
  </Tab>
</Tabs>

With this approach, you can focus on the business logic instead of repeatedly writing code to handle API responses in your browser extension components, making your extension's codebase more readable and maintainable.

The same error handling and response unwrapping benefits apply whether you're building web, mobile, or extension interfaces - allowing you to keep your data fetching logic consistent across all platforms.


file: ./src/content/docs/mobile/api/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with the API.",
  "index": true
}
        
<Callout type="error" title="API deployment required">
  To enable communication between your Expo app and the server in a production environment, the web application with Hono API must be deployed first.

  <Cards>
    <Card title="API" description="Learn more about the API." href="/docs/web/api/overview" />

    <Card title="Web deployment" description="Deploy your web application to production." href="/docs/web/deployment/checklist" />
  </Cards>
</Callout>

TurboStarter is designed to be a scalable and production-ready full-stack starter kit. One of its core features is a dedicated and extensible API layer. To enable this in a type-safe manner, we chose [Hono](https://hono.dev) as the API server and client library.

<Callout title="Why Hono?">
  Hono is a small, simple, and ultrafast web framework that gives you a way to
  define your API endpoints with full type safety. It provides built-in
  middleware for common needs like validation, caching, and CORS. It also
  includes an [RPC client](https://hono.dev/docs/guides/rpc) for making
  type-safe function calls from the frontend. Being edge-first, it's optimized
  for serverless environments and offers excellent performance.
</Callout>

All API endpoints and their resolvers are defined in the `packages/api/` package. Here you will find a `modules` folder that contains the different feature modules of the API. Each module has its own folder and exports all its resolvers.

For each module, we create a separate Hono route in the `packages/api/index.ts` file and aggregate all sub-routers into one main router.

The API is then exposed as a route handler that will be provided as a Next.js API route:

```ts title="apps/web/src/app/api/[...route]/route.ts"
import { handle } from "hono/vercel";

import { appRouter } from "@turbostarter/api";

const handler = handle(appRouter);
export { handler as GET, handler as POST };
```

Learn more about how to use the API in your mobile app in the following sections:


file: ./src/content/docs/mobile/auth/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Configure authentication for your application."
}
        
TurboStarter supports three different authentication methods:

* **Password** - the traditional email/password method
* **Magic Link** - passwordless email link authentication
* **OAuth** - OAuth providers, Google and Github are set up by default

All authentication methods are enabled by default, but you can easily customize them to your needs. You can enable or disable any method, and configure them according to your requirements.

<Callout>
  Remember that you can mix and match these methods or add new ones - for
  example, you can have both password and magic link authentication enabled at
  the same time, giving your users more flexibility in how they authenticate.
</Callout>

Authentication configuration can be customized through a simple configuration file. The following sections explain the available options and how to configure each authentication method based on your requirements.

## API

To enable new authentication method or add some plugin, you'd need to update the API configuration. Please refer to [web authentication configuration](/docs/web/auth/configuration) for more information as it's not strictly related with mobile app configuration.

<Callout title="Remember to add your app scheme as trusted origin">
  For mobile apps, we need to define an [authentication trusted origin](https://www.better-auth.com/docs/reference/security#trusted-origins) using a mobile app scheme instead.

  App schemes (like `turbostarter://`) are used for [deep linking](https://docs.expo.dev/guides/linking/) users to specific screens in your app after authentication.

  To find your app scheme, take a look at `apps/mobile/app.config.ts` file and then add it to your auth server configuration:

  ```tsx title="server.ts"
  export const auth = betterAuth({
    ...

    trustedOrigins: ["turbostarter://**"],

    ...
  });
  ```

  Adding your app scheme to the trusted origins list is crucial for security - it prevents CSRF attacks and blocks malicious open redirects by ensuring only requests from approved origins (your app) are allowed through.

  [Read more about auth security in Better Auth's documentation.](https://www.better-auth.com/docs/reference/security)
</Callout>

## UI

We have separate configuration that determines what is displayed to your users in the **UI**. It's set at `apps/mobile/config/auth.ts`.

The recommendation is to **not update this directly** - instead, please define the environment variables and override the default behavior.

```ts title="apps/mobile/config/auth.ts"
import { SOCIAL_PROVIDER, authConfigSchema } from "@turbostarter/auth";

import { env } from "~/lib/env";

import type { AuthConfig } from "@turbostarter/auth";

export const authConfig = authConfigSchema.parse({
  providers: {
    password: env.EXPO_PUBLIC_AUTH_PASSWORD,
    magicLink: env.EXPO_PUBLIC_AUTH_MAGIC_LINK,
    oAuth: [SOCIAL_PROVIDER.GOOGLE, SOCIAL_PROVIDER.GITHUB],
  },
}) satisfies AuthConfig;
```

The configuration is also validated using the Zod schema, so if something is off, you'll see the errors.

For example, if you want to switch from password to magic link, you'd set the following environment variables:

```dotenv title=".env.local"
EXPO_PUBLIC_AUTH_PASSWORD=false
EXPO_PUBLIC_AUTH_MAGIC_LINK=true
```

To display third-party providers in the UI, you need to set the `oAuth` array to include the provider you want to display. The default is Google and Github.

```tsx title="apps/web/config/auth.ts"
providers: {
    ...
    oAuth: [SOCIAL_PROVIDER.GOOGLE, SOCIAL_PROVIDER.GITHUB],
    ...
},
```

## Third party providers

To enable third-party authentication providers, you'll need to:

1. Set up an OAuth application in the provider's developer console (like Google Cloud Console, Github Developer Settings or any other provider you want to use)
2. Configure the corresponding environment variables in your TurboStarter **API (web) application**

Each OAuth provider requires its own set of credentials and environment variables. Please refer to the [Better Auth documentation](https://better-auth.com/docs/concepts/oauth) for detailed setup instructions for each supported provider.

<Callout title="Environment variables">
  Make sure to set both development and production environment variables
  appropriately. Your OAuth provider may require different callback URLs for
  each environment.
</Callout>


file: ./src/content/docs/mobile/auth/flow.mdx
meta: {
  "title": "User flow",
  "description": "Discover the authentication flow in Turbostarter."
}
        
TurboStarter ships with a fully functional authentication system. Most of the screens and components are preconfigured and easily customizable to your needs.

Here you will find a quick walkthrough of the authentication flow.

## Sign up

The sign-up screen is where users can create an account. They need to provide their email address and password.

![Sign up](/images/docs/mobile/auth/sign-up.png)

Once successful, users are asked to confirm their email address. This is enabled by default - and due to security reasons, it's not possible to disable it.

<Callout type="warn" title="Sending authentication emails">
  Make sure to configure the [email provider](/docs/web/emails/configuration) together with the [auth hooks](/docs/web/emails/sending#authentication-emails) to be able to send emails from your app.
</Callout>

![Confirm email](/images/docs/mobile/auth/confirm-email.png)

## Sign in

The sign-in screen is where users can log in to their account. They need to provide their email address and password, use magic link (if enabled) or third-party providers.

![Sign in](/images/docs/mobile/auth/sign-in.png)

## Sign out

The sign out button is located in the user menu.

![Sign out](/images/docs/mobile/auth/sign-out.png)

## Forgot password

The forgot password screen is where users can reset their password. They need to provide their email address and follow the instructions in the email.

It comes together with the reset password screen, where users land from a forgot email. There they can reset their password by providing new password and confirming it.

![Forgot password](/images/docs/mobile/auth/forgot-password.png)


file: ./src/content/docs/mobile/auth/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with authentication.",
  "index": true
}
        
TurboStarter uses [Better Auth](https://better-auth.com) to handle authentication. It's a secure, production-ready authentication solution that integrates seamlessly with many frameworks and provides enterprise-grade security out of the box.

<Callout title="Why Better Auth?">
  One of the core principles of TurboStarter is to do things **as simple as possible**, and to make everything **as performant as possible**.

  Better Auth provides an excellent developer experience with minimal configuration required, while maintaining enterprise-grade security standards. Its framework-agnostic approach and focus on performance makes it the perfect choice for TurboStarter.
</Callout>

![Better Auth](/images/docs/better-auth.png)

You can read more about Better Auth in the [official documentation](https://better-auth.com/docs).

TurboStarter supports multiple authentication methods:

* **Password** - the traditional email/password method
* **Magic Link** - magic links with **deep linking**
* **OAuth** - OAuth social providers (Google and Github preconfigured)
* **Native Apple authentication** - Apple sign-in for iOS (coming soon)
* **Native Google authentication** - Google sign-in for Android (coming soon)

As well as common applications flows, with ready-to-use views and components:

* **Sign in** - sign in with email/password or OAuth providers
* **Sign up** - sign up with email/password or OAuth providers
* **Sign out** - sign out
* **Password recovery** - forgot and reset password
* **Email verification** - verify email

You can construct your auth flow like LEGO bricks - plug in needed parts and customize them to your needs.


file: ./src/content/docs/mobile/configuration/app.mdx
meta: {
  "title": "App configuration",
  "description": "Learn how to setup the overall settings of your app."
}
        
When configuring your app, you'll need to define settings in different places depending on which provider will use them (e.g., Expo, EAS).

## App configuration

Let's start with the core settings for your app. These settings are **crucial** as they're used by Expo and EAS to build your app, determine its store presence, prepare updates, and more.

This configuration includes essential details like the official name, description, scheme, store IDs, splash screen configuration, and more.

You'll define these settings in `apps/mobile/app.config.ts`. Make sure to follow the [Expo config schema](https://docs.expo.dev/versions/latest/config/app/) when setting this up.

Here is an example of what the config file looks like:

```ts title="apps/mobile/app.config.ts"
import { ExpoConfig } from "expo/config";

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  name: "TurboStarter",
  slug: "turbostarter",
  scheme: "turbostarter",
  version: "0.1.0",
  orientation: "portrait",
  icon: "./assets/images/icon.png",
  userInterfaceStyle: "automatic",
  assetBundlePatterns: ["**/*"],
  sdkVersion: "51.0.0",
  platforms: ["ios", "android"],
  updates: {
    fallbackToCacheTimeout: 0,
  },
  newArchEnabled: true,
  ios: {
    bundleIdentifier: "your.bundle.identifier",
    supportsTablet: false,
  },
  android: {
    package: "your.bundle.identifier",
    adaptiveIcon: {
      monochromeImage: "./public/images/icon/android/monochrome.png",
      foregroundImage: "./public/images/icon/android/adaptive.png",
      backgroundColor: "#0D121C",
    },
  },
  extra: {
    eas: {
      projectId: "your-project-id",
    },
  },
  experiments: {
    tsconfigPaths: true,
    typedRoutes: true,
  },
  plugins: ["expo-router", ["expo-splash-screen", SPLASH]],
});
```

Make sure to replace the values with your own and take your time to set everything correctly.

<Card title="Configure with app config" description="docs.expo.dev" href="https://docs.expo.dev/workflow/configuration/" />

### Internal configuration

The same as for the [web app](/docs/web/configuration/app), and [extension](/docs/extension/configuration/app), we're defining the internal app config, which stores some overall variables for your application (that can't be read from Expo config).

The recommendation is to **not update this directly** - instead, please define the environment variables and override the default behavior. The configuration is strongly typed so you can use it safely accross your codebase - it'll be validated at build time.

```ts title="apps/mobile/src/config/app.ts"
import { env } from "~/lib/env";

export const appConfig = {
  locale: env.EXPO_PUBLIC_DEFAULT_LOCALE,
  theme: {
    mode: env.EXPO_PUBLIC_THEME_MODE,
    color: env.EXPO_PUBLIC_THEME_COLOR,
  },
} as const;
```

For example, to set the mobile app default theme color, you'd update the following variable:

```dotenv title=".env.local"
EXPO_PUBLIC_THEME_COLOR="yellow"
```

<Callout type="warn" title="Do NOT use process.env!">
  Do NOT use `process.env` to get the values of the variables. Variables
  accessed this way are not validated at build time, and thus the wrong variable
  can be used in production.
</Callout>

## EAS configuration

To properly build and publish your app, you need to define settings for the EAS build service.

This is done in `apps/mobile/eas.json` and it must follow the [EAS config scheme](https://docs.expo.dev/eas/json/).

Here is an example of what the config file looks like:

```json title="apps/mobile/eas.json"
{
  "cli": {
    "version": ">= 4.1.2"
  },
  "build": {
    "base": {
      "node": "20.15.0",
      "pnpm": "9.6.0",
      "ios": {
        "resourceClass": "m-medium"
      },
      "env": {
        "EXPO_PUBLIC_DEFAULT_LOCALE": "en",
        "EXPO_PUBLIC_AUTH_PASSWORD": "true",
        "EXPO_PUBLIC_AUTH_MAGIC_LINK": "false",
        "EXPO_PUBLIC_THEME_MODE": "system",
        "EXPO_PUBLIC_THEME_COLOR": "orange"
      }
    },
    ...
    "preview": {
      "extends": "base",
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      },
      "env": {
        "APP_ENV": "test",
        "EXPO_PUBLIC_SITE_URL": "",
      }
    },
    "production": {
      "extends": "base",
      "env": {
        "APP_ENV": "production",
        "EXPO_PUBLIC_SITE_URL": "",
      }
    }
    ...
  },
}
```

Make sure to fill all the environment variables with the correct values for your project and correct environment, otherwise your app won't build and you won't be able to publish it.

<Card title="Configure EAS Build with eas.json" description="docs.expo.dev" href="https://docs.expo.dev/build/eas-json/" />


file: ./src/content/docs/mobile/configuration/environment-variables.mdx
meta: {
  "title": "Environment variables",
  "description": "Learn how to configure environment variables."
}
        
Environment variables are defined in the `.env` file in the root of the repository and in the root of the `apps/mobile` package.

* **Shared environment variables**: Defined in the **root** `.env` file. These are shared between environments (e.g., development, staging, production) and apps (e.g., web, mobile).
* **Environment-specific variables**: Defined in `.env.development` and `.env.production` files. These are specific to the development and production environments.
* **App-specific variables**: Defined in the app-specific directory (e.g., `apps/web`). These are specific to the app and are not shared between apps.
* **Build environment variables**: Not stored in the `.env` file. Instead, they are stored in `eas.json` file used to build app on [Expo Application Services](https://expo.dev/eas).
* **Secret keys**: They're not stored on mobile side, instead [they're defined on the web side.](/docs/web/configuration/environment-variables#secret-keys)

## Shared variables

Here you can add all the environment variables that are shared across all the apps.

To override these variables in a specific environment, please add them to the specific environment file (e.g. `.env.development`, `.env.production`).

```dotenv title=".env.local"
# Shared environment variables

# The database URL is used to connect to your database.
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres"

# The name of the product. This is used in various places across the apps.
PRODUCT_NAME="TurboStarter"

# The url of the web app. Used mostly to link between apps.
URL="http://localhost:3000"

...
```

## App-specific variables

Here you can add all the environment variables that are specific to the app (e.g. `apps/mobile`).

You can also override the shared variables defined in the root `.env` file.

```dotenv title="apps/mobile/.env.local"
# App-specific environment variables

# Env variables extracted from shared to be exposed to the client in Expo app
EXPO_PUBLIC_SITE_URL="${URL}"
EXPO_PUBLIC_DEFAULT_LOCALE="${DEFAULT_LOCALE}"

# Theme mode and color
EXPO_PUBLIC_THEME_MODE="system"
EXPO_PUBLIC_THEME_COLOR="orange"

# Use this variable to enable or disable password-based authentication. If you set this to true, users will be able to sign up and sign in using their email and password. If you set this to false, the form won't be shown.
EXPO_PUBLIC_AUTH_PASSWORD="true"

...
```

<Callout title="EXPO_PUBLIC_ prefix">
  To make environment variables available in the Expo app code, you need to prefix them with `EXPO_PUBLIC_`. They will be injected to the code during the build process.

  Only environment variables prefixed with `EXPO_PUBLIC_` will be injected.

  [Read more about Expo environment variables.](https://docs.expo.dev/guides/environment-variables/)
</Callout>

## Build environment variables

To allow your app to build properly on [EAS](https://expo.dev/eas) you need to define your environment variables in `eas.json` file under corresponding profile (e.g. `preview` or `production`).

Here is an example of correctly filled `eas.json` for one of the profiles:

```json title="apps/mobile/eas.json"
{
  "build": {
    "base": {
      "env": {
        "EXPO_PUBLIC_DEFAULT_LOCALE": "en",
        "EXPO_PUBLIC_AUTH_PASSWORD": "true",
        "EXPO_PUBLIC_AUTH_MAGIC_LINK": "false",
        "EXPO_PUBLIC_THEME_MODE": "system",
        "EXPO_PUBLIC_THEME_COLOR": "orange"
      }
    },
    "production": {
      "extends": "base",
      "autoIncrement": true,
      "env": {
        "APP_ENV": "production",
        "EXPO_PUBLIC_SITE_URL": "https://turbostarter.dev"
      }
    }
  }
}
```

Then, when you trigger `production` build correct environment variables will be injected to your mobile app code ensuring that everything is working correctly.

## Secret keys

Secret keys and sensitive information are to be **never** stored on the mobile app code.

<Callout title="What does this mean?">
  It means that you will need to add the secret keys to the **web app, where the API is deployed.**

  The mobile app should only communicate with the backend API, which is typically part of the web app. The web app is responsible for handling sensitive operations and storing secret keys securely.

  [See web documentation for more details.](/docs/web/configuration/environment-variables#secret-keys)

  This is not a TurboStarter-specific requirement, but a best practice for security for any
  application. Ultimately, it's your choice.
</Callout>


file: ./src/content/docs/mobile/configuration/paths.mdx
meta: {
  "title": "Paths configuration",
  "description": "Learn how to configure the paths of your app."
}
        
The paths configuration is set at `apps/mobile/config/paths.ts`. This configuration stores all the paths that you'll be using in your application. It is a convenient way to store them in a central place rather than scatter them in the codebase using magic strings.

It is **unlikely you'll need to change** this unless you're heavily editing the codebase.

```ts title="apps/mobile/config/paths.ts"
const pathsConfig = {
  index: "/",
  tabs: {
    auth: {
      login: `${AUTH_PREFIX}/login`,
      register: `${AUTH_PREFIX}/register`,
      forgotPassword: `${AUTH_PREFIX}/password/forgot`,
      updatePassword: `${AUTH_PREFIX}/password/update`,
      error: `${AUTH_PREFIX}/error`,
    },
    billing: `/billing`,
    ai: `/ai`,
    settings: `/settings`,
  },
} as const;
```

<Callout title="Fully type-safe">
  By declaring the paths as constants, we can use them safely throughout the
  codebase. There is no risk of misspelling or using magic strings.
</Callout>


file: ./src/content/docs/mobile/customization/add-app.mdx
meta: {
  "title": "Adding apps",
  "description": "Learn how to add apps to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new app to your TurboStarter project within your monorepo and want to keep pulling updates from the TurboStarter repository.
</Callout>

In some ways - creating a new repository may be the easiest way to manage your application. However, if you want to keep your application within the monorepo and pull updates from the TurboStarter repository, you can follow these instructions.

To pull updates into a separate application outside of `mobile` - we can use [git subtree](https://www.atlassian.com/git/tutorials/git-subtree).

Basically, we will create a subtree at `apps/mobile` and create a new remote branch for the subtree. When we create a new application, we will pull the subtree into the new application. This allows us to keep it in sync with the `apps/mobile` folder.

To add a new app to your TurboStarter project, you need to follow these steps:

<Steps>
  <Step>
    ## Create a subtree

    First, we need to create a subtree for the `apps/mobile` folder. We will create a branch named `mobile-branch` and create a subtree for the `apps/mobile` folder.

    ```bash
    git subtree split --prefix=apps/mobile --branch mobile-branch
    ```
  </Step>

  <Step>
    ## Create a new app

    Now, we can create a new application in the `apps` folder.

    Let's say we want to create a new app `ai-chat` at `apps/ai-chat` with the same structure as the `apps/mobile` folder (which acts as the template for all new apps).

    ```bash
    git subtree add --prefix=apps/ai-chat origin mobile-branch --squash
    ```

    You should now be able to see the `apps/ai-chat` folder with the contents of the `apps/mobile` folder.
  </Step>

  <Step>
    ## Update the app

    When you want to update the new application, follow these steps:

    ### Pull the latest updates from the TurboStarter repository

    The command below will update all the changes from the TurboStarter repository:

    ```bash
    git pull upstream main
    ```

    ### Push the `mobile-branch` updates

    After you have pulled the updates from the TurboStarter repository, you can split the branch again and push the updates to the mobile-branch:

    ```bash
    git subtree split --prefix=apps/mobile --branch mobile-branch
    ```

    Now, you can push the updates to the `mobile-branch`:

    ```bash
    git push origin mobile-branch
    ```

    ### Pull the updates to the new application

    Now, you can pull the updates to the new application:

    ```bash
    git subtree pull --prefix=apps/ai-chat origin mobile-branch --squash
    ```
  </Step>
</Steps>

That's it! You now have a new application in the monorepo 🎉


file: ./src/content/docs/mobile/customization/add-package.mdx
meta: {
  "title": "Adding packages",
  "description": "Learn how to add packages to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new package to your TurboStarter application instead of adding a folder to your application in `apps/web` or modify existing packages under `packages`. You don't need to do this to add a new screen or component to your application.
</Callout>

To add a new package to your TurboStarter application, you need to follow these steps:

<Steps>
  <Step>
    ## Generate a new package

    First, enter the command below to create a new package in your TurboStarter application:

    ```bash
    turbo gen
    ```

    Turborepo will ask you to enter the name of the package you want to create. Enter the name of the package you want to create and press enter.

    If you don't want to add dependencies to your package, you can skip this step by pressing enter.

    The command will have generated a new package under packages named `@turbostarter/<package-name>`. If you named it `example`, the package will be named `@turbostarter/example`.
  </Step>

  <Step>
    ## Export a module from your package

    By default, the package exports a single module using the `index.ts` file. You can add more exports by creating new files in the package directory and exporting them from the `index.ts` file or creating export files in the package directory and adding them to the `exports` field in the `package.json` file.

    ### From `index.ts` file

    The easiest way to export a module from a package is to create a new file in the package directory and export it from the `index.ts` file.

    ```ts title="packages/example/src/module.ts"
    export function example() {
      return "example";
    }
    ```

    Then, export the module from the `index.ts` file.

    ```ts title="packages/example/src/index.ts"
    export * from "./module";
    ```

    ### From `exports` field in `package.json`

    **This can be very useful for tree-shaking.** Assuming you have a file named `module.ts` in the package directory, you can export it by adding it to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./module": "./src/module.ts"
      }
    }
    ```

    **When to do this?**

    1. when exporting two modules that don't share dependencies to ensure better tree-shaking. For example, if your exports contains both client and server modules.
    2. for better organization of your package

    For example, create two exports `client` and `server` in the package directory and add them to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./client": "./src/client.ts",
        "./server": "./src/server.ts"
      }
    }
    ```

    1. The `client` module can be imported using `import { client } from '@turbostarter/example/client'`
    2. The `server` module can be imported using `import { server } from '@turbostarter/example/server'`
  </Step>

  <Step>
    ## Use the package in your application

    You can now use the package in your application by importing it using the package name:

    ```ts title="apps/mobile/src/app/index.tsx"
    import { example } from "@turbostarter/example";

    console.log(example());
    ```
  </Step>
</Steps>

Et voilà! You have successfully added a new package to your TurboStarter application. 🎉


file: ./src/content/docs/mobile/customization/components.mdx
meta: {
  "title": "Components",
  "description": "Manage and customize your app components."
}
        
For the components part, we're using [react-native-reusables](https://rnr-docs.vercel.app/getting-started/introduction/) for atomic, accessible and highly customizable components.

> It's like shadcn/ui, but for mobile apps.

<Callout type="info" title="Why react-native-reusables?">
  react-native-reusables is a powerful tool that allows you to generate
  pre-designed components with a single command. It's built with Nativewind
  (like Tailwind CSS for mobile) and accessiblity in mind, it's also highly
  customizable.
</Callout>

TurboStarter defines two packages that are responsible for the UI part of your app:

* `@turbostarter/ui` - shared styles, [themes](/docs/mobile/customization/styling#themes) and assets (e.g. icons)
* `@turbostarter/ui-mobile` - pre-built UI mobile components, ready to use in your app

## Adding a new component

There are basically two ways to add a new component:

<Tabs items={["Using the CLI", "Copy-pasting"]}>
  <Tab value="Using the CLI">
    TurboStarter is fully compatible with [react-native-reusables CLI](https://www.npmjs.com/package/@react-native-reusables/cli), so you can generate new components with single command.

    Run the following command from the **root** of your project:

    ```bash
    pnpm --filter @turbostarter/ui-mobile ui:add
    ```

    This will launch an interactive command-line interface to guide you through the process of adding a new component where you can pick which component you want to add.

    ```bash
    Which components would you like to add? > Space to select. A to toggle all.
    Enter to submit.

    ◯  accordion
    ◯  alert
    ◯  alert-dialog
    ◯  aspect-ratio
    ◯  avatar
    ◯  badge
    ◯  button
    ◯  calendar
    ◯  card
    ◯  checkbox
    ```

    Newly created components will appear in the `packages/ui/mobile/src` directory.
  </Tab>

  <Tab value="Copy-pasting">
    You can always copy-paste a component from the [react-native-reusables](https://rnr-docs.vercel.app/getting-started/introduction/) website and modify it to your needs.

    This is possible, because the components are headless and don't need (in most cases) any additional dependencies.

    Copy code from the website, create a new file in the `packages/ui/mobile/src` directory and paste the code into the file.
  </Tab>
</Tabs>

<Callout title="Keep it atomic" type="warn">
  Keep in mind that you should always try to keep shared components as atomic as possible. This will make it easier to reuse them and to build specific views by composition.

  E.g. include components like `Button`, `Input`, `Card`, `Dialog` in shared package, but keep specific components like `LoginForm` in your app directory.
</Callout>

## Using components

Each component is a standalone entity which has a separate export from the package. It helps to keep things modular, avoid unnecessary dependencies and make tree-shaking possible.

To import a component from the UI package, use the following syntax:

```tsx title="apps/mobile/src/components/my-component.tsx"
// [!code word:card]
import {
  Card,
  CardContent,
  CardHeader,
  CardFooter,
  CardTitle,
  CardDescription,
} from "@turbostarter/ui-mobile/card";
```

Then you can use it to build a component specific to your app:

```tsx title="apps/mobile/src/components/my-component.tsx"
export function MyComponent() {
  return (
    <Card>
      <CardHeader>
        <CardTitle>My Component</CardTitle>
      </CardHeader>
      <CardContent>
        <Text>My Component Content</Text>
      </CardContent>
      <CardFooter>
        <Button>Click me</Button>
      </CardFooter>
    </Card>
  );
}
```

<Callout title="Think of it the same as for the web">
  Most of the components are the same as for the [web app](/docs/web/customization/components).

  It means that you can basically migrate existing web components to the mobile app with just an import change!
</Callout>

<Card href="https://rnr-docs.vercel.app/getting-started/introduction/" title="react-native-reusables" description="rnr-docs.vercel.app" />


file: ./src/content/docs/mobile/customization/styling.mdx
meta: {
  "title": "Styling",
  "description": "Get started with styling your app."
}
        
To build the user web interface TurboStarter comes with [Nativewind](https://www.nativewind.dev/) pre-configured.

<Callout title="Why Nativewind?" type="info">
  Nativewind is basically a Tailwind CSS for mobile apps. It gives you a way to style your app with Tailwind CSS utilities and classes.
</Callout>

## Tailwind configuration

In the `tooling/tailwind/config` directory you will find shared Tailwind CSS configuration files. To change some global styles you can edit the files in this folder.

Here is an example of a shared Tailwind configuration file:

```ts title="tooling/tailwind/config/base.ts"
import type { Config } from "tailwindcss";

export default {
  darkMode: "class",
  content: ["src/**/*.{ts,tsx}"],
  theme: {
    extend: {
      colors: {
        ...
        primary: {
          DEFAULT: "hsl(var(--color-primary))",
          foreground: "hsl(var(--color-primary-foreground))",
        },
        secondary: {
          DEFAULT: "hsl(var(--color-secondary))",
          foreground: "hsl(var(--color-secondary-foreground))",
        },
        success: {
          DEFAULT: "hsl(var(--color-success))",
          foreground: "hsl(var(--color-success-foreground))",
        },
        ...
      },
    },
  },
  plugins: [animate, containerQueries, typography],
} satisfies Config;
```

For the colors part, we bet stricly on [CSS Variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) in [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) format to allow for easy theme management without a need for any JavaScript.

Also, each app has its own `tailwind.config.ts` file which extends the shared config and allows you to override the global styles.

Here is an example of an app's `tailwind.config.ts` file:

```ts title="apps/mobile/tailwind.config.ts"
import type { Config } from "tailwindcss";
import nativewind from "nativewind/preset";
import { hairlineWidth } from "nativewind/theme";

import baseConfig from "@turbostarter/tailwind-config/mobile";

export default {
  // We need to append the path to the UI package to the content array so that
  // those classes are included correctly.
  content: [
    ...baseConfig.content,
    "../../packages/ui/{shared,mobile}/src/**/*.{ts,tsx}",
  ],
  presets: [baseConfig, nativewind],
  theme: {
    extend: {
      fontFamily: {
        sans: ["DMSans_400Regular"],
        mono: ["DMMono_400Regular"],
      },
      borderWidth: {
        hairline: hairlineWidth(),
      },
    },
  },
} satisfies Config;
```

That way we can have a separation of concerns and a clear structure for the Tailwind CSS configuration.

## Themes

TurboStarter comes with **9+** predefined themes which you can use to quickly change the look and feel of your app.

They're defined in `packages/ui/shared/src/styles/themes` directory. Each theme is a set of variables that can be overridden:

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

Each variable is stored as a [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) array, which is then converted to a CSS variable. That way we can ensure full type-safety and reuse themes across parts of our apps (e.g. use the same theme in emails).

Feel free to add your own themes or override the existing ones to match your brand's identity.

To apply a theme to your app, we're declaring a theme provider, which is a wrapper around the app that passes the correct variables to the styles that will be used in the components and screens. It's located at `providers/theme.tsx`:

```tsx title="apps/mobile/src/providers/theme.tsx"
export default function ThemeProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <NavigationThemeProvider value={isDark ? DarkTheme : DefaultTheme}>
      <View style={colors[config.color][resolvedTheme]} className="flex-1">
        {children}
      </View>
    </NavigationThemeProvider>
  );
}
```

## Dark mode

TurboStarter comes with a built-in dark mode support.

Each theme has a corresponding dark mode variables which are used to change the theme to its dark mode counterpart.

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {},
  dark: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

Nativewind takes care of adding the `dark` class to the root of our app as well as reading the user's preferences via `useColorScheme` hook. That way you can put full focus on the features and just change the colors if you need to customize the theme.

Also, you can define the default theme mode and color in [app configuration](/docs/mobile/configuration/app).

<Cards>
  <Card title="Nativewind" description="nativewind.dev" href="https://nativewind.dev/" />

  <Card title="Dark mode | Nativewind" description="nativewind.dev" href="https://www.nativewind.dev/v4/core-concepts/dark-mode" />

  <Card title="Themes | Nativewind" description="nativewind.dev" href="https://www.nativewind.dev/v4/guides/themes" />
</Cards>


file: ./src/content/docs/mobile/installation/clone.mdx
meta: {
  "title": "Cloning repository",
  "description": "Get the code to your local machine and start developing your app.",
  "mirror": "../../web/installation/clone.mdx"
}
        


file: ./src/content/docs/mobile/installation/commands.mdx
meta: {
  "title": "Common commands",
  "description": "Learn about common commands you need to know to work with the mobile project.",
  "mirror": "../../web/installation/commands.mdx"
}
        


file: ./src/content/docs/mobile/installation/conventions.mdx
meta: {
  "title": "Conventions",
  "description": "Some standard conventions used across TurboStarter codebase.",
  "mirror": "../../web/installation/conventions.mdx"
}
        


file: ./src/content/docs/mobile/installation/dependencies.mdx
meta: {
  "title": "Managing dependencies",
  "description": "Learn how to manage dependencies in your project.",
  "mirror": "../../web/installation/dependencies.mdx"
}
        


file: ./src/content/docs/mobile/installation/development.mdx
meta: {
  "title": "Development",
  "description": "Get started with the code and develop your mobile SaaS."
}
        
## Prerequisites

To get started with TurboStarter, ensure you have the following installed and set up:

* [Node.js](https://nodejs.org/en) (20.x or higher)
* [Docker](https://www.docker.com) (only if you want to use local database)
* [pnpm](https://pnpm.io)
* [Firebase](https://firebase.google.com) project (optional for some features - check [Firebase project](/docs/mobile/installation/firebase) section for more details)

## Project development

<Steps>
  <Step>
    ### Set up environment

    We won't copy the official docs, as there is quite a bit of setup you need to make to get started with iOS and Android development and it also depends what approach you want to take.

    [Check this official setup guide to get started](https://docs.expo.dev/get-started/set-up-your-environment/). After you're done with the setup, go back to this guide and continue with the next step.

    You can pick if you want to develop the app for iOS or Android by using the real device or the simulator.

    <Callout title="Recommendation">
      We recommend using the simulators and [development builds](https://docs.expo.dev/develop/development-builds/create-a-build/) for development, as it is more real and reliable approach. It also won't limit you in terms of native dependencies (required for e.g. [analytics](/docs/mobile/analytics/overview)).

      Of course, you can start with the simplest approach (using [Expo Go](https://expo.dev/go)) and when you iterate further, switch to different approach.
    </Callout>
  </Step>

  <Step>
    ### Install dependencies

    Install the project dependencies by running the following command:

    ```bash
    pnpm i
    ```

    <Callout title="Why pnpm?">
      It is a fast, disk space efficient package manager that uses hard links and symlinks to save one version of a module only ever once on a disk. It also has a great [monorepo support](https://pnpm.io/workspaces). Of course, you can change it to use [Bun](https://bunpkg.com), [yarn](https://yarnpkg.com) or [npm](https://www.npmjs.com) with minimal effort.
    </Callout>
  </Step>

  <Step>
    ### Setup environment variables

    Create a `.env.local` files from `.env.example` files and fill in the required environment variables.

    Check [Environment variables](/docs/web/configuration/environment-variables) for more details on setting up environment variables.
  </Step>

  <Step>
    ### Start database

    If you want to use local database (**recommended for development purposes**), ensure Docker is running, then setup your database with:

    ```bash
    pnpm db:setup
    ```

    This command initiates the PostgreSQL container and runs migrations, ensuring your database is up to date and ready to use.
  </Step>

  <Step>
    ### Start development server

    To start the application development server, run:

    ```bash
    pnpm dev
    ```

    Your development server should now be running at `http://localhost:8081`.

    ![Metro server](/images/docs/mobile/metro-server.png)

    Scan the QR code with your mobile device to start the app or press the appropriate key on your keyboard to run it on simulator. In case of any issues check the [Troubleshooting](https://docs.expo.dev/troubleshooting/overview/) section.
  </Step>

  <Step>
    ### Publish to stores

    When you're ready to publish the project to the stores, follow [guidelines](/docs/mobile/marketing) and [checklist](/docs/mobile/publishing/checklist) to ensure everything is set up correctly.
  </Step>
</Steps>


file: ./src/content/docs/mobile/installation/editor-setup.mdx
meta: {
  "title": "Editor setup",
  "description": "Learn how to set up your editor for the fastest development experience.",
  "mirror": "../../web/installation/editor-setup.mdx"
}
        


file: ./src/content/docs/mobile/installation/firebase.mdx
meta: {
  "title": "Firebase project",
  "description": "Learn how to set up a Firebase project for your TurboStarter mobile app."
}
        
For some features of your mobile app, you will need to set up a Firebase project. It's a requirement enforced by how these features are implemented under the hood and we cannot change it.

You would need a Firebase project to use the following features:

* [Analytics](/docs/mobile/analytics/overview) with [Google Analytics](/docs/mobile/analytics/configuration#google-analytics) provider

Here, we'll go through the steps to set up a Firebase project and link it to your mobile app.

<Callout title="Development build required" type="warn">
  In development environment, the integration with Firebase is possible only when using a [development build](https://docs.expo.dev/workflow/overview/#development-builds). It means that **it won't work in the [Expo Go](https://expo.dev/go) app**.
</Callout>

<Steps>
  <Step>
    ## Create a Firebase project

    First things first, you need to create a Firebase project. You can do this by going to the [Firebase console](https://console.firebase.google.com/) and clicking on "Add Project":

    ![Create a Firebase project](/images/docs/mobile/installation/firebase/create-project.png)

    Name it as you want, and proceed to the dashboard.
  </Step>

  <Step>
    ## Install Firebase SDK

    To install React Native Firebase's base app module, run the following command in your mobile app directory:

    ```bash
    npx expo install @react-native-firebase/app
    ```
  </Step>

  <Step>
    ## Configure Firebase modules

    The recommended approach to configure React Native Firebase is to use [Expo Config Plugins](https://docs.expo.dev/config-plugins/introduction/).

    To enable Firebase on the native Android and iOS platforms, create and download Service Account files for each platform from your Firebase project.

    You can find them in the dashboard under the Firebase project settings:

    ![Download Service Account files](/images/docs/mobile/installation/firebase/config-files.png)

    For Android, it will be a `google-services.json` file, and for iOS it will be a `GoogleService-Info.plist` file.

    Then provide paths to the downloaded files in the following `app.config.ts` fields: [`android.googleServicesFile`](https://docs.expo.io/versions/latest/config/app/#googleservicesfile-1) and [`ios.googleServicesFile`](https://docs.expo.io/versions/latest/config/app/#googleservicesfile). This is how an example configuration looks like:

    ```ts title="app.config.ts"
    export default ({ config }: ConfigContext): ExpoConfig => ({
      ...config,
      ios: {
        googleServicesFile: "./GoogleService-Info.plist",
      },
      android: {
        googleServicesFile: "./google-services.json",
      },
      plugins: [
        "@react-native-firebase/app",
        [
          "expo-build-properties",
          {
            ios: {
              useFrameworks: "static",
            },
          },
        ],
      ],
    });
    ```

    <Callout>
      For iOS only, since `firebase-ios-sdk` requires `use_frameworks` you need to configure `expo-build-properties` by adding `"useFrameworks": "static"`.
    </Callout>

    Listing a module in the Config Plugins (the `plugins` array in the config above) is only required for React Native Firebase modules that involve native installation steps - e.g. modifying the Xcode project, `Podfile`, `build.gradle`, `AndroidManifest.xml` etc. React Native Firebase modules without native steps will work out of the box.
  </Step>

  <Step>
    ## Generate native code

    If you are compiling your app locally, you'll need to regenerate the native code for the platforms to pick up the changes:

    ```bash
    npx expo prebuild --clean
    ```

    Then, you could follow the same steps as in the [development environment setup](/docs/mobile/installation/development) guide to run the app locally or [build a production version](/docs/mobile/publishing/checklist#build-your-app) of your app.
  </Step>
</Steps>

Et voilà! You've set up and linked your Firebase project to your mobile app 🎉

You can learn more about the Firebase integration and it's possibilities in the [official documentation](https://rnfirebase.io/).


file: ./src/content/docs/mobile/installation/structure.mdx
meta: {
  "title": "Project structure",
  "description": "Learn about the project structure and how to navigate it."
}
        
The main directories in the project are:

* `apps` - the location of the main apps
* `packages` - the location of the shared code and the API

### `apps` Directory

This is where the apps live. It includes web app (Next.js), mobile app (React Native - Expo), and the browser extension (WXT - Vite + React). Each app has its own directory.

### `packages` Directory

This is where the shared code and the API for packages live. It includes the following:

* shared libraries (database, mailers, cms, billing, etc.)
* shared features (auth, mails, billing, ai etc.)
* UI components (buttons, forms, modals, etc.)

All apps can use and reuse the API exported from the packages directory. This makes it easy to have one, or many apps in the same codebase, sharing the same code.

## Repository structure

By default the monorepo contains the following apps and packages:

<Files>
  <Folder name="apps" defaultOpen>
    <Folder name="web - Web app (Next.js)" />

    <Folder name="mobile - Mobile app (React Native - Expo)" />

    <Folder name="extension - Browser extension (WXT - Vite + React)" />
  </Folder>

  <Folder name="packages" defaultOpen>
    <Folder name="api - API server (including all features logic)" />

    <Folder name="auth - Authentication setup" />

    <Folder name="billing - Billing config and providers" />

    <Folder name="cms - CMS setup and providers" />

    <Folder name="db - Database setup" />

    <Folder name="email - Mail templates and providers" />

    <Folder name="i18n - Internationalization setup" />

    <Folder name="shared - Shared utilities and helpers" />

    <Folder name="storage - Storage setup" />

    <Folder name="ui - Atomic UI components">
      <Folder name="shared" />

      <Folder name="web" />

      <Folder name="mobile" />
    </Folder>
  </Folder>

  <Folder name="tooling" defaultOpen>
    <Folder name="eslint - ESLint config" />

    <Folder name="github - Github actions" />

    <Folder name="prettier - Prettier config" />

    <Folder name="tailwind - Tailwind CSS config" />

    <Folder name="typescript - TypeScript config" />
  </Folder>
</Files>

## Mobile application structure

The mobile application is located in the `apps/mobile` folder. It contains the following folders:

<Files>
  <Folder name="public - Static assets" />

  <Folder name="src" defaultOpen>
    <Folder name="app - Main application" />

    <Folder name="assets - Optimized static assets" />

    <Folder name="components - Components for modules" />

    <Folder name="config - App config" />

    <Folder name="lib - Communication with packages" />

    <Folder name="providers - Shared React providers" />

    <Folder name="utils - Shared utilities" />
  </Folder>

  <File name=".env.local" />

  <File name="app.config.ts" />

  <File name="eas.json" />

  <File name="package.json" />

  <File name="metro.config.js" />

  <File name="tailwind.config.ts" />

  <File name="tsconfig.json" />

  <File name="turbo.json" />
</Files>


file: ./src/content/docs/mobile/installation/update.mdx
meta: {
  "title": "Updating codebase",
  "description": "Learn how to update your codebase to the latest version.",
  "mirror": "../../web/installation/update.mdx"
}
        


file: ./src/content/docs/mobile/publishing/checklist.mdx
meta: {
  "title": "Checklist",
  "description": "Let's publish your TurboStarter app to stores!"
}
        
When you're ready to publish your TurboStarter app to stores, follow this checklist.

This process may take a few hours and some trial and error, so buckle up — you're almost there!

<Steps>
  <Step>
    ## Create database instance

    **Why it's necessary?**

    A production-ready database instance is essential for storing your application's data securely and reliably in the cloud. [PostgreSQL](https://www.postgresql.org/) is the recommended database for TurboStarter due to its robustness, features, and wide support.

    **How to do it?**

    You have several options for hosting your PostgreSQL database:

    * [Supabase](https://supabase.com/) - Provides a fully managed Postgres database with additional features
    * [Vercel Postgres](https://vercel.com/storage/postgres) - Serverless SQL database optimized for Vercel deployments
    * [Neon](https://neon.tech/) - Serverless Postgres with automatic scaling
    * [Turso](https://turso.tech/) - Edge database built on libSQL with global replication
    * [DigitalOcean](https://www.digitalocean.com/products/managed-databases) - Managed database clusters with automated failover

    Choose a provider based on your needs for:

    * Pricing and budget
    * Geographic region availability
    * Scaling requirements
    * Additional features (backups, monitoring, etc.)
  </Step>

  <Step>
    ## Migrate database

    **Why it's necessary?**

    Pushing database migrations ensures that your database schema in the remote database instance is configured to match TurboStarter's requirements. This step is crucial for the application to function correctly.

    **How to do it?**

    You basically have two possibilities of doing a migration:

    <Tabs items={["Using Github Actions (recommended)", "Running locally"]}>
      <Tab value="Using Github Actions (recommended)">
        TurboStarter comes with predefined Github Action to handle database migrations. You can find its definition in the `.github/workflows/publish-db.yml` file.

        What you need to do is to set your `DATABASE_URL` as a [secret for your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).

        Then, you can run the workflow which will publish the database schema to your remote database instance.

        [Check how to run Github Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
      </Tab>

      <Tab value="Running locally">
        You can also run your migrations locally, although this is not recommended for production.

        To do so, set the `DATABASE_URL` environment variable to your database URL (that comes from your database provider) in `.env.local` file and run the following command:

        ```bash
        pnpm db:migrate
        ```

        This command will run the migrations and apply them to your remote database.

        [Learn more about database migrations.](/docs/web/database/migrations)
      </Tab>
    </Tabs>
  </Step>

  <Step>
    ## (Optional) Set up Firebase project

    **Why it's necessary?**

    Setting up a Firebase project is optional, and depends on which features your app is using. For example, if you want to use [Analytics](/docs/mobile/analytics/overview) with [Google Analytics](/docs/mobile/analytics/configuration#google-analytics), setting up a Firebase project is required.

    **How to do it?**

    Please refer to the [Firebase project](/docs/mobile/installation/firebase) section on how to set up and configure your Firebase project.
  </Step>

  <Step>
    ## Set up web backend API

    **Why it's necessary?**

    Setting up the backend is necessary to have a place to store your data and to have other features work properly (e.g., auth, billing).

    **How to do it?**

    Please refer to the [web deployment checklist](/docs/web/deployment/checklist) on how to set up and deploy the web app backend to production.
  </Step>

  <Step>
    ## Environment variables

    **Why it's necessary?**

    Setting the correct environment variables is essential for the application to function correctly. These variables include API keys, database URLs, and other configuration details required for your app to connect to various services.

    **How to do it?**

    Use our `.env.example` files to get the correct environment variables for your project. Then add them to your `eas.json` file under correct profile.

    ```json title="eas.json"
    {
      "profiles": {
        "base": {
          "env": {
            "EXPO_PUBLIC_DEFAULT_LOCALE": "en",
            "EXPO_PUBLIC_AUTH_PASSWORD": "true",
            "EXPO_PUBLIC_AUTH_MAGIC_LINK": "false",
            "EXPO_PUBLIC_THEME_MODE": "system",
            "EXPO_PUBLIC_THEME_COLOR": "orange"
          }
        },
        "production": {
          "extends": "base",
          "autoIncrement": true,
          "env": {
            "APP_ENV": "production",
            "EXPO_PUBLIC_SITE_URL": "https://turbostarter.dev",
          }
        }
      }
    }
    ```
  </Step>

  <Step>
    ## Build your app

    <Callout title="Prerequisite: EAS account">
      Building your app requires an EAS account and project. If you don't have one, you can create it by following the steps [here](https://expo.dev/eas).
    </Callout>

    **Why it's necessary?**

    Building your app is necessary to create a standalone application bundle that can be published to the stores.

    **How to do it?**

    You basically have two possibilities to build a bundle for your app:

    <Tabs items={["Using Github Actions (recommended)", "Running locally"]}>
      <Tab value="Using Github Actions (recommended)">
        TurboStarter comes with predefined Github Action to handle building your app on EAS. You can find its definition in the `.github/workflows/publish-mobile.yml` file.

        What you need to do is to set your `EXPO_TOKEN` as a [secret for your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions). You can obtain it from your EAS account, learn more in the [official documentation](https://docs.expo.dev/accounts/programmatic-access/#personal-access-tokens)

        Then, you can run the workflow which will build the app on EAS platform.

        [Check how to run Github Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
      </Tab>

      <Tab value="Running locally">
        You can also run your build locally, although this is not recommended for production.

        To do it, you'll need to have EAS CLI installed on your machine. You can install it by running the following command:

        ```bash
        npm install -g eas-cli
        ```

        Then, run the following command to build your app with the `production` profile:

        ```bash
        eas build --profile production --platform all
        ```

        This will build the app for both platforms (iOS and Android) and output the results in your app folder.
      </Tab>
    </Tabs>
  </Step>

  <Step>
    ## Submit to stores

    **Why it's necessary?**

    Submitting your app to the stores is necessary to make it available to your users. That's the only way to get your app in front of your users.

    **How to do it?**

    To submit your app to the stores, you will first need to get your app bundles. If you ran previous step locally you already should have the `.ipa` (for iOS) and `.aab` (for Android) files in your app folder.

    If you used Github Actions to build your app, you can find the results in the `Builds` tab of your [EAS project](https://expo.dev). Download the artifacts and save them on your local machine.

    Then, you would need to upload the bundles to the stores, here's how to do it:

    <Tabs items={["App Store", "Google Play"]}>
      <Tab value="App Store">
        Please follow the [official documentation](https://docs.expo.dev/submit/ios/#manual-submissions) on uploading your app to the App Stores.
      </Tab>

      <Tab value="Google Play">
        Please follow the [official documentation](https://docs.expo.dev/submit/android/#start-the-submission) on uploading your app to the Google Play Store.
      </Tab>
    </Tabs>

    <Callout title="Auto-submit is coming soon">
      We're working on an auto-submit feature for EAS, which will automate the process of submitting your app to the stores.

      [See roadmap](https://github.com/orgs/turbostarter/projects/1)
    </Callout>
  </Step>

  <Step>
    ## Send to review

    **Why it's necessary?**

    Sending your app to review is necessary to make it available to your users. That's the only way to get your app in front of your users, because you **must** follow the stores' guidelines and get your app approved.

    **How to do it?**

    You need to send your app to review to the stores, you can do it by going to the [App Store Connect](https://appstoreconnect.apple.com/apps) and [Google Play Console](https://play.google.com/console).

    Unfortunately, it's not possible to automate this step, so you'll need to do it manually.

    <Tabs items={["App Store", "Google Play"]}>
      <Tab value="App Store">
        1. Go to [App Store Connect](https://appstoreconnect.apple.com/apps)
        2. Select your app
        3. [Create new version](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version/)
        4. Fill release notes and other relevant information
        5. [Attach](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds) your uploaded `.ipa` file to a version
        6. Click on *Send to Review*
        7. [Confirm your submission](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-for-review/#:~:text=Submit%20an%20app,click%20%E2%80%9CAdd%20for%20Review%E2%80%9D.)
        8. Wait...

        Follow the [official documentation](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version) for more information.

        <Cards>
          <Card title="App Store Connect" description="appstoreconnect.apple.com" href="https://appstoreconnect.apple.com/apps" />

          <Card title="Create a new version" description="developer.apple.com" href="https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version/" />

          <Card title="Upload builds" description="developer.apple.com" href="https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds" />

          <Card title="Submit for review" description="developer.apple.com" href="https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-for-review/#:~:text=Submit%20an%20app,click%20%E2%80%9CAdd%20for%20Review%E2%80%9D.)" />
        </Cards>
      </Tab>

      <Tab value="Google Play">
        1. Go to [Google Play Console](https://play.google.com/console)
        2. Select your app
        3. [Create new release](https://support.google.com/googleplay/android-developer/answer/9859348)
        4. Fill release notes and other relevant information
        5. Attach your uploaded `.aab` file to a release
        6. Confirm your submission
        7. Wait...

        Follow the [official documentation](https://support.google.com/googleplay/android-developer/answer/9859348) for more information.

        <Cards>
          <Card title="Google Play Console" description="play.google.com" href="https://play.google.com/console" />

          <Card title="Prepare and roll out a release" description="support.google.com" href="https://support.google.com/googleplay/android-developer/answer/9859348" />
        </Cards>
      </Tab>
    </Tabs>

    Then, you would have to wait for the review process to complete. This process can take from a few hours to a few days, depending on the stores and the type of app you have.

    <Callout title="Your submission might be rejected" type="error">
      If your submission is rejected, you'll receive an email from the stores with the rejection reason. You'll need to fix the issues and upload a new version of your app.

      Make sure to follow the [guidelines](/docs/mobile/marketing) or check [publishing troubleshooting](/docs/mobile/troubleshooting/publishing) for more info.
    </Callout>

    When you receive the approval from the stores (by email or by push notification), you'll be able to publish your app on the stores.

    ![Review notification](/images/docs/mobile/review-notifications.jpeg)
  </Step>
</Steps>

That's it! Your app is now live and accessible to your users, good job! 🎉

<Callout title="Other things to consider">
  * Optimize your store listings with compelling descriptions, keywords, screenshots and preview videos
  * Remove placeholder content and replace with your final production content
  * Update all visual branding including favicon, scheme, splash screen and app icons
</Callout>


file: ./src/content/docs/mobile/publishing/updates.mdx
meta: {
  "title": "Updates",
  "description": "Learn how to update your published app."
}
        
When you publish your app to the stores, you can update it later to give your users new features and bug fixes.

TurboStarter comes with two ready-to-use ways to update your apps, we'll go through both of them.

## Submitting new version

The most traditional way to update your app is to submit a new version to the stores. This is the most reliable way to update your app, but it can take a while for the new version to be approved and available to the users.

To submit a new version, you need to change the version number in the `package.json` file and the `app.config.ts` file.

```json
{
    ...
    "version": "1.0.1",
    ...
}
```

Then, follow the exact same steps as [when you initially published your app](/docs/mobile/publishing/checklist), and, when you'll submit your app to review, provide release notes for the new version.

## Over-the-air (OTA) updates

Over-the-Air (OTA) updates allow you to push updates to your app without requiring users to download a new version from the app store. This is a powerful feature that enables rapid iteration and fixes.

<Callout title="OTA updates are coming soon">
  We are working on introducing seamless OTA updates integration into TurboStarter to enable you to push updates to your app without the need to submit a new version to the stores. Stay tuned for updates.

  [See roadmap](https://github.com/orgs/turbostarter/projects/1)
</Callout>


file: ./src/content/docs/mobile/troubleshooting/installation.mdx
meta: {
  "title": "Installation",
  "description": "Find answers to common mobile installation issues."
}
        
## Cannot clone the repository

Issues related to cloning the repository are usually related to a Git misconfiguration in your local machine. The commands displayed in this guide using SSH: these will work only if you have setup your SSH keys in Github.

If you run into issues, [please make sure you follow this guide to set up your SSH key in Github.](https://docs.github.com/en/authentication/connecting-to-github-with-ssh)

If this also fails, please use HTTPS instead. You will be able to see the commands in the repository's Github page under the "Clone" dropdown.

Please also make sure that the account that accepted the invite to TurboStarter, and the locally connected account are the same.

## Local database doesn't start

If you cannot run the local database container, it's likely you have not started [Docker](https://docs.docker.com/get-docker/) locally. Our local database requires Docker to be installed and running.

Please make sure you have installed Docker (or compatible software such as [Colima](https://github.com/abiosoft/colima), [Orbstack](https://github.com/orbstack/orbstack)) and that is running on your local machine.

Also, make sure that you have enough [memory and CPU allocated](https://docs.docker.com/engine/containers/resource_constraints/) to your Docker instance.

## I don't see my translations

If you don't see your translations appearing in the application, there are a few common causes:

1. Check that your translation `.json` files are properly formatted and located in the correct directory
2. Verify that the language codes in your configuration match your translation files
3. Enable debug mode (`debug: true`) in your i18next configuration to see detailed logs

[Read more about configuration for translations](/docs/mobile/internationalization#configuration)

## Expo cannot detect XCode

If you get the following error:

```bash
Expo cannot detect Xcode Xcode must be fully installed before you can continue
```

This is usually related to the Xcode CLI not being installed. You can fix this by running the following command:

```bash
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
```

If you still face the issue, please make sure you have the latest version of Xcode installed.

## "Module not found" error

This issue is mostly related to either dependency installed in the wrong package or issues with the file system.

The most common cause is incorrect dependency installation. Here's how to fix it:

1. Clean the workspace:

   ```bash
   pnpm clean
   ```

2. Reinstall the dependencies:
   ```bash
   pnpm i
   ```

If you're adding new dependencies, make sure to install them in the correct package:

```bash
# For main app dependencies
pnpm install --filter mobile my-package

# For a specific package
pnpm install --filter @turbostarter/ui my-package
```

If the issue persists, please check the file system for any issues.

### Windows OneDrive

OneDrive can cause file system issues with Node.js projects due to its file syncing behavior. If you're using Windows with OneDrive, you have two options to resolve this:

1. Move your project to a location outside of OneDrive-synced folders (recommended)
2. Disable OneDrive sync specifically for your development folder

This prevents file watching and symlink issues that can occur when OneDrive tries to sync Node.js project files.


file: ./src/content/docs/mobile/troubleshooting/publishing.mdx
meta: {
  "title": "Publishing",
  "description": "Find answers to common mobile publishing issues."
}
        
## My app submission was rejected

If your app submission was rejected, you probably got an email with the reason. You'll need to fix the issues and upload a new build of your app to the store and send it for review again.

Make sure to follow the [guidelines](/docs/mobile/marketing) when submitting your app to ensure that everything is setup correctly.

## App Store screenshots don't match requirements

If your app submission was rejected due to screenshot issues, make sure:

1. Screenshots match the required dimensions for each device
2. Screenshots accurately represent your app's functionality
3. You have provided screenshots for all required device sizes
4. Screenshots don't contain device frames unless they match Apple's requirements

[See Apple's screenshot specifications](https://developer.apple.com/app-store/screenshots/)

## Version number conflicts

If you get version number conflicts when submitting:

1. Ensure your `app.json` version matches what's in the store
2. Increment the version number appropriately:
   ```bash
   "version": "1.0.1",
   "android.versionCode": 2,
   "ios.buildNumber": "2"
   ```
3. Make sure both stores have unique version numbers


file: ./src/content/docs/web/ai/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Configure AI integration in your TurboStarter project."
}
        
To ensure scalability and avoid security vulnerabilities, AI requests are proxied by our [Hono backend](/docs/web/api/overview). This means you need to set up AI integration on both the client and server side.

<Callout title="Why proxy requests?">
  We want to avoid exposing API keys directly to the browser, as this could lead to abuse of your key and generate unnecessary costs.
</Callout>

In this section, we'll explore the configuration for both sides to give you a smooth start.

## Server-side

On the backend, you need to set up two things: environment variables to configure the provider and the procedure to pass responses to the client. Let's go through it!

### Environment variables

You need to set the environment variables that correspond to the AI provider you want to use.

For example, for the OpenAI provider, you would need to set the following environment variables:

```dotenv
OPENAI_API_KEY=<your-openai-api-key>
```

However, if you want to use the Anthropic provider, you would need to set these environment variables:

```dotenv
ANTHROPIC_API_KEY=<your-anthropic-api-key>
```

You can find the list of all available providers in the [official documentation](https://sdk.vercel.ai/providers/ai-sdk-providers), along with the required variables that need to be set to ensure the integration works correctly.

### API endpoint

As we're proxying the requests, we need to register an [API endpoint](/docs/web/api/new-endpoint) that will be used to pass the responses to the client.

The steps will be the same as we described in the [API](/docs/web/api/new-endpoint) section. An example implementation could look like this:

```ts title="ai.router.ts"
export const aiRouter = new Hono().post(
  "/chat",
  validate(
    "json",
    z.object({
      messages: z.array(
        z.object({
          role: z.enum(["user", "system", "data", "assistant"]),
          content: z.string(),
        }),
      ),
    }),
  ),
  (c) =>
    streamText({
      model: openai("gpt-4o"),
      messages: convertToCoreMessages(c.req.valid("json").messages),
    }).toDataStreamResponse(),
);
```

As you can see, we're defining which provider and specific model we want to use here.

We're also using [Streams API](https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Concepts), which allows us to pass the result to the user as soon as the model starts generating it, without needing to wait for the full response to be completed. This gives the user a sense of immediacy and makes the conversation more interactive.

## Client-side

To consume the server response, we can leverage the ready-to-use hooks provided by the [Vercel AI SDK](https://sdk.vercel.ai/docs/ai-sdk-ui/chatbot), such as the `useChat` hook:

```tsx title="page.tsx"
import { useChat } from "ai/react";

const AI = () => {
  const { messages } = useChat({
    api: "/api/ai/chat",
  });

  return (
    <div>
      {messages.map((message) => (
        <div key={message.id}>{message.content}</div>
      ))}
    </div>
  );
};

export default AI;
```

By leveraging this integration, we can easily manage the state of the AI request and update the UI as soon as the response is ready.

TurboStarter ships with a ready-to-use implementation of AI chat, allowing you to see this solution in action. Feel free to reuse or modify it according to your needs.


file: ./src/content/docs/web/ai/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with AI integration in your TurboStarter project."
}
        
For AI integration, TurboStarter leverages the [Vercel AI SDK](https://sdk.vercel.ai/docs/introduction), which provides a comprehensive set of tools and utilities to help you build AI applications more easily and efficiently.

<Callout title="Why Vercel AI SDK?">
  It's a simple yet powerful library that exposes a unified API for all major AI providers.

  This allows you to build your AI application without worrying about the intricacies of each underlying provider's API.
</Callout>

You can learn more about the `ai` package in the [official documentation](https://sdk.vercel.ai/docs/introduction).

## Features

The starter comes with the most common AI features built-in, such as:

* **Chat**: Build chat applications with ease.
* **Streaming responses**: Stream responses from your AI provider in real-time.
* **Image generation**: Generate images using AI technology.
* **Embeddings**: Generate embeddings for your data.
* **Vector stores**: Store and query your embeddings efficiently.

You can easily compose your application using these building blocks or extend them to suit your specific needs.

## Providers

**TurboStarter relies on the AI SDK to provide support for various AI providers.**

This means you can easily switch between different AI providers without changing your code, as long as they are supported by the `ai` package.

You can find the list of supported providers in the [official documentation](https://sdk.vercel.ai/providers/ai-sdk-providers).

<Callout title="Custom providers">
  There is also the possibility to add your own custom provider. It just needs to implement the common interface and provide all the necessary methods.

  Read more about this in the [official guide](https://sdk.vercel.ai/providers/community-providers/custom-providers).
</Callout>

The configuration for each provider is straightforward and simple. We'll explore this in more detail in the [Configuration](/docs/web/ai/configuration) section.


file: ./src/content/docs/web/analytics/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure web analytics in TurboStarter."
}
        
The `@turbostarter/analytics-web` package offers a streamlined and flexible approach to tracking events in your TurboStarter web app using various analytics providers. It abstracts the complexities of different analytics services and provides a consistent interface for event tracking.

In this section, we'll guide you through the configuration process for each supported provider.

Note that the configuration is validated against a schema, so you'll see error messages in the console if anything is misconfigured.

## Providers

TurboStarter supports multiple analytics providers, each with its own unique configuration. Below, you'll find detailed information on how to set up and use each supported provider. Choose the one that best suits your needs and follow the instructions in the respective accordion section.

<Accordions>
  <Accordion title="Vercel Analytics" id="vercel">
    To use Vercel Analytics as your provider, you need to [create a Vercel account](https://vercel.com/) and [set up a project](https://vercel.com/docs/projects/overview).

    Next, enable analytics in your Vercel project settings:

    1. Navigate to the [Vercel dashboard](https://vercel.com/dashboard).
    2. Select your project.
    3. Go to the *Analytics* section.
    4. Click *Enable* in the dialog.

    <Callout>
      Enabling Web Analytics will add new routes (scoped at `/_vercel/insights/*`) after your next deployment.
    </Callout>

    Also, make sure to activate the Vercel provider as your analytics provider:

    ```dotenv
    NEXT_PUBLIC_ANALYTICS_PROVIDER="vercel"
    ```

    To customize the provider, you can find its definition in `packages/analytics/web/src/providers/vercel` directory.

    For more information, please refer to the [Vercel Analytics documentation](https://vercel.com/docs/analytics/overview).

    ![Vercel Analytics dashboard](/images/docs/web/analytics/vercel.avif)
  </Accordion>

  <Accordion title="Google Analytics" id="google-analytics">
    To use Google Analytics as your analytics provider, you need to [create a Google Analytics account](https://analytics.google.com/) and [set up a property](https://support.google.com/analytics/answer/9304153).

    Next, add a data stream in your Google Analytics account settings:

    1. Navigate to [Google Analytics](https://analytics.google.com/).
    2. In the *Admin* section, under *Data collection and modification*, click on *Data Streams*.
    3. Click *Add stream*.
    4. Select *Web* as the platform.
    5. Enter the required details for the stream (at minimum, provide a name and website URL).
    6. Click *Create stream*.

    After creating the stream, you'll need two pieces of information:

    1. Your [Measurement ID](https://support.google.com/analytics/answer/12270356) (it should look like `G-XXXXXXXXXX`):

    ![Google Analytics Measurement ID](/images/docs/web/analytics/google/id.png)

    2. Your [Measurement Protocol API secret](https://support.google.com/analytics/answer/9814495):

    ![Google Analytics Measurement Protocol API secret](/images/docs/web/analytics/google/api-secret.png)

    Set these values in your `.env.local` file in the `apps/web` directory and in your deployment environment:

    ```dotenv
    NEXT_PUBLIC_ANALYTICS_GOOGLE_MEASUREMENT_ID="your-measurement-id"
    GOOGLE_ANALYTICS_SECRET="your-measurement-protocol-api-secret"
    ```

    Also, make sure to activate the Google Analytics provider as your analytics provider:

    ```dotenv
    NEXT_PUBLIC_ANALYTICS_PROVIDER="google-analytics"
    ```

    To customize the provider, you can find its definition in `packages/analytics/web/src/providers/google-analytics` directory.

    For more information, please refer to the [Google Analytics documentation](https://developers.google.com/analytics).

    ![Google Analytics dashboard](/images/docs/web/analytics/google/dashboard.jpg)
  </Accordion>

  <Accordion title="PostHog" id="posthog">
    To use PostHog as your analytics provider, you need to configure a PostHog instance. You can obtain the [Cloud](https://app.posthog.com/signup) instance by [creating an account](https://app.posthog.com/signup) or [self-host](https://posthog.com/docs/self-host) it.

    Then, create a project and, based on your [project settings](https://app.posthog.com/project/settings), fill the following environment variables in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    NEXT_PUBLIC_POSTHOG_KEY="your-posthog-api-key"
    NEXT_PUBLIC_POSTHOG_HOST="your-posthog-instance-host"
    ```

    Also, make sure to activate the PostHog provider as your analytics provider:

    ```dotenv
    NEXT_PUBLIC_ANALYTICS_PROVIDER="posthog"
    ```

    To customize the provider, you can find its definition in `packages/analytics/web/src/providers/posthog` directory.

    For more information, please refer to the [PostHog documentation](https://posthog.com/docs).

    ![PostHog dashboard](/images/docs/web/analytics/posthog.png)
  </Accordion>

  <Accordion title="Open Panel" id="open-panel">
    To use Open Panel as your analytics provider, you need to [create an account](https://openpanel.dev/) and [set up a client for your project](https://docs.openpanel.dev/docs).

    Then, you would need to set your client ID and secret in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    NEXT_PUBLIC_OPEN_PANEL_CLIENT_ID="your-client-id"
    OPEN_PANEL_CLIENT_SECRET="your-client-secret"
    ```

    Also, make sure to activate the Open Panel provider as your analytics provider:

    ```dotenv
    NEXT_PUBLIC_ANALYTICS_PROVIDER="open-panel"
    ```

    To customize the provider, you can find its definition in `packages/analytics/web/src/providers/open-panel` directory.

    For more information, please refer to the [Open Panel documentation](https://docs.openpanel.dev/).

    ![Open Panel dashboard](/images/docs/web/analytics/open-panel.webp)
  </Accordion>
</Accordions>

## Client-side context

To enable tracking events, capturing page views and other analytics features **on the client-side**, you need to wrap your app with the `Provider` component that's implemented by every provider and available through the `@turbostarter/analytics-web` package:

```tsx title="providers.tsx"
// [!code word:AnalyticsProvider]
import { memo } from "react";

import { Provider as AnalyticsProvider } from "@turbostarter/analytics-web";

interface ProvidersProps {
  readonly children: React.ReactNode;
}

export const Providers = memo<ProvidersProps>(({ children }) => {
  return (
    <OtherProviders>
      <AnalyticsProvider>{children}</AnalyticsProvider>
    </OtherProviders>
  );
});

Providers.displayName = "Providers";
```

By implementing this setup, you ensure that all analytics events are properly tracked from your client-side code. This configuration allows you to safely utilize the [Analytics API](/docs/web/analytics/tracking) within your client components, enabling comprehensive event tracking and data collection.


file: ./src/content/docs/web/analytics/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with web analytics in TurboStarter.",
  "index": true
}
        
TurboStarter comes with built-in analytics support for multiple providers as well as a unified API for tracking events. This API enables you to easily and consistently track user behavior and app usage across your SaaS application.

## Providers

The starter implements multiple providers for managing analytics. To learn more about each provider and how to configure them, see their respective sections:

<Cards>
  <Card title="Vercel Analytics" href="/docs/web/analytics/configuration#vercel" />

  <Card title="Google Analytics" href="/docs/web/analytics/configuration#google-analytics" />

  <Card title="PostHog" href="/docs/web/analytics/configuration#posthog" />

  <Card title="Open Panel" href="/docs/web/analytics/configuration#open-panel" />
</Cards>

All configuration and setup is built-in with a unified API, allowing you to switch between providers without changing your code. You can even introduce your own provider without breaking any tracking-related logic.

In the following sections, we'll cover how to set up each provider and how to track events in your application.


file: ./src/content/docs/web/analytics/tracking.mdx
meta: {
  "title": "Tracking events",
  "description": "Learn how to track events in your TurboStarter web app."
}
        
The implementation strategy for each analytics provider varies depending on whether it's designed for client-side or server-side use. We'll explore both approaches, as they are crucial for ensuring accurate and comprehensive analytics data in your web SaaS application.

## Client-side tracking

The client strategy for tracking events, which every provider must implement, is straightforward:

```ts
export type AllowedPropertyValues = string | number | boolean;

type TrackFunction = (
  event: string,
  data?: Record<string, AllowedPropertyValues>,
) => void;

export interface AnalyticsProviderClientStrategy {
  Provider: ({ children }: { children: React.ReactNode }) => React.ReactNode;
  track: TrackFunction;
}
```

<Callout>
  You don't need to worry much about this implementation, as all the providers are already configured for you. However, it's useful to be aware of this structure if you plan to add your own custom provider.
</Callout>

As shown above, each provider must supply two key elements:

1. `Provider` - a component that [wraps your app](/docs/web/analytics/configuration#client-side-context).
2. `track` - a function responsible for sending event data to the provider.

To track an event, you simply need to invoke the `track` method, passing the event name and an optional data object:

```tsx
import { track } from "@turbostarter/analytics-web";

export const MyComponent = () => {
  return (
    <button onClick={() => track("button.click", { country: "US" })}>
      Track event
    </button>
  );
};
```

## Server-side tracking

The server strategy for tracking events, that every provider has to implement, is even simpler:

```ts
export interface AnalyticsProviderServerStrategy {
  track: TrackFunction;
}
```

<Callout>
  You don't need to worry much about this implementation, as all the providers are already configured for you. However, it's useful to be aware of this structure if you plan to add your own custom provider.
</Callout>

This server-side strategy allows you to track events outside of the browser environment, which is particularly useful for scenarios involving server actions or React Server Components.

To track an event on the server side, simply call the `track` method, providing the event name and an optional data object:

```tsx
// [!code word:server]
import { track } from "@turbostarter/analytics-web/server";

track("button.click", {
  country: "US",
  region: "California",
});
```

<Callout type="error" title="Ensure correct import!">
  Make sure to use the correct import for the `track` function. We're using the same name for both client and server tracking, but they are different functions. For server-side, just add `/server` to the import path (`@turbostarter/analytics-web/server`).

  <Tabs items={["Client-side", "Server-side"]}>
    <Tab value="Client-side">
      ```tsx
      import { track } from "@turbostarter/analytics-web";
      ```
    </Tab>

    <Tab value="Server-side">
      ```tsx
      // [!code word:server]
      import { track } from "@turbostarter/analytics-web/server";
      ```
    </Tab>
  </Tabs>
</Callout>

Congratulations! You've now mastered event tracking in your TurboStarter web app. With this knowledge, you're well-equipped to analyze user behaviors and gain valuable insights into your application's usage patterns. Happy analyzing! 📊


file: ./src/content/docs/web/api/client.mdx
meta: {
  "title": "Using API client",
  "description": "How to use API client to interact with the API."
}
        
In Next.js, you can access the API client in two ways:

* **server-side**: in server components and API routes
* **client-side**: in client components

When you create a new page and want to fetch data, you have flexibility in where to make the API calls. Server Components are great for initial data loading since the fetching happens during server-side rendering, eliminating an extra client-server round trip. The data is then efficiently streamed to the client.

By default in Next.js, every component is a Server Component. You can opt into client-side rendering by adding the `use client` directive at the top of a component file. Client Components are useful when you need interactive features or want to fetch data based on user interactions. While they're initially server-rendered, they're also hydrated and rendered on the client, allowing you to make API calls directly from the browser.

Let's explore both approaches to understand their differences and use cases.

## Server-side

We're creating a server-side API client inside `apps/web/src/lib/api/server.ts` file. The client automatically handles passing authentication headers from the user's session to secure API endpoints.

It's pre-configured with all the necessary setup, so you can start using it right away without any additional configuration.

Then, there is nothing simpler than calling the API from your server component:

```tsx title="page.tsx"
import { api } from "~/lib/api/server";

export default async function MyServerComponent() {
  const response = await api.posts.$get();
  const posts = await response.json();

  /* do something with the data... */
  return <div>{JSON.stringify(posts)}</div>;
}
```

<Card title="Next.js - Server components" description="nextjs.org" href="https://nextjs.org/docs/app/building-your-application/rendering/server-components" />

## Client-side

We're creating a separate client-side API client in `apps/web/src/lib/api/client.tsx` file. It's a simple wrapper around the [@tanstack/react-query](https://tanstack.com/query/latest/docs/framework/react/overview) that fetches or mutates data from the API.

It also requires wrapping your app in a `ApiProvider` component to provide the query client to the rest of the app:

```tsx title="layout.tsx"
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        <ApiProvider>{children}</ApiProvider>
      </body>
    </html>
  );
}
```

Of course, it's all already configured for you, so you just need to start using `api` in your client components:

```tsx title="page.tsx"
"use client";

import { api } from "~/lib/api/client";

export default function MyClientComponent() {
  const { data: posts, isLoading } = useQuery({
    queryKey: ["posts"],
    queryFn: async () => {
      const response = await api.posts.$get();

      if (!response.ok) {
        throw new Error("Failed to fetch posts!");
      }

      return response.json();
    },
  });

  if (isLoading) {
    return <div>Loading...</div>;
  }

  /* do something with the data... */
  return <div>{JSON.stringify(posts)}</div>;
}
```

<Card title="Next.js - Client components" description="nextjs.org" href="https://nextjs.org/docs/app/building-your-application/rendering/client-components" />

<Callout type="warn" title="Ensure correct API url">
  Inside the `apps/web/src/lib/api/utils.ts` we're calling a function to get base url of your api, so make sure it's set correctly (especially on production) and your API endpoint is corresponding with the name there.

  ```tsx title="utils.ts"
  export const getBaseUrl = () => {
    if (typeof window !== "undefined") return window.location.origin;
    if (env.NEXT_PUBLIC_URL) return env.NEXT_PUBLIC_URL;
    if (env.VERCEL_URL) return `https://${env.VERCEL_URL}`;
    // eslint-disable-next-line no-restricted-properties, turbo/no-undeclared-env-vars
    return `http://localhost:${process.env.PORT ?? 3000}`;
  };
  ```

  As you can see we're mostly relying on the [environment variables](/docs/web/configuration/environment-variables) to get it, so there shouldn't be any issues with it, but in case, please be aware where to find it 😉
</Callout>

## Handling responses

As you can see in the examples above, the [Hono RPC](https://hono.dev/docs/guides/rpc) client returns a plain `Response` object, which you can use to get the data or handle errors. However, implementing this handling in every query or mutation can be tedious and will introduce unnecessary boilerplate in your codebase.

That's why we've developed the `handle` function that unwraps the response for you, handles errors, and returns the data in a consistent format. You can safely use it with any procedure from the API client:

<Tabs items={["Server-side", "Client-side"]}>
  <Tab value="Server-side">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/server";

    export default async function MyServerComponent() {
      const posts = await handle(api.posts.$get)();

      /* do something with the data... */
      return <div>{JSON.stringify(posts)}</div>;
    }
    ```
  </Tab>

  <Tab value="Client-side">
    ```tsx
    // [!code word:handle]

    "use client";

    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/client";

    export default function MyClientComponent() {
      const { data: posts, isLoading } = useQuery({
        queryKey: ["posts"],
        queryFn: handle(api.posts.$get),
      });

      if (isLoading) {
        return <div>Loading...</div>;
      }

      /* do something with the data... */
      return <div>{JSON.stringify(posts)}</div>;
    }
    ```
  </Tab>
</Tabs>

With this approach, you can focus on the business logic instead of repeatedly writing code to handle API responses in your browser extension components, making your extension's codebase more readable and maintainable.

The same error handling and response unwrapping benefits apply whether you're building web, mobile, or extension interfaces - allowing you to keep your data fetching logic consistent across all platforms.


file: ./src/content/docs/web/api/internationalization.mdx
meta: {
  "title": "Internationalization",
  "description": "Learn how to localize and translate your API."
}
        
Since TurboStarter provides fully featured [internationalization](/docs/web/internationalization/overview) out of the box, you can easily localize not only the frontend but also the API layer. This can be useful when you need to fetch localized data from the database or send emails in different languages.

Let's explore possibilities of this feature.

## Request-based localization

To get the locale for the current request, you can leverage the `localize` middleware:

```ts title="email.router.ts"
const emailRouter = new Hono().get("/", localize, (c) => {
  const locale = c.var.locale;

  // do something with the locale
});
```

Inside it, we're setting the `locale` variable in the current request context, making it available to the procedure.

## Error handling

When handling errors in an internationalized API, you'll want to ensure error messages are properly translated for your users. TurboStarter provides built-in support for localizing error messages using error codes and a special `onError` hook.

That's why it's recommended to use error codes instead of direct messages in your throw statements:

```ts
throw new HttpException(HttpStatusCode.UNAUTHORIZED, {
  code: "auth:error.unauthorized",
  /* 👇 optional */
  message: "You are not authorized to access this resource.",
});
```

The error code will then be used to retrieve the localized message, and the returned response from your API will look like this:

```json
{
  "code": "auth:error.unauthorized",
  /* 👇 localized based on request's locale */
  "message": "You are not authorized to access this resource.",
  "path": "/api/auth/login",
  "status": 401,
  "timestamp": "2024-01-01T00:00:00.000Z"
}
```

Then, you can either use the returned code to get the localized message in your frontend, or simply use the returned message as is.


file: ./src/content/docs/web/api/mutations.mdx
meta: {
  "title": "Mutations",
  "description": "Learn how to mutate data on the server."
}
        
As we saw in [adding new endpoint](/docs/web/api/new-endpoint#maybe-mutation), mutations allow us to modify data on the server, like creating, updating, or deleting resources. They can be defined similarly to queries using our API client.

Just like queries, mutations can be executed either server-side or client-side depending on your needs. Let's explore both approaches.

## Server actions

Next.js provides [server actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations) as a powerful way to handle mutations directly on the server. They're particularly well-suited for form submissions and other data modifications.

Using our `api` client with server actions is straightforward - you simply call the API function on the server.

Here's an example of how you can define an action to create a new post:

<Tabs items={["With helper", "Without helper"]}>
  <Tab value="With helper">
    ```tsx
    // [!code word:handle]
    "use server";

    import { revalidatePath } from "next/cache";

    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/server";

    export async function createPost(post: PostInput) {
      try {
        await handle(api.posts.$post)(post);
      } catch (error) {
        onError(error);
      }

      revalidatePath("/posts");
    }
    ```
  </Tab>

  <Tab value="Without helper">
    ```tsx
    "use server";

    import { revalidatePath } from "next/cache";

    import { api } from "~/lib/api/server";

    export async function createPost(post: PostInput) {
      const response = await api.posts.$post(post);

      if (!response.ok) {
        return { error: "Failed to create post" };
      }

      revalidatePath("/posts");
    }
    ```
  </Tab>
</Tabs>

In the above example we're also using `revalidatePath` to revalidate the path `/posts` to fetch the updated list of posts.

<Cards>
  <Card title="Server actions and mutation" description="nextjs.org" href="https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations" />

  <Card title="revalidatePath" description="nextjs.org" href="https://nextjs.org/docs/app/api-reference/functions/revalidatePath" />
</Cards>

## useMutation hook

On the other hand, if you want to perform a mutation in the client-side, you can use the `useMutation` hook that comes straight from the integration with [Tanstack Query](https://tanstack.com/query).

<Tabs items={["With helper", "Without helper"]}>
  <Tab value="With helper">
    ```tsx
    // [!code word:handle]
    import { handle } from "@turbostarter/api/utils";

    import { api } from "~/lib/api/react";

    export function CreatePost() {
      const queryClient = useQueryClient();
      const { mutate } = useMutation({
        mutationFn: handle(api.posts.$post),
        onSuccess: () => {
          toast.success("Post created successfully!");
          queryClient.invalidateQueries({ queryKey: ["posts"] });
        },
      });

      return <form onSubmit={...} />;
    }
    ```
  </Tab>

  <Tab value="Without helper">
    ```tsx
    import { api } from "~/lib/api/react";

    export function CreatePost() {
      const queryClient = useQueryClient();
      const { mutate } = useMutation({
        mutationFn: async (post: PostInput) => {
          const response = await api.posts.$post(post);

          if (!response.ok) {
            throw new Error("Failed to create post!");
          }
        },
        onSuccess: () => {
          toast.success("Post created successfully!");
          queryClient.invalidateQueries({ queryKey: ["posts"] });
        },
      });

      return <form onSubmit={...} />;
    }
    ```
  </Tab>
</Tabs>

<Cards>
  <Card title="useMutation hook" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/reference/useMutation" />

  <Card title="Query invalidation" description="tanstack.com" href="https://tanstack.com/query/latest/docs/framework/react/guides/query-invalidation" />
</Cards>


file: ./src/content/docs/web/api/new-endpoint.mdx
meta: {
  "title": "Adding new endpoint",
  "description": "How to add new endpoint to the API."
}
        
To define a new API endpoint, you can either extend an existing entity (e.g. add new customer route) or create a new, separate module.

<Steps>
  <Step>
    ## Create new module

    To create a new module you can create a new folder in the `modules` folder. For example `modules/posts`.

    Then you would need to create a router declaration for this module. We're following a convention with the filename suffixes, so you would need to create a file named `posts.router.ts` in the `modules/posts` folder.

    ```typescript title="modules/posts/posts.router.ts"
    import { Hono } from "hono";

    import { validate } from "../../middleware";

    export const postsRouter = new Hono().get(
      "/",
      validate("query", filtersSchema),
      (c) => getAllPosts(c.req.valid("query")),
    );
    ```

    As you can see we're implementing a `.get` method without any additional middlewares for the router. This is a simple way to define a new GET endpoint.

    Also, we're using a [zod](https://zod.dev/) validator to ensure that input passed to the endpoint is correct.
  </Step>

  <Step>
    ### Maybe mutation?

    The same way you can define a mutation for the new entity, just by changing the `get` to `post`:

    ```ts title="modules/posts/posts.router.ts"
    // [!code word:.post]
    export const postsRouter = new Hono().post(
      "/",
      enforceAuth,
      validate("json", postSchema),
      (c) => createPost(c.req.valid("json")),
    );
    ```

    Hono supports all [HTTP methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods), so you can define a new endpoint for any method you need (e.g. `put`, `delete`, etc.).

    The `enforceAuth` middleware ensures that only authenticated users can access the endpoint, while the zod validator checks if the input data matches the expected schema. This combination provides both authentication and data validation in a single, clean setup.

    [Read more about protected routes](/docs/web/api/protected-routes).
  </Step>

  <Step>
    ## Implement logic

    Then you would need to create a controller for this module. There is a place, where the logic happens, e.g. for the `GET /` endpoint we would need to create a `getAllPosts` function which will fetch posts from the database.

    ```typescript title="modules/posts/posts.controller.ts"
    import { db } from "@turbostarter/db/server";
    import { posts } from "@turbostarter/db/schema";

    export const getAllPosts = (filters: Filters) => {
      return db.select().from(posts).all().where(/* your filter logic here */);
    };
    ```
  </Step>

  <Step>
    ## Register router

    To make the module and its endpoints available in the API you need to register a router for this module in the `index.ts` file:

    ```ts title="index.ts"
    import { postsRouter } from "./modules/posts/posts.router";

    const appRouter = new Hono()
      .basePath("/api")
      .route("/posts", postsRouter)
      /* other routers from your app logic */
      .onError(onError);

    type AppRouter = typeof appRouter;

    export type { AppRouter };
    export { appRouter };
    ```

    The `basePath` method sets a prefix for all routes in this router. While optional, using it helps organize API endpoints. This modular approach makes the API structure clearer and easier to maintain.
  </Step>
</Steps>

That's it! You've just created a new API endpoint - it's now available at `/api/posts` 🎉

<Callout title="It's fully type-safe!">
  By exporting the `AppRouter` type you get fully type-safe RPC calls in the
  client. It's important because without producing a huge amount of code, we're
  fully type-safe from the frontend code. It helps avoid passing incorrect data
  to the procedure and streamline consuming returned types without a need to
  define these types by hand.
</Callout>


file: ./src/content/docs/web/api/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with the API.",
  "index": true
}
        
TurboStarter is designed to be a scalable and production-ready full-stack starter kit. One of its core features is a dedicated and extensible API layer. To enable this in a type-safe manner, we chose [Hono](https://hono.dev) as the API server and client library.

<Callout title="Why Hono?">
  Hono is a small, simple, and ultrafast web framework that gives you a way to
  define your API endpoints with full type safety. It provides built-in
  middleware for common needs like validation, caching, and CORS. It also
  includes an [RPC client](https://hono.dev/docs/guides/rpc) for making
  type-safe function calls from the frontend. Being edge-first, it's optimized
  for serverless environments and offers excellent performance.
</Callout>

All API endpoints and their resolvers are defined in the `packages/api/` package. Here you will find a `modules` folder that contains the different feature modules of the API. Each module has its own folder and exports all its resolvers.

For each module, we create a separate Hono route in the `packages/api/index.ts` file and aggregate all sub-routers into one main router.

The API is then exposed as a route handler that will be provided as a Next.js API route:

```ts title="apps/web/src/app/api/[...route]/route.ts"
import { handle } from "hono/vercel";

import { appRouter } from "@turbostarter/api";

const handler = handle(appRouter);
export { handler as GET, handler as POST };
```

<Callout type="warn" title="API availability">
  The API is a part of web, serverless Next.js app. It means that you **must**
  deploy it to use the API in other apps (e.g. mobile app, browser extension),
  even if you don't need web app itself. It's very simple, as you're just
  deploying the Next.js app and the API is just a part of it.
</Callout>

Learn more about API in the following sections:


file: ./src/content/docs/web/api/protected-routes.mdx
meta: {
  "title": "Protected routes",
  "description": "Learn how to protect your API routes."
}
        
Hono has built-in support for [middlewares](https://hono.dev/docs/guides/middleware), which are functions that can be used to modify the context or execute code before or after a route handler is executed.

That's how we can secure our API endpoints from unauthorized access. Below are some examples of you can leverage middlewares to protect your API routes.

## Authenticated access

After validating the user's authentication status, we store their data in the context using [Hono's built-in context](https://hono.dev/docs/api/context). This allows us to access the user's information in subsequent middleware and procedures without having to re-validate the session.

Here's an example of middleware that validates whether the user is currently logged in and stores their data in the context:

```ts title="middleware.ts"
/**
 * Reusable middleware that enforces users are logged in before running the
 * procedure
 */
export const enforceAuth = createMiddleware<{
  Variables: {
    user: User;
  };
}>(async (c, next) => {
  const session = await auth.api.getSession({ headers: c.req.raw.headers });
  const user = session?.user ?? null;

  if (!user) {
    throw new HTTPException(HttpStatusCode.UNAUTHORIZED, {
      message: "You need to be logged in to access this feature!",
    });
  }

  c.set("user", user);
  await next();
});
```

Then we can use our defined middleware to protect endpoints by adding it before the route handler:

```ts title="billing.router.ts"
export const billingRouter = new Hono().get(
  "/customer",
  enforceAuth,
  async (c) => c.json(await getCustomerByUserId(c.var.user.id)),
);
```

## Feature-based access

When developing your API you may want to restrict access to certain features based on the user's current subscription plan. (e.g. only users with "Pro" plan can access teams).

You can achieve this by creating a middleware that will check if the user has access to the feature and then pass the execution to the next middleware or procedure:

```ts title="middleware.ts"
/**
 * Reusable middleware that enforces users have access to a feature
 * before running the procedure
 */
export const enforceFeatureAvailable = (feature: Feature) =>
  createMiddleware<{
    Variables: {
      user: User;
    };
  }>(async (c, next) => {
    const { data: customer } = await getCustomerById(c.var.user.id);

    const hasFeature = isFeatureAvailable(customer, feature);

    if (!hasFeature) {
      throw new HTTPException(HttpStatusCode.PAYMENT_REQUIRED, {
        message: "Upgrade your plan to access this feature!",
      });
    }

    await next();
  });
```

Use it within your procedure the same way as we did with `enforceAuth` middleware:

```ts title="teams.router.ts"
export const teamsRouter = new Hono().get(
  "/",
  enforceAuth,
  enforceFeatureAvailable(FEATURES.PRO.TEAMS),
  (c) => c.json(...),
);
```

These are just examples of what you can achieve with Hono middlewares. You can use them to add any kind of logic to your API (e.g. [logging](https://hono.dev/docs/middleware/builtin/logger), [caching](https://hono.dev/docs/middleware/builtin/cache), etc.)


file: ./src/content/docs/web/auth/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Configure authentication for your application."
}
        
TurboStarter supports three different authentication methods:

* **Password** - the traditional email/password method
* **Magic Link** - passwordless email link authentication
* **OAuth** - OAuth providers, Google and Github are set up by default

All authentication methods are enabled by default, but you can easily customize them to your needs. You can enable or disable any method, and configure them according to your requirements.

<Callout>
  Remember that you can mix and match these methods or add new ones - for
  example, you can have both password and magic link authentication enabled at
  the same time, giving your users more flexibility in how they authenticate.
</Callout>

Authentication configuration can be customized through a simple configuration file. The following sections explain the available options and how to configure each authentication method based on your requirements.

## API

The **server-side** authentication configuration is set at `packages/auth/src/server.ts`. It confgures [Better Auth](https://better-auth.com) package to use the correct providers and settings:

```tsx title="server.ts"
export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true,
    sendResetPassword: () => {},
  },
  emailVerification: {
    sendOnSignUp: true,
    autoSignInAfterVerification: true,
    sendVerificationEmail: () => {},
  },
  database: drizzleAdapter(db, {
    provider: "pg",
    usePlural: true,
    schema,
  }),
  plugins: [
    magicLink({
      sendMagicLink: () => {},
    }),
    expo(),
    nextCookies(),
  ],
  socialProviders: {
    [SOCIAL_PROVIDER.GITHUB]: {
      clientId: env.GITHUB_CLIENT_ID,
      clientSecret: env.GITHUB_CLIENT_SECRET,
    },
    [SOCIAL_PROVIDER.GOOGLE]: {
      clientId: env.GOOGLE_CLIENT_ID,
      clientSecret: env.GOOGLE_CLIENT_SECRET,
    },
  },

  /* other configuration options */
});
```

The configuration is validated against Better Auth's schema at runtime, providing immediate feedback if any settings are incorrect or insecure. This validation ensures your authentication setup remains robust and properly configured.

All authentication routes and handlers are centralized within the [Hono API](/docs/web/api/overview), giving you a single source of truth and complete control over the authentication flow. This centralization makes it easier to maintain, debug, and customize the authentication process as needed.

[Read more about it in the official documentation](https://www.better-auth.com/docs/basic-usage).

## UI

We have separate configuration that determines what is displayed to your users in the **UI**. It's set at `apps/web/config/auth.ts`.

The recommendation is to **not update this directly** - instead, please define the environment variables and override the default behavior.

```ts title="apps/web/config/auth.ts"
import { SOCIAL_PROVIDER, authConfigSchema } from "@turbostarter/auth";

import { env } from "~/lib/env";

import type { AuthConfig } from "@turbostarter/auth";

export const authConfig = authConfigSchema.parse({
  providers: {
    password: env.NEXT_PUBLIC_AUTH_PASSWORD,
    magicLink: env.NEXT_PUBLIC_AUTH_MAGIC_LIND,
    oAuth: [SOCIAL_PROVIDER.GOOGLE, SOCIAL_PROVIDER.GITHUB],
  },
}) satisfies AuthConfig;
```

The configuration is also validated using the Zod schema, so if something is off, you'll see the errors.

For example, if you want to switch from password to magic link, you'd set the following environment variables:

```dotenv title=".env.local"
NEXT_PUBLIC_AUTH_PASSWORD=false
NEXT_PUBLIC_AUTH_MAGIC_LINK=true
```

To display third-party providers in the UI, you need to set the `oAuth` array to include the provider you want to display. The default is Google and Github:

```tsx title="apps/web/config/auth.ts"
providers: {
    ...
    oAuth: [SOCIAL_PROVIDER.GOOGLE, SOCIAL_PROVIDER.GITHUB],
    ...
},
```

## Third party providers

To enable third-party authentication providers, you'll need to:

1. Set up an OAuth application in the provider's developer console (like Google Cloud Console, Github Developer Settings or any other provider you want to use)
2. Configure the corresponding environment variables in your TurboStarter application

Each OAuth provider requires its own set of credentials and environment variables. Please refer to the [Better Auth documentation](https://better-auth.com/docs/concepts/oauth) for detailed setup instructions for each supported provider.

<Callout title="Environment variables">
  Make sure to set both development and production environment variables
  appropriately. Your OAuth provider may require different callback URLs for
  each environment.
</Callout>


file: ./src/content/docs/web/auth/flow.mdx
meta: {
  "title": "User flow",
  "description": "Discover the authentication flow in Turbostarter."
}
        
TurboStarter ships with a fully functional authentication system. Most of the views and components are preconfigured and easily customizable to your needs.

Here you will find a quick walkthrough of the authentication flow.

## Sign up

The sign-up page is where users can create an account. They need to provide their email address and password.

![Sign up](/images/docs/web/auth/sign-up.png)

Once successful, users are asked to confirm their email address. This is enabled by default - and due to security reasons, it's not possible to disable it.

<Callout type="warn" title="Sending authentication emails">
  Make sure to configure the [email provider](/docs/web/emails/configuration) together with the [auth hooks](/docs/web/emails/sending#authentication-emails) to be able to send emails from your app.
</Callout>

![Confirm email](/images/docs/web/auth/confirm-email.png)

## Sign in

The sign-in page is where users can log in to their account. They need to provide their email address and password, use magic link (if enabled) or third-party providers.

![Sign in](/images/docs/web/auth/sign-in.png)

## Sign out

The sign out button is located in the user menu.

![Sign out](/images/docs/web/auth/sign-out.png)

## Forgot password

The forgot password page is where users can reset their password. They need to provide their email address and follow the instructions in the email.

![Forgot password](/images/docs/web/auth/forgot-password.png)

The reset password page is where users land from a forgot email. There they can reset their password by providing new password and confirming it.

![Reset password](/images/docs/web/auth/update-password.png)


file: ./src/content/docs/web/auth/oauth.mdx
meta: {
  "title": "OAuth",
  "description": "Get started with social authentication."
}
        
Better Auth supports almost **15** (!) different [OAuth providers](https://www.better-auth.com/docs/concepts/oauth). They can be easily configured and enabled in the kit without any additional configuration needed.

<Callout title="Everything configured!">
  TurboStarter provides you with all the configuration required to handle OAuth providers responses from your app:

  * redirects
  * middleware
  * confirmation API routes

  You just need to configure one of the below providers on their side and set correct credentials as environment variables in your TurboStarter app.
</Callout>

![OAuth providers](/images/docs/web/auth/social-providers.png)

Third Party providers need to be configured, managed and enabled fully on the provider's side. TurboStarter just needs the correct credentials to be set as environment variables in your app and passed to the [authentication API configuration](/docs/web/auth/configuration#api).

To enable OAuth providers in your TurboStarter app, you need to:

1. Set up an OAuth application in the provider's developer console (like Google Cloud Console, Github Developer Settings or any other provider you want to use)
2. Configure the provider's credentials as environment variables in your app. For example, for Google OAuth:

```dotenv title="packages/db/.env.local"
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
```

Then, pass it to the authentication configuration in `packages/auth/src/server.ts`:

```tsx title="server.ts"
export const auth = betterAuth({
  ...

  socialProviders: {
    [SOCIAL_PROVIDER.GOOGLE]: {
      clientId: env.GOOGLE_CLIENT_ID,
      clientSecret: env.GOOGLE_CLIENT_SECRET,
    },
  },

  ...
});
```

<Callout title="Missing provider?">
  Better Auth provides a [generic OAuth plugin](https://www.better-auth.com/docs/plugins/generic-oauth) that allows you to add any OAuth provider to your app.

  It supports both OAuth 2.0 and OpenID Connect (OIDC) flows, allowing you to easily add social login or custom OAuth authentication to your application.
</Callout>


file: ./src/content/docs/web/auth/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with authentication.",
  "index": true
}
        
TurboStarter uses [Better Auth](https://better-auth.com) to handle authentication. It's a secure, production-ready authentication solution that integrates seamlessly with many frameworks and provides enterprise-grade security out of the box.

<Callout title="Why Better Auth?">
  One of the core principles of TurboStarter is to do things **as simple as possible**, and to make everything **as performant as possible**.

  Better Auth provides an excellent developer experience with minimal configuration required, while maintaining enterprise-grade security standards. Its framework-agnostic approach and focus on performance makes it the perfect choice for TurboStarter.
</Callout>

![Better Auth](/images/docs/better-auth.png)

You can read more about Better Auth in the [official documentation](https://better-auth.com/docs).

TurboStarter supports multiple authentication methods:

* **Password** - the traditional email/password method
* **Magic Link** - magic links
* **OAuth** - OAuth social providers (Google and Github preconfigured)

As well as common applications flows, with ready-to-use views and components:

* **Sign in** - sign in with email/password or OAuth providers
* **Sign up** - sign up with email/password or OAuth providers
* **Sign out** - sign out
* **Password recovery** - forgot and reset password
* **Email verification** - verify email

You can construct your auth flow like LEGO bricks - plug in needed parts and customize them to your needs.


file: ./src/content/docs/web/billing/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Configure billing for your application."
}
        
The billing configuration schema replicates your billing provider's schema, so that:

* we can display the data in the UI (pricing table, billing section, etc.)
* create the correct checkout session
* make some features work correctly - such as feature-based access

It is common to all billing providers and placed in `packages/billing/src/config/index.ts`. Some billing providers have some differences in what you can or cannot do. In these cases, the schema will try to validate and enforce the rules - but it's up to you to make sure the data is correct.

The schema is based on few entities:

* **Plans:** The main product you are selling (e.g., "Pro Plan", "Starter Plan", etc.)
* **Prices:** The pricing plan for the product (e.g., "Monthly", "Yearly", etc.)
* **Discounts:** The discount for the price (e.g., "10% off", "20% off", etc.)

```ts title="index.ts"
type BillingConfig = {
  plans: PlanWithPrices[];
  discounts: Discount[];
};
```

<Callout title="Getting the schema right is important!" type="error">
  Getting the IDs of your plans is **extremely important** - as these are used to:

  * create the correct checkout
  * manage your customers billing data

  Please take it easy while you configure this, do one step at a time, and test it thoroughly.
</Callout>

## Billing provider

To set the billing provider, you need to modify the `BILLING_PROVIDER` environment variable. It defaults to [Stripe](/docs/web/billing/stripe).

```dotenv
BILLING_PROVIDER="stripe"
```

It's important to set it correctly, as this is used to determine the correct API calls and environment variables used during the communication with the billing provider.

## Billing model

To set the billing model, you need to modify the `BILLING_MODEL` environment variable. It defaults to `recurring` as it's the most common model for SaaS apps.

```dotenv
BILLING_MODEL="recurring"
```

This field will be used to display corresponding data in the UI (e.g. in pricing tables) and to create the correct checkout session.

<Callout title="Available billing models">
  For now, TurboStarter supports two billing models:

  * `recurring` - for subscription-based models
  * `one-time` - for one-time payments

  When changing it, make sure to also update corresponding data on the provider side to match it with the correct billing model.
</Callout>

## Plans

Plans are the main products you are selling. They are defined by the following fields:

```ts title="index.ts"
export const config = billingConfigSchema.parse({
  ...
  plans: [
    {
      id: PricingPlanType.PREMIUM,
      name: "Premium",
      description: "Become a power user and gain benefits",
      badge: "Bestseller",
      prices: [],
    },
  ],
  ...
}) satisfies BillingConfig;
```

Let's break down the fields:

* `id`: The unique identifier for the plan (e.g., `free`, `pro`, `enterprise`, etc.). **This is chosen by you, it doesn't need to be the same one as the one in the provider.** It's also used to determine the access level of the plan.
* `name`: The name of the plan
* `description`: The description of the plan
* `badge`: A badge to display on the product (e.g., "Bestseller", "Popular", etc.)

The majority of these fields are going to populate the pricing table in the UI.

### Prices

Prices are the pricing plans for the plan. They are defined by the following fields:

```ts title="index.ts"
export const config = billingConfigSchema.parse({
  ...
  plans: [
    {
      id: PricingPlanType.PREMIUM,
      name: "Premium",
      description: "Become a power user and gain benefits",
      badge: "Bestseller",
      prices: [
        {
          /* 👇 This is the `priceId` from the provider (e.g. Stripe) or `variantId` (e.g. Lemon Squeezy) */
          id: "price_1PpZAAFQH4McJDTlig6Fxsyy",
          amount: 1900,
          currency: "usd",
          interval: RecurringInterval.MONTH,
          trialDays: 7,
          type: BillingModel.RECURRING,
        },
      ],
    },
  ],
  ...
}) satisfies BillingConfig;
```

Let's break down the fields:

* `id`: The unique identifier for the price. **This must match the price ID in the billing provider**
* `amount`: The amount of the price (displayed values will be divided by 100)
* `currency`: The currency of the price (only currencies from the [current locale](/docs/web/internationalization/overview) will be displayed - defaults to `usd`)

<Callout title="Set the correct currency on your billing provider">
  Make sure to have the same currency set on your third-party billing provider (e.g. as a [store currency](https://docs.lemonsqueezy.com/help/payments/currencies) on Lemon Squeezy)
</Callout>

* `interval`: The interval of the price (e.g., `month`, `year`, etc.)
* `trialDays`: The number of trial days for the price
* `type`: The type of the price (e.g., `recurring`, `one-time`, etc.)

The amount is set for UI purposes. The billing provider will handle the actual billing - therefore, please make sure the amount is correctly set in the billing provider.

<Callout title="Set the correct price ID!" type="error">
  Make sure to set the correct price ID that corresponds to the price in the billing provider. This is very important - as this is used to identify the correct price when creating a checkout session.
</Callout>

### One-off payments

One-off payments are a type of price that is used to create a checkout session for a one-time payment. They are defined by the following fields:

```ts title="index.ts"
export const config = billingConfigSchema.parse({
  ...
  plans: [
    {
      id: PricingPlanType.PREMIUM,
      name: "Premium",
      description: "Become a power user and gain benefits",
      badge: "Bestseller",
      prices: [
        {
          /* 👇 This is the `priceId` from the provider (e.g. Stripe) or `variantId` (e.g. Lemon Squeezy) */
          id: "price_1PpUagFQH4McJDTlHCzOmyT6",
          amount: 29900,
          currency: "usd",
          type: BillingModel.ONE_TIME,
        },
      ],
    },
  ],
  ...
}) satisfies BillingConfig;
```

Let's break down the fields:

* `id`: The unique identifier for the price. **This must match the price ID in the billing provider**
* `amount`: The amount of the price (displayed values will be divided by 100)
* `currency`: The currency of the price (only currencies from the [current locale](/docs/web/internationalization/overview) will be displayed - defaults to `usd`)
* `type`: The type of the price (e.g. `recurring`, `one-time`, etc.). In this case it's `one-time` as it's a one-off payment.

Please remember that the cost is set for UI purposes. **The billing provider will handle the actual billing - therefore, please make sure the cost is correctly set in the billing provider.**

### Custom prices

Sometimes - you want to display a price in the pricing table - but not actually have it in the billing provider. This is common for custom plans, free plans that don't require the billing provider subscription, or plans that are not yet available.

To do so, let's add the `custom` flag to the price:

```ts title="index.ts"
{
  id: "enterprise-monthly",
  label: "Contact us!",
  href: "/contact",
  interval: RecurringInterval.MONTH,
  custom: true,
  type: BillingModel.RECURRING,
}
```

Here's the full example:

```ts title="index.ts"
export const config = billingConfigSchema.parse({
  ...
  plans: [
    {
      id: PricingPlanType.PREMIUM,
      name: "Premium",
      description: "Become a power user and gain benefits",
      badge: "Bestseller",
      prices: [
        {
          id: "premium-monthly",
          label: "Contact us!",
          href: "/contact",
          interval: RecurringInterval.MONTH,
          custom: true,
          type: BillingModel.RECURRING,
        },
      ],
    },
  ],
  ...
}) satisfies BillingConfig;
```

As you can see, the plan is now a custom plan. The UI will display the plan in the pricing table, but it won't be available for purchase.

We do this by adding the following fields:

* `custom`: A flag to indicate that the plan is custom. This will prevent the plan from being available for purchase. It's set to `false` by default.
* `label`: This is used to display the label in the pricing table instead of the price.
* `href`: The link to the page where the user can contact you. This is used in the pricing table.

<Callout title="Translations supported!">
  All labels and descriptions can be translated using the [internationalization](/docs/web/internationalization/overview) feature. The UI will display the correct translation based on the user's locale.

  ```ts title="index.ts"
  label: "common:contactUs",
  ```

  To make strings translatable, make sure to provide the translation key in the config.
</Callout>

### Discounts

Sometimes, you want to offer a discount to your users. This is done by adding a discount to the price in `discounts` field.

```ts title="index.ts"
export const config = billingConfigSchema.parse({
  ...
  discounts: [
    {
      code: "50OFF",
      type: BillingDiscountType.PERCENT,
      off: 50,
      appliesTo: [
        "price_1PpUagFQH4McJDTlHwsCzOmyT6",
      ],
    },
  ],
  ...
}) satisfies BillingConfig;
```

Let's break down the fields:

* `code`: The code of the discount (e.g., "50OFF", "10% off", etc.) **This must match the code configured in the billing provider**
* `type`: The type of the discount (e.g., `percent`, `amount`, etc.)
* `off`: The amount of the discount (e.g., 50 for 50% off)
* `appliesTo`: The list of prices that the discount applies to. This is the price ID that you've configured above for the price.

This data will allow to display the correct banner in the UI e.g. "10% off for the first 100 customers!" and to apply the discount to the correct price at checkout.

## Adding more products, plans and discounts

Simply add more plans, prices and discounts to the arrays. The UI **should** be able to handle it in most traditional cases. If you have a more complex billing schema, you may need to adjust the UI accordingly.


file: ./src/content/docs/web/billing/lemon-squeezy.mdx
meta: {
  "title": "Lemon Squeezy",
  "description": "Manage your customers data and subscriptions using Lemon Squeezy."
}
        
Lemon Squeezy is another billing provider available for TurboStarter. Here we'll go through the configuration and how to set it up as a provider for your app.

To switch to Lemon Squeezy you need to set it as provider in the environment variables:

```dotenv title="apps/web/.env.local"
BILLING_PROVIDER="lemon-squeezy"
```

Then, let's configure the integration:

<Steps>
  <Step>
    ## Get API keys

    After you have created your account and a store for [Lemon Squeezy](https://lemonsqueezy.com/), you will need to create a new API key. You can do this by going to the [API page](https://app.lemonsqueezy.com/settings/api) in the settings and clicking on the plus button. You will need to give your API key a name and then click on the *Create* button. Once you have created your API key, you will need to copy the API key to use it in the setup of the integration.

    For local development, make sure to use [Test Mode](https://docs.lemonsqueezy.com/help/getting-started/test-mode) to not mess with the real transactions.
  </Step>

  <Step>
    ## Set environment variables

    You need to set the following environment variables:

    ```dotenv title="apps/web/.env.local"
    LEMONSQUEEZY_API_KEY="" # Your Lemon Squeezy API key
    LEMONSQUEEZY_SIGNING_SECRET="" # Your Lemon Squeezy webhook signing secret
    LEMONSQUEEZY_STORE_ID="" # Your Lemon Squeezy store ID (can be found under Settings > Stores next to your store url, e.g #12345)
    ```

    **Please do not add the secret keys to the .env file in production.** During development, you can place them in `.env.local` as it's not committed to the repository. In production, you can set them in the environment variables of your hosting provider.
  </Step>

  <Step>
    ## Create products

    For your users to choose from the available subscription plans, you need to create those Products first on the [Products page](https://app.lemonsqueezy.com/products). You can create as many products as you want.

    Create one product per plan you want to offer. You can add multiple variant within the product to offer multiple models or different billing intervals.

    ![Lemon Squeezy Products](/images/docs/web/billing/lemon-squeezy/products.webp)

    To offer multiple intervals for each plan, you can use the [Variant](https://docs.lemonsqueezy.com/help/products/variants) feature of Lemon Squeezy. Just create one variant for each interval/model you want to offer.

    ![Lemon Squeezy Variants](/images/docs/web/billing/lemon-squeezy/variants.png)

    <Callout type="warn" title="Match the variant id with configuration">
      You need to make sure that the price ID you set in the configuration matches the ID of the variant you created in Lemon Squeezy.

      [See configuration](/docs/web/billing/configuration#prices) for more information.
    </Callout>
  </Step>

  <Step>
    ## Create a webhook

    To sync the current subscription status or checkout conclusion and other information to your database, you need to set up a webhook.

    The webhook handling code comes ready to use with TurboStarter, you just have to create the webhook in the Lemon Squeezy dashboard and insert the URL for your project.

    To configure a new webhook, go to the [Webhooks page](https://app.lemonsqueezy.com/settings/webhooks) in the Lemon Squeezy settings and click the *Plus* button.

    ![Lemon Squeezy Webhook](/images/docs/web/billing/lemon-squeezy/webhook.png)

    Select the following events:

    * For subscriptions:
      * `subscription_created`
      * `subscription_updated`
      * `subscription_cancelled`
    * For one-off payments:
      * `order_created`

    You will also have to enter a *Signing secret* which you can get by running the following command in your terminal:

    ```bash
    openssl rand -base64 32
    ```

    Copy the generated string and paste it into the *Signing secret* field.

    You also need to add this secret to your environment variables:

    ```dotenv title="apps/web/.env.local"
    LEMONSQUEEZY_WEBHOOK_SECRET=your-signing-secret
    ```

    To get the callback URL for the webhook, you can either use a local development URL or the URL of your deployed app:

    ### Local development

    If you want to test the webhook locally, you can use [ngrok](https://ngrok.com) to create a tunnel to your local machine. Ngrok will then give you a URL that you can use to test the webhook locally.

    To do so, install ngrok and run it with the following command (while your TurboStarter web development server is running):

    ```bash
    ngrok http 3000
    ```

    ![Ngrok](/images/docs/web/billing/stripe/ngrok.png)

    This will give you a URL (see the *Forwarding* output) that you can use to create a webhook in Lemon Squeezy. Just use that url and add `/api/billing/webhook` to it.

    <Card title="Lemon Squeezy Webhooks" description="docs.lemonsqueezy.com" href="https://docs.lemonsqueezy.com/api/webhooks" />

    ### Production deployment

    When going to production, you will need to set the webhook URL and the events you want to listen to in Lemon Squeezy.

    The webhook path is `/api/billing/webhook`. If your app is hosted at `https://myapp.com` then you need to enter `https://myapp.com/api/billing/webhook` as the URL.

    All the relevant events are automatically handled by TurboStarter, so you don't need to do anything else. If you want to handle more events please check [Webhooks](/docs/web/billing/webhooks) for more information.
  </Step>
</Steps>

## Add discount

You can add a discount for your customers that will apply on a specific price.

You can create the discount on [Discounts page](https://app.lemonsqueezy.com/discounts).

![Lemon Squeezy Discounts](/images/docs/web/billing/lemon-squeezy/discount.png)

You can set there a details of discount such as products that it should apply to, amount off, duration, max redemptions and more.

<Card title="Lemon Squeezy Discounts" description="lemonsqueezy.com" href="https://www.lemonsqueezy.com/marketing/discount-codes" />

You need to add also the discount code and details to TurboStarter billing configuration to enable displaying it in the UI, creating checkout sessions with it and calculate prices.

[See discounts configuration](/docs/web/billing/configuration#discounts) for more details.

That's it! 🎉 You have now set up Lemon Squeezy as a billing provider for your app.

Feel free to add more products, prices, discounts and manage your customers data and subscriptions using Lemon Squeezy.

<Callout type="warn" title="Ensure configuration matches">
  Make sure that the data you set in the configuration matches the details of things you created in Lemon Squeezy.

  [See configuration](/docs/web/billing/configuration) for more information.
</Callout>


file: ./src/content/docs/web/billing/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with billing in TurboStarter.",
  "index": true
}
        
The `@turbostarter/billing` package is used to manage subscriptions, one-off payments, and more.

Inside, we're making an abstraction layer that allows us to use different billing providers without breaking our code nor changing the API calls.

![Billing Providers](/images/docs/billing-providers.png)

## Providers

TurboStarter implements multiple providers for managing billing:

* [Stripe](/docs/web/billing/stripe)
* [Lemon Squeezy](/docs/web/billing/lemon-squeezy)
* [Paddle](/docs/web/billing/paddle) (coming soon)

All configuration and setup is built-in with a unified API, so you can switch between providers without changing your code.

## Subscriptions vs. One-off payments

TurboStarter supports both one-off payments and subscriptions. You have the choice to use one or both. What TurboStarter cannot assume with certainty is the billing mode you want to use. By default, we assume you want to use subscriptions, as this is the most common billing mode for SaaS applications.

This means that - by default - TurboStarter will be looking for a subscription plan when visiting the billing section or pricing page.

**It's easily customizable** - [take a look at configuration](/docs/web/billing/configuration).

### But I want to use both

Perfect - you can, but you need to customize the pages to display the correct data.

Depending on the service you use, you will need to set the environment variables accordingly. By default - the billing package uses [Stripe](/docs/web/billing/stripe). Alternatively, you can use [Lemon Squeezy](/docs/web/billing/lemon-squeezy). In the future, we will also add [Paddle](/docs/web/billing/paddle).


file: ./src/content/docs/web/billing/paddle.mdx
meta: {
  "title": "Paddle",
  "description": "Manage your customers data and subscriptions using Paddle."
}
        
<Callout title="Paddle integration is coming soon!">
  We are working on adding Paddle integration to our platform. As soon as it's ready, we will update this page with the necessary information.
</Callout>


file: ./src/content/docs/web/billing/stripe.mdx
meta: {
  "title": "Stripe",
  "description": "Manage your customers data and subscriptions using Stripe."
}
        
Stripe is the default billing provider for TurboStarter. Here we'll go through the configuration and how to set it up as a provider for your app.

<Steps>
  <Step>
    ## Get API keys

    After you have created your account for [Stripe](https://stripe.com), you will need to get the API key. You can do this by going to the [API page](https://dashboard.stripe.com/apikeys) in the dashboard. Here you will find the *Secret key* and the *Publishable key*. You will need the *Secret key* for the integration to work.

    For local development, make sure to use [Test Mode](https://docs.stripe.com/test-mode) to not mess with the real transactions.
  </Step>

  <Step>
    ## Set environment variables

    You need to set the following environment variables:

    ```dotenv title="apps/web/.env.local"
    STRIPE_SECRET_KEY="" # Your Stripe secret key
    STRIPE_WEBHOOK_SECRET="" # The secret key of the webhook you created (see below)
    ```

    **Please do not add the secret keys to the .env file in production.** During development, you can place them in `.env.local` as it's not committed to the repository. In production, you can set them in the environment variables of your hosting provider.
  </Step>

  <Step>
    ## Create products

    For your users to choose from the available subscription plans, you need to create those Products first on the [Products page](https://dashboard.stripe.com/products). You can create as many products as you want.

    Create one product per plan you want to offer. You can add multiple prices within this product to offer multiple models or different billing intervals.

    ![Stripe Products](/images/docs/web/billing/stripe/products.webp)

    <Callout type="warn" title="Match the price id with configuration">
      You need to make sure that the price ID you set in the configuration matches the ID of the price you created in Stripe.

      [See configuration](/docs/web/billing/configuration) for more information.
    </Callout>
  </Step>

  <Step>
    ## Create a webhook

    To sync the current subscription status or checkout conclusion and other information to your database, you need to set up a webhook.

    The webhook code comes ready to use with TurboStarter, you just have to create the webhook in the Stripe dashboard and insert the URL for your project.

    To configure a new webhook, go to the [Webhooks page](https://dashboard.stripe.com/webhooks) in the Stripe settings and click the Add endpoint button.

    ![Stripe Webhook](/images/docs/web/billing/stripe/webhook.png)

    Select the following events:

    * For subscriptions:
      * `customer.subscription.created`
      * `customer.subscription.updated`
      * `customer.subscription.deleted`
    * For one-off payments:
      * `checkout.session.completed`

    To get the URL for the webhook, you can either use a local development URL or the URL of your deployed app:

    ### Local development

    There are two ways to test the webhook during local development:

    <Tabs items={["Stripe CLI", "Tunnel"]}>
      <Tab value="Stripe CLI">
        The Stripe CLI which allows you to listen to Stripe events straight to your own localhost. You can install and use the CLI using a variety of methods, but we recommend using official way to do it.

        [Install the Stripe CLI](https://docs.stripe.com/stripe-cli)

        Then - login to your Stripe account using the project you want to run:

        ```bash
        stripe login
        ```

        Copy the webhook secret displayed in the terminal and set it as the `STRIPE_WEBHOOK_SECRET` environment variable in your `apps/web/.env.local` file:

        ```dotenv title="apps/web/.env.local"
        STRIPE_WEBHOOK_SECRET=*your-secret-key*
        ```

        Now, you can listen to Stripe events running the following command:

        ```bash
        stripe listen --forward-to localhost:3000/api/billing/webhook
        ```

        This will forward all the Stripe events to your local endpoint.

        <Callout type="warn" title="Not receiving events?">
          **If you have not logged in** - the first time you set it up, you are required to sign in. This is a one-time process. Once you sign in, you can use the CLI to listen to Stripe events.

          **Please sign in and then re-run the command.** Now, you can listen to Stripe events.

          If you're not receiving events, please make sure that:

          * the webhook secret is correct
          * the account you signed in is the same as the one you're using in your app
        </Callout>

        You can even trigger the event manually for testing purposes:

        ```bash
        stripe trigger customer.subscription.created
        ```

        <Card title="Stripe CLI" description="docs.stripe.com" href="https://docs.stripe.com/stripe-cli" />
      </Tab>

      <Tab value="Tunnel">
        If you want to test the webhook locally, you can use [ngrok](https://ngrok.com) to create a tunnel to your local machine. Ngrok will then give you a URL that you can use to test the webhook locally.

        To do so, install ngrok and run it with the following command (while your TurboStarter web development server is running):

        ```bash
        ngrok http 3000
        ```

        ![Ngrok](/images/docs/web/billing/stripe/ngrok.png)

        This will give you a URL (see the *Forwarding* output) that you can use to create a webhook in Stripe. Just use that url and add `/api/billing/webhook` to it.

        <Card title="Stripe Webhooks" description="docs.stripe.com" href="https://docs.stripe.com/webhooks" />
      </Tab>
    </Tabs>

    ### Production deployment

    When going to production, you will need to set the webhook URL and the events you want to listen to in Stripe.

    The webhook path is `/api/billing/webhook`. If your app is hosted at `https://myapp.com` then you need to enter `https://myapp.com/api/billing/webhook` as the URL.

    All the relevant events are automatically handled by TurboStarter, so you don't need to do anything else. If you want to handle more events please check [Webhooks](/docs/web/billing/webhooks) for more information.
  </Step>

  <Step>
    ## Configure Stripe Customer Portal

    Stripe requires you to set up the Customer Portal so that users can manage their billing information, invoices and plan settings from there.

    You can do it [under the following link.](https://dashboard.stripe.com/settings/billing/portal)

    ![Stripe Customer Portal](/images/docs/web/billing/stripe/customer-portal.png)

    1. Please make sure to enable the setting that lets users switch plans
    2. Configure the behavior of the cancellation according to your needs
  </Step>
</Steps>

## Add discount

You can add a discount for your customers that will apply on a specific price.

<Steps>
  <Step>
    ### Create coupon

    First, you'd need to create a coupon on the [Coupons page](https://dashboard.stripe.com/coupons).

    ![Stripe Coupons](/images/docs/web/billing/stripe/coupon.png)

    You can set there a details of discount such as prices that it should apply to, amount off, duration, max redemptions and more.
  </Step>

  <Step>
    ### Add promotion code

    To enable using code during checkout you need to get a promotion code. You can define it on the same page as the coupon and give some user-friendly name to it.

    ![Stripe Promotion Code](/images/docs/web/billing/stripe/promotion-code.png)

    This code will be auto-applied at new checkout sessions.

    <Card title="Stripe Discounts" description="docs.stripe.com" href="https://docs.stripe.com/checkout/custom-checkout/add-discounts" />
  </Step>

  <Step>
    ### Configure discount

    You need to add also the discount code and details to TurboStarter billing configuration to enable displaying it in the UI, creating checkout sessions with it and calculate prices.

    [See discounts configuration](/docs/web/billing/configuration#discounts) for more details.
  </Step>
</Steps>

That's it! 🎉 You have now set up Stripe as a billing provider for your app.

Feel free to add more products, prices, discounts and manage your customers data and subscriptions using Stripe.

<Callout type="warn" title="Ensure configuration matches">
  Make sure that the data you set in the configuration matches the details of things you created in Stripe.

  [See configuration](/docs/web/billing/configuration) for more information.
</Callout>


file: ./src/content/docs/web/billing/webhooks.mdx
meta: {
  "title": "Webhooks",
  "description": "Handle webhooks from your billing provider."
}
        
TurboStarter handles billing webhooks to update customer data based on events received from the billing provider.

Occasionally, you may need to set up additional webhooks or perform custom actions with webhooks.

In such cases, you can customize the billing webhook handler in the billing router at `packages/api/src/modules/billing/billing.router.ts`.

By default, the webhook handler is configured to be as straightforward as possible:

```ts title="billing.router.ts"
import { webhookHandler } from "@turbostarter/billing/server";

export const billingRouter = new Hono().post("/webhook", (c) =>
  webhookHandler(c.req.raw),
);
```

However, you can extend it using the callbacks provided from `@turbostarter/billing` package:

```ts title="billing.router.ts"
import { webhookHandler } from "@turbostarter/billing/server";

export const billingRouter = new Hono().post("/webhook", (c) =>
  webhookHandler(c.req.raw, {
    onCheckoutSessionCompleted: (sessionId) => {},
    onSubscriptionCreated: (subscriptionId) => {},
    onSubscriptionUpdated: (subscriptionId) => {},
    onSubscriptionDeleted: (subscriptionId) => {},
  }),
);
```

You can provide one or more of the callbacks to handle the events you are interested in.


file: ./src/content/docs/web/cms/blog.mdx
meta: {
  "title": "Blog",
  "description": "Learn how to manage your blog content."
}
        
TurboStarter comes with a pre-configured blog implementation that allows you to manage your blog content.

## Creating a new blog post

To create a new blog post, you need to create a new directory (its name will be used as the slug of the blog post) with `.mdx` files in the `packages/cms/src/collections/blog/content` directory. Each file in this directory should be named after the locale it belongs to (e.g `en.mdx`, `es.mdx`, etc.).

The file will start with a [frontmatter](https://mdxjs.com/guides/frontmatter/) block, which is a yaml-like block that contains metadata about the post. The frontmatter block should be surrounded by three dashes (`---`).

```mdx title="packages/cms/src/collections/blog/content/my-first-blog-post/en.mdx"
---
title: Quick Tips to Improve Your Skills Right Away
description: Whether you're learning a new technical skill or working on personal development, these quick tips can help you improve right away. Learn how to break down your goals, practice consistently, and track your progress using Markdown.
publishedAt: 2023-04-19
tags: [learning, skills, progress]
thumbnail: https://images.unsplash.com/photo-1483639130939-150975af84e5?q=80&w=2370&auto=format&fit=crop&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D
status: published
---
```

Let's break down the frontmatter fields:

* `title`: The title of the blog post (it will be also used to generate a slug for the blog post)
* `description`: The description of the blog post
* `publishedAt`: The date when the blog post was published
* `tags`: The tags of the blog post
* `thumbnail`: The thumbnail of the blog post
* `status`: The status of the blog post (could be `published` or `draft`)

After the frontmatter block, you can add the content of the blog post:

```mdx title="packages/cms/src/collections/blog/content/my-first-blog-post/en.mdx"
# Quick Tips to Improve Your Skills Right Away

Awesome paragraph!

[Link](https://turbostarter.dev)

<Callout>This is a callout component.</Callout>

...
```

You can consume the content the same as it's described in [Content Collections](/docs/web/cms/content-collections).

## BONUS: Using custom components

As you're using MDX, you can use **any React component** in your blog posts. Just define it as a normal React component and pass it to `<MdxContent />` in `components` prop:

```tsx title="apps/web/src/app/content/page.tsx"
import { MyComponent } from "~/components/my-component";

export default function Page() {
  return (
    <MDXContent
      code={data.body}
      components={{ ...defaultMdxComponents, MyComponent }}
    />
  );
}
```

Then, you would be able to use it in your document content and it will rendered on the page as a result:

```mdx title="packages/cms/src/collections/blog/content/my-first-blog-post/en.mdx"
...

# Heading

Excellent paragraph!

<MyComponent />

1. First item
2. Second item
3. Third item
```

TurboStarter ships with a set of default components that you can use in your blog posts, e.g. `<Callout />`, `<Card />` etc. Use them or define your own to make your blog posts more engaging.


file: ./src/content/docs/web/cms/content-collections.mdx
meta: {
  "title": "Content Collections",
  "description": "Get started with Content Collections."
}
        
By default, TurboStarter uses [Content Collections](https://www.content-collections.dev/) to store and retrieve content from the MDX files.

Content from there is used to populate data in the following places:

* **Blog**
* **Legal pages**
* **Documentation**

<Callout title="Why content-collections?">
  It is a great alternative to headless CMS like Contentful or Prismic based on MDX (a more powerful version of markdown). It is free, open source and the content is located right in your repository.
</Callout>

Of course, you can add more collections and views, as it's very flexible.

## Defining new collection

To define a new collection, you need to create a new file in the `packages/cms/src/collections` directory:

```ts title="packages/cms/src/collections/legal/index.ts"
import { defineCollection } from "@content-collections/core";

export const legal = defineCollection({
  name: "legal",
  directory: "src/collections/legal/content",
  include: "**/*.mdx",
  schema: (z) => ({
    title: z.string(),
    description: z.string(),
  }),
  transform: async (doc, context) => {
    const mdx = await transformMDX(doc, context);

    return {
      ...mdx,
      slug: doc._meta.directory,
      locale: doc._meta.fileName.split(".")[0],
    };
  },
});
```

Then it's passed to the config in `packages/cms/content-collections.ts` file which is used to generate types and parse content from MDX files.

```tsx title="packages/cms/content-collections.ts"
import { defineConfig } from "@content-collections/core";

import { legal } from "./src/collections/legal";

export default defineConfig({
  collections: [legal],
});
```

When you run a development server, content collections will be automatically rebuilt (in `.content-collections` directory) and you will be able to import the content and metadata of each file in your application.

<Callout title="It's fully type-safe!">
  By exporting the generated content you get fully type-safe API to interact
  with the content. We can have type safety on the data that we're receiving
  from the MDX files.
</Callout>

## Using content collections

To get some content from `@turbostarter/cms` package, you need to use the exposed API that we described in the [Overview section](/docs/web/cms/overview#api):

```tsx title="apps/web/src/app/[locale](marketing)/legal/[slug]/page.tsx"
import { content } from "@turbostarter/cms";

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string; locale: string }>;
}) {
  const item = getContentItemBySlug({
    collection: CollectionType.LEGAL,
    slug: (await params).slug,
    locale: (await params).locale,
  });

  return <h1>{title}</h1>;
}
```

Voila! You can now access the content from the MDX files.

<Cards>
  <Card title="Content Collections" description="content-collections.dev" href="https://www.content-collections.dev/" />

  <Card title="MDX" description="mdxjs.com" href="https://mdxjs.com/" />
</Cards>


file: ./src/content/docs/web/cms/overview.mdx
meta: {
  "title": "Overview",
  "description": "Manage your content in TurboStarter.",
  "index": true
}
        
TurboStarter implements a CMS interface that abstracts the implementation from where you store your data. It provides a simple API to interact with your data, and it's easy to extend and customize.

By default, the starter kit ships with these implementations in place:

1. [Content Collections](https://www.content-collections.dev/) - a headless CMS that uses [MDX](https://mdxjs.com/) files to store your content.

The implementation is available under `@turbostarter/cms` package, here we'll go over how to use it.

## API

The CMS package provides a simple, unified API to interact with the content. It's the same for all the providers, so you can easily use it with any of the implementations without changing the code.

### Fetching content items

To fetch items from your colletions, you can use the `getContentItems` function.

```ts
import { getContentItems } from "@turbostarter/cms";

const { items, count } = getContentItems({
  collection: CollectionType.BLOG,
  tags: [ContentTag.SKILLS],
  sortBy: "publishedAt",
  sortOrder: SortOrder.DESCENDING,
  status: ContentStatus.PUBLISHED,
  locale: "en",
});
```

It accepts an object with the following properties:

* `collection`: The collection to fetch the items from.
* `tags`: The tags to filter the items by.
* `sortBy`: The field to sort the items by.
* `sortOrder`: The order to sort the items in.
* `status`: The status of the items to fetch. It can be `published` or `draft`. By default, only `published` items are fetched.
* `locale`: The locale to fetch the items in. By default, all locales are fetched.

### Fetching a single content item

To fetch a single content item, you can use the `getContentItemBySlug` function.

```ts
import { getContentItemBySlug } from "@turbostarter/cms";

const item = getContentItemBySlug({
  collection: CollectionType.BLOG,
  slug: "my-first-blog-post",
  status: ContentStatus.PUBLISHED,
  locale: "en",
});
```

It accepts an object with the following properties:

* `collection`: The collection to fetch the item from.
* `slug`: The slug of the item to fetch.
* `status`: The status of the item to fetch. It can be `published` or `draft`. By default, only `published` items are fetched.
* `locale`: The locale to fetch the item in. By default, all locales are fetched.


file: ./src/content/docs/web/configuration/app.mdx
meta: {
  "title": "App configuration",
  "description": "Learn how to setup the overall settings of your app."
}
        
The application configuration is set at `apps/web/src/config/app.ts`. This configuration stores some overall variables for your application.

This allows you to host multiple apps in the same monorepo, as every application defines its own configuration.

The recommendation is to **not update this directly** - instead, please define the environment variables and override the default behavior. The configuration is strongly typed so you can use it safely accross your codebase - it'll be validated at build time.

```ts title="apps/web/src/config/app.ts"
import { env } from "~/lib/env";

export const appConfig = {
  name: env.NEXT_PUBLIC_PRODUCT_NAME,
  url: env.NEXT_PUBLIC_URL,
  locale: env.NEXT_PUBLIC_DEFAULT_LOCALE,
  theme: {
    mode: env.NEXT_PUBLIC_THEME_MODE,
    color: env.NEXT_PUBLIC_THEME_COLOR,
  },
} as const;
```

For example, to set the product name and default locale, you'd update the following variables:

```dotenv title=".env.local"
NEXT_PUBLIC_PRODUCT_NAME="TurboStarter"
NEXT_PUBLIC_DEFAULT_LOCALE="en"
```

<Callout type="warn" title="Do NOT use process.env!">
  Do NOT use `process.env` to get the values of the variables. Variables
  accessed this way are not validated at build time, and thus the wrong variable
  can be used in production.
</Callout>


file: ./src/content/docs/web/configuration/environment-variables.mdx
meta: {
  "title": "Environment variables",
  "description": "Learn how to configure environment variables."
}
        
Environment variables are defined in the `.env` file in the root of the repository and in the root of the `apps/web` package.

* **Shared environment variables**: Defined in the **root** `.env` file. These are shared between environments (e.g., development, staging, production) and apps (e.g., web, mobile).
* **Environment-specific variables**: Defined in `.env.development` and `.env.production` files. These are specific to the development and production environments.
* **App-specific variables**: Defined in the app-specific directory (e.g., `apps/web`). These are specific to the app and are not shared between apps.
* **Secret keys**: Not stored in the `.env` file. Instead, they are stored in the environment variables of the CI/CD system.
* **Local secret keys**: If you need to use secret keys locally, you can store them in the `.env.local` file. This file is not committed to Git, making it safe for sensitive information.

## Shared variables

Here you can add all the environment variables that are shared across all the apps. This file should be located in the **root** of the project.

To override these variables in a specific environment, please add them to the specific environment file (e.g. `.env.development`, `.env.production`).

```dotenv title=".env.local"
# Shared environment variables

# The database URL is used to connect to your database.
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres"

# The name of the product. This is used in various places across the apps.
PRODUCT_NAME="TurboStarter"

# The url of the web app. Used mostly to link between apps.
URL="http://localhost:3000"

...
```

## App-specific variables

Here you can add all the environment variables that are specific to the app (e.g. `apps/web`).

You can also override the shared variables defined in the root `.env` file.

```dotenv title="apps/web/.env.local"
# App-specific environment variables

# Env variables extracted from shared to be exposed to the client in Next.js app
NEXT_PUBLIC_PRODUCT_NAME="${PRODUCT_NAME}"
NEXT_PUBLIC_URL="${URL}"
NEXT_PUBLIC_DEFAULT_LOCALE="${DEFAULT_LOCALE}"

# Theme mode and color
NEXT_PUBLIC_THEME_MODE="system"
NEXT_PUBLIC_THEME_COLOR="orange"

...
```

<Callout title="NEXT_PUBLIC_ prefix">
  To make environment variables available in the Next.js **client-side** app code, you need to prefix them with `NEXT_PUBLIC_`. They will be injected to the code during the build process.

  Only environment variables prefixed with `NEXT_PUBLIC_` will be injected, so don't use this prefix for environment variables that should be used only in the server-side code.

  [Read more about Next.js environment variables.](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables)
</Callout>

## Secret keys

Secret keys and sensitive information are to be never stored in the `.env` file. Instead, **they are stored in the environment variables of the CI/CD system.**

<Callout title="What does this mean?">
  It means that you will need to add the secret keys to the environment
  variables of your CI/CD system (e.g., GitHub Actions, Vercel, Cloudflare, your
  VPS, Netlify, etc.). This is not a TurboStarter-specific requirement, but a
  best practice for security for any application. Ultimately, it's your choice.
</Callout>

Below is some examples of "what is a secret key?" in practice.

```dotenv title=".env.local"
# Secret keys

# The database URL is used to connect to your database.
DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres"

# Stripe server config - required only if you use Stripe as a billing provider
STRIPE_WEBHOOK_SECRET=""
STRIPE_SECRET_KEY=""

# Lemon Squeezy server config - required only if you use Lemon Squeezy as a billing provider
LEMON_SQUEEZY_API_KEY=""
LEMON_SQUEEZY_SIGNING_SECRET=""
LEMON_SQUEEZY_STORE_ID=""

...
```

<Callout title="Secrets used locally">
  If you need to use secret keys locally, you can store them in the `.env.local`
  file. This file is not committed to Git, therefore it is safe to store
  sensitive information in it.
</Callout>


file: ./src/content/docs/web/configuration/paths.mdx
meta: {
  "title": "Paths configuration",
  "description": "Learn how to configure the paths of your app."
}
        
The paths configuration is set at `apps/web/config/paths.ts`. This configuration stores all the paths that you'll be using in your application. It is a convenient way to store them in a central place rather than scatter them in the codebase using magic strings.

It is **unlikely you'll need to change** this unless you're heavily editing the codebase.

```ts title="apps/web/config/paths.ts"
const pathsConfig = {
  index: "/",
  marketing: {
    pricing: "/pricing",
    contact: "/contact",
    blog: {
      index: BLOG_PREFIX,
      post: (slug: string) => `${BLOG_PREFIX}/${slug}`,
    },
    legal: {
      terms: `${LEGAL_PREFIX}/terms-and-conditions`,
      privacy: `${LEGAL_PREFIX}/privacy-policy`,
      cookies: `${LEGAL_PREFIX}/cookie-policy`,
    },
  },
  auth: {
    login: `${AUTH_PREFIX}/login`,
    register: `${AUTH_PREFIX}/register`,
    forgotPassword: `${AUTH_PREFIX}/password/forgot`,
    updatePassword: `${AUTH_PREFIX}/password/update`,
    error: `${AUTH_PREFIX}/error`,
  },
  dashboard: {
    index: DASHBOARD_PREFIX,
  },
  ...,
} as const;
```

<Callout title="Fully type-safe">
  By declaring the paths as constants, we can use them safely throughout the
  codebase. There is no risk of misspelling or using magic strings.
</Callout>


file: ./src/content/docs/web/customization/add-app.mdx
meta: {
  "title": "Adding apps",
  "description": "Learn how to add apps to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new app to your TurboStarter project within your monorepo and want to keep pulling updates from the TurboStarter repository.
</Callout>

In some ways - creating a new repository may be the easiest way to manage your application. However, if you want to keep your application within the monorepo and pull updates from the TurboStarter repository, you can follow these instructions.

To pull updates into a separate application outside of `web` - we can use [git subtree](https://www.atlassian.com/git/tutorials/git-subtree).

Basically, we will create a subtree at `apps/web` and create a new remote branch for the subtree. When we create a new application, we will pull the subtree into the new application. This allows us to keep it in sync with the `apps/web` folder.

To add a new app to your TurboStarter project, you need to follow these steps:

<Steps>
  <Step>
    ## Create a subtree

    First, we need to create a subtree for the `apps/web` folder. We will create a branch named `web-branch` and create a subtree for the `apps/web` folder.

    ```bash
    git subtree split --prefix=apps/web --branch web-branch
    ```
  </Step>

  <Step>
    ## Create a new app

    Now, we can create a new application in the `apps` folder.

    Let's say we want to create a new app `ai-chat` at `apps/ai-chat` with the same structure as the `apps/web` folder (which acts as the template for all new apps).

    ```bash
    git subtree add --prefix=apps/ai-chat origin web-branch --squash
    ```

    You should now be able to see the `apps/ai-chat` folder with the contents of the `apps/web` folder.
  </Step>

  <Step>
    ## Update the app

    When you want to update the new application, follow these steps:

    ### Pull the latest updates from the TurboStarter repository

    The command below will update all the changes from the TurboStarter repository:

    ```bash
    git pull upstream main
    ```

    ### Push the `web-branch` updates

    After you have pulled the updates from the TurboStarter repository, you can split the branch again and push the updates to the web-branch:

    ```bash
    git subtree split --prefix=apps/web --branch web-branch
    ```

    Now, you can push the updates to the `web-branch`:

    ```bash
    git push origin web-branch
    ```

    ### Pull the updates to the new application

    Now, you can pull the updates to the new application:

    ```bash
    git subtree pull --prefix=apps/ai-chat origin web-branch --squash
    ```
  </Step>
</Steps>

That's it! You now have a new application in the monorepo 🎉


file: ./src/content/docs/web/customization/add-package.mdx
meta: {
  "title": "Adding packages",
  "description": "Learn how to add packages to your Turborepo workspace."
}
        
<Callout title="Advanced topic" type="warn">
  This is an **advanced topic** - you should only follow these instructions if you are sure you want to add a new package to your TurboStarter application instead of adding a folder to your application in `apps/web` or modify existing packages under `packages`. You don't need to do this to add a new page or component to your application.
</Callout>

To add a new package to your TurboStarter application, you need to follow these steps:

<Steps>
  <Step>
    ## Generate a new package

    First, enter the command below to create a new package in your TurboStarter application:

    ```bash
    turbo gen
    ```

    Turborepo will ask you to enter the name of the package you want to create. Enter the name of the package you want to create and press enter.

    If you don't want to add dependencies to your package, you can skip this step by pressing enter.

    The command will have generated a new package under packages named `@turbostarter/<package-name>`. If you named it `example`, the package will be named `@turbostarter/example`.

    Finally, to make fast refresh work when you make changes to the package, you need to add the package to the `next.config.js` file in the root of your TurboStarter application `apps/web`.

    ```ts title="next.config.js"
    const INTERNAL_PACKAGES = [
      // all internal packages,
      "@turbostarter/example",
    ];
    ```
  </Step>

  <Step>
    ## Export a module from your package

    By default, the package exports a single module using the `index.ts` file. You can add more exports by creating new files in the package directory and exporting them from the `index.ts` file or creating export files in the package directory and adding them to the `exports` field in the `package.json` file.

    ### From `index.ts` file

    The easiest way to export a module from a package is to create a new file in the package directory and export it from the `index.ts` file.

    ```ts title="packages/example/src/module.ts"
    export function example() {
      return "example";
    }
    ```

    Then, export the module from the `index.ts` file.

    ```ts title="packages/example/src/index.ts"
    export * from "./module";
    ```

    ### From `exports` field in `package.json`

    **This can be very useful for tree-shaking.** Assuming you have a file named `module.ts` in the package directory, you can export it by adding it to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./module": "./src/module.ts"
      }
    }
    ```

    **When to do this?**

    1. when exporting two modules that don't share dependencies to ensure better tree-shaking. For example, if your exports contains both client and server modules.
    2. for better organization of your package

    For example, create two exports `client` and `server` in the package directory and add them to the `exports` field in the `package.json` file.

    ```json title="packages/example/package.json"
    {
      "exports": {
        ".": "./src/index.ts",
        "./client": "./src/client.ts",
        "./server": "./src/server.ts"
      }
    }
    ```

    1. The `client` module can be imported using `import { client } from '@turbostarter/example/client'`
    2. The `server` module can be imported using `import { server } from '@turbostarter/example/server'`
  </Step>

  <Step>
    ## Use the package in your application

    You can now use the package in your application by importing it using the package name:

    ```ts title="apps/web/src/app/page.tsx"
    import { example } from "@turbostarter/example";

    console.log(example());
    ```
  </Step>
</Steps>

Et voilà! You have successfully added a new package to your TurboStarter application. 🎉


file: ./src/content/docs/web/customization/components.mdx
meta: {
  "title": "Components",
  "description": "Manage and customize your app components."
}
        
For the components part, we're using [shadcn/ui](https://ui.shadcn.com) for atomic, accessible and highly customizable components.

<Callout type="info" title="Why shadcn/ui?">
  shadcn/ui is a powerful tool that allows you to generate pre-designed
  components with a single command. It's built with Tailwind CSS and Radix UI,
  and it's highly customizable.
</Callout>

TurboStarter defines two packages that are responsible for the UI part of your app:

* `@turbostarter/ui` - shared styles, [themes](/docs/web/customization/styling#themes) and assets (e.g. icons)
* `@turbostarter/ui-web` - pre-built UI web components, ready to use in your app

## Adding a new component

There are basically two ways to add a new component:

<Tabs items={["Using the CLI", "Copy-pasting"]}>
  <Tab value="Using the CLI">
    TurboStarter is fully compatible with [shadcn CLI](https://ui.shadcn.com/docs/cli), so you can generate new components with single command.

    Run the following command from the **root** of your project:

    ```bash
    pnpm --filter @turbostarter/ui-web ui:add
    ```

    This will launch an interactive command-line interface to guide you through the process of adding a new component where you can pick which component you want to add.

    ```bash
    Which components would you like to add? > Space to select. A to toggle all.
    Enter to submit.

    ◯  accordion
    ◯  alert
    ◯  alert-dialog
    ◯  aspect-ratio
    ◯  avatar
    ◯  badge
    ◯  button
    ◯  calendar
    ◯  card
    ◯  checkbox
    ```

    Newly created components will appear in the `packages/ui/web/src` directory.
  </Tab>

  <Tab value="Copy-pasting">
    You can always copy-paste a component from the [shadcn/ui](https://ui.shadcn.com/docs/components) website and modify it to your needs.

    This is possible, because the components are headless and don't need (in most cases) any additional dependencies.

    Copy code from the website, create a new file in the `packages/ui/web/src` directory and paste the code into the file.
  </Tab>
</Tabs>

<Callout title="Keep it atomic" type="warn">
  Keep in mind that you should always try to keep shared components as atomic as possible. This will make it easier to reuse them and to build specific views by composition.

  E.g. include components like `Button`, `Input`, `Card`, `Dialog` in shared package, but keep specific components like `LoginForm` in your app directory.
</Callout>

## Using components

Each component is a standalone entity which has a separate export from the package. It helps to keep things modular, avoid unnecessary dependencies and make tree-shaking possible.

To import a component from the UI package, use the following syntax:

```tsx title="components/my-component.tsx"
// [!code word:card]
import {
  Card,
  CardContent,
  CardHeader,
  CardFooter,
  CardTitle,
  CardDescription,
} from "@turbostarter/ui-web/card";
```

Then you can use it to build a component specific to your app:

```tsx title="components/my-component.tsx"
export function MyComponent() {
  return (
    <Card>
      <CardHeader>
        <CardTitle>My Component</CardTitle>
      </CardHeader>
      <CardContent>
        <p>My Component Content</p>
      </CardContent>
      <CardFooter>
        <Button>Click me</Button>
      </CardFooter>
    </Card>
  );
}
```

<Callout title="Recommendation: use v0 to generate layouts">
  We recommend using [v0](https://v0.dev) to generate layouts for your app. It's a powerful tool that allows you to generate layouts from the natural language instructions.

  Of course, **it won't replace a designer**, but it can be a good starting point for your layout.
</Callout>

<Cards>
  <Card href="https://ui.shadcn.com/" title="shadcn/ui" description="ui.shadcn.com" />

  <Card href="https://v0.dev/chat" title="v0 by Vercel" description="v0.dev" />
</Cards>


file: ./src/content/docs/web/customization/styling.mdx
meta: {
  "title": "Styling",
  "description": "Get started with styling your app."
}
        
To build the user web interface TurboStarter comes with [Tailwind CSS](https://tailwindcss.com/) and [Radix UI](https://www.radix-ui.com/) pre-configured.

<Callout title="Why Tailwind CSS and Radix UI?" type="info">
  The combination of Tailwind CSS and Radix UI gives ready-to-use, accessible UI components that can be fully customized to match your brand's design.
</Callout>

## Tailwind configuration

In the `tooling/tailwind/config` directory you will find shared Tailwind CSS configuration files. To change some global styles you can edit the files in this folder.

Here is an example of a shared Tailwind configuration file:

```ts title="tooling/tailwind/config/base.ts"
import type { Config } from "tailwindcss";

export default {
  darkMode: "class",
  content: ["src/**/*.{ts,tsx}"],
  theme: {
    extend: {
      colors: {
        ...
        primary: {
          DEFAULT: "hsl(var(--color-primary))",
          foreground: "hsl(var(--color-primary-foreground))",
        },
        secondary: {
          DEFAULT: "hsl(var(--color-secondary))",
          foreground: "hsl(var(--color-secondary-foreground))",
        },
        success: {
          DEFAULT: "hsl(var(--color-success))",
          foreground: "hsl(var(--color-success-foreground))",
        },
        ...
      },
    },
  },
  plugins: [animate, containerQueries, typography],
} satisfies Config;
```

For the colors part, we bet stricly on [CSS Variables](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) in [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) format to allow for easy theme management without a need for any JavaScript.

Also, each app has its own `tailwind.config.ts` file which extends the shared config and allows you to override the global styles.

Here is an example of an app's `tailwind.config.ts` file:

```ts title="apps/web/tailwind.config.ts"
import type { Config } from "tailwindcss";
import { fontFamily } from "tailwindcss/defaultTheme";

import baseConfig from "@turbostarter/tailwind-config/web";

export default {
  // We need to append the path to the UI package to the content array so that
  // those classes are included correctly.
  content: [
    ...baseConfig.content,
    "../../packages/ui/{shared,web}/src/**/*.{ts,tsx}",
  ],
  presets: [baseConfig],
  theme: {
    extend: {
      fontFamily: {
        sans: ["var(--font-sans)", ...fontFamily.sans],
        mono: ["var(--font-mono)", ...fontFamily.mono],
      },
    },
  },
} satisfies Config;
```

That way we can have a separation of concerns and a clear structure for the Tailwind CSS configuration.

## Themes

TurboStarter comes with **9+** predefined themes which you can use to quickly change the look and feel of your app.

They're defined in `packages/ui/shared/src/styles/themes` directory. Each theme is a set of variables that can be overridden:

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

Each variable is stored as a [HSL](https://en.wikipedia.org/wiki/HSL_and_HSV) array, which is then converted to a CSS variable at build time (by our custom build script). That way we can ensure full type-safety and reuse themes across parts of our apps (e.g. use the same theme in emails).

Feel free to add your own themes or override the existing ones to match your brand's identity.

To apply a theme to your app, you can use the `data-theme` attribute on the `html` element:

```tsx title="apps/web/src/app/layout.tsx"
export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html data-theme="orange">
      <body>{children}</body>
    </html>
  );
}
```

## Dark mode

TurboStarter comes with a built-in dark mode support.

Each theme has a corresponding dark mode variables which are used to change the theme to its dark mode counterpart.

```ts title="packages/ui/shared/src/styles/themes/colors/orange.ts"
export const orange = {
  light: {},
  dark: {
    background: [0, 0, 1],
    foreground: [240, 0.1, 0.039],
    card: [0, 0, 1],
    "card-foreground": [240, 0.1, 0.039],
    ...
  }
} satisfies ThemeColors;
```

As we define the `darkMode` as `class` in the shared Tailwind configuration, we need to add the `dark` class to the `html` element to apply the dark mode styles.

For this purpose we're using [next-themes](https://github.com/pacocoursey/next-themes) package under the hood to handle the user preferences management.

```tsx title="apps/web/src/providers/theme.tsx"
export const ThemeProvider = memo<ThemeProviderProps>(({ children }) => {
  return (
    <NextThemeProvider
      attribute="class"
      defaultTheme={appConfig.theme.mode}
      enableSystem
    >
      {children}
      <ThemeConfigProvider />
    </NextThemeProvider>
  );
});
```

We can define the default theme mode and color in [app configuration](/docs/web/configuration/app).

<Cards>
  <Card title="Tailwind CSS" description="tailwindcss.com" href="https://tailwindcss.com/" />

  <Card title="Radix UI" description="radix-ui.com" href="https://www.radix-ui.com/" />
</Cards>


file: ./src/content/docs/web/database/client.mdx
meta: {
  "title": "Database client",
  "description": "Use database client to interact with the database."
}
        
The database client is an export of the Drizzle client. It is automatically typed by Drizzle based on the schema and is exposed as the db object from the database package (`@turbostarter/db`) in the monorepo.

This guide covers how to initialize the client and also basic operations, such as querying, creating, updating, and deleting records. To learn more about the Drizzle client, check out the [official documentation](https://orm.drizzle.team/kit-docs/overview).

## Initializing the client

Pass the validated `DATABASE_URL` to the client to initialize it.

```ts title="server.ts"
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";

import { env } from "../env";

const client = postgres(env.DATABASE_URL);
export const db = drizzle(client);
```

Now it's exported from the `@turbostarter/db` package and can be used across the codebase (server-side).

## Querying data

To query data, you can use the `db` object and its methods:

```ts title="query.ts"
import { eq } from "@turbostarter/db";
import { db } from "@turbostarter/db/server";
import { customers } from "@turbostarter/db/schema";

export const getCustomerByUserId = async (userId: string) => {
  const [data] = await db
    .select()
    .from(customers)
    .where(eq(customers.userId, userId));

  return data ?? null;
};
```

<Cards className="sm:grid-cols-3">
  <Card title="Select" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/select" />

  <Card title="Filters" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/operators" />

  <Card title="Joins" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/joins" />
</Cards>

## Mutating data

You can use the exported utilities to mutate data. Insert, update or delete records in fast and fully type-safe way:

```ts title="mutation.ts"
import { eq } from "@turbostarter/db";
import { db } from "@turbostarter/db/server";
import { customers } from "@turbostarter/db/schema";

export const upsertCustomer = (data: InsertCustomer) => {
  return db.insert(customers).values(data).onConflictDoUpdate({
    target: customers.userId,
    set: data,
  });
};
```

<Cards className="sm:grid-cols-3">
  <Card title="Insert" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/insert" />

  <Card title="Update" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/update" />

  <Card title="Delete" description="orm.drizzle.team" href="https://orm.drizzle.team/docs/delete" />
</Cards>


file: ./src/content/docs/web/database/migrations.mdx
meta: {
  "title": "Migrations",
  "description": "Migrate your changes to the database."
}
        
You have your schema in place, and you want to apply your changes to the database. TurboStarter provides you a convenient way to do so with pre-configured CLI commands.

## Generating migration

To generate a migration, from the schema you need to run the following command:

```bash
pnpm db:generate
```

This will create a new `.sql` file in the `migrations` directory.

<Callout>
  Drizzle will also generate a `.json` representation of the migration in the `meta` directory, but it's for its internal purposes and you shouldn't need to touch it.
</Callout>

## Applying migrations

To apply the migrations to the database, you need to run the following command:

```bash
pnpm db:migrate
```

This will apply all the migrations that have not been applied yet. If any conflicts arise, you can resolve them by modifying the generated migration file.

## Pushing changes

To push changes directly to the database, you can use the following command:

```bash
pnpm db:push
```

This lets you push your schema changes directly to the database and omit managing SQL migration files.

<Callout type="warn" title="Use with caution!">
  Pushing changes directly to the database (without using migrations) could be risky. Please be careful when using it; we recommend it only for local development and local databases.

  [Read more about it in the Drizzle docs](https://orm.drizzle.team/kit-docs/overview#prototyping-with-db-push).
</Callout>


file: ./src/content/docs/web/database/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with the database.",
  "index": true
}
        
We're using [Drizzle ORM](https://orm.drizzle.team) to interact with the database. It basically adds a little layer of abstraction between our code and the database.

> If you know SQL, you know Drizzle.

For the database we're leveraging [PostgreSQL](https://www.postgresql.org), but you could use any other database that Drizzle ORM supports (basically any SQL database e.g. MySQL, SQLite, etc.).

<Callout title="Why Drizzle ORM?">
  Drizzle ORM is a powerful tool that allows you to interact with the database in a type-safe manner. It ships with 0 (!) dependencies and is designed to be fast and easy to use.
</Callout>

## Setup

To start interacting with the database you first need to ensure that your database instance is up and running.

<Tabs items={["Local development", "Cloud instance"]}>
  <Tab value="Local development">
    For local development we recommend using the [Docker](https://hub.docker.com/_/postgres) container.

    You can start the container with the following command:

    ```bash
    pnpm db:setup
    ```

    This will start the database container and initialize the database with the latest schema.

    **Where is DATABASE\_URL?**

    `DATABASE_URL` is a connection string that is used to connect to the database. When the command will finish it will be displayed in the console and setup to your environment variables.
  </Tab>

  <Tab value="Cloud instance">
    You can also use a cloud instance of database (e.g. [Neon](https://neon.tech/), [Turso](https://turso.tech/), etc.), although it's not recommended for local development.

    **Where is DATABASE\_URL?**

    It's available in your provider's project dashboard. You'll need to copy the connection string from there and add it to your `.env.local` file. The format will look something like:

    * Neon: `postgresql://user:password@ep-xyz-123.region.aws.neon.tech/dbname`
    * Turso: `libsql://your-db-xyz.turso.io`

    Make sure to keep this URL secure and never commit it to version control.
  </Tab>
</Tabs>

Then, you need to set `DATABASE_URL` environment variable in **root** `.env.local` file.

```dotenv title=".env.local"
# The database URL is used to connect to your database.
DATABASE_URL="postgresql://postgres:postgres@127.0.0.1:54322/postgres"
```

You're ready to go! 🥳

## Studio

TurboStarter provides you also with an interactive UI where you can explore your database and test queries called Studio.

To run the Studio, you can use the following command:

```bash
pnpm db:studio
```

This will start the Studio on [https://local.drizzle.studio](https://local.drizzle.studio).

![Drizzle Studio](/images/docs/db-studio.webp)

## Next steps

* [Update schema](/docs/web/database/schema) - learn about schema and how to update it.
* [Generate & run migrations](/docs/web/database/migrations) - migrate your changes to the database.
* [Initialize client](/docs/web/database/client) - initialize the database client and start interacting with the database.


file: ./src/content/docs/web/database/schema.mdx
meta: {
  "title": "Schema",
  "description": "Learn about the database schema."
}
        
Creating a schema for your data is one of the primary tasks when building a new application.

You can find the schema of each table in `packages/db/src/db/schema` directory. The schema is basically organized by entity and each file is a separate table.

## Defining schema

The schema is defined using SQL-like utilities from [drizzle-orm](https://orm.drizzle.team/docs/sql-schema-declaration).

It supports all the SQL features, such as enums, indexes, foreign keys, extensions and more.

<Callout title="Code-first approach">
  We're relying on the code-first approach, where we define the schema in code and then generate the SQL from it. That way we can approach full type-safety and the simplest flow for database updates and migrations.
</Callout>

## Example

Let's take a look at the `customers` table, where we store information about our customers.

```typescript title="customers.ts"
export const customers = pgTable("customers", {
  userId: text("user_id")
    .references(() => users.id, {
      onDelete: "cascade",
    })
    .primaryKey(),
  customerId: text("customer_id").notNull(),
  status: billingStatusEnum("status"),
  plan: pricingPlanTypeEnum("plan"),
  createdAt: timestamp("created_at", { mode: "string" }).notNull().defaultNow(),
  updatedAt: timestamp("updated_at", { mode: "string" })
    .notNull()
    .$onUpdate(() => new Date().toISOString()),
});

export type InsertCustomer = typeof customers.$inferInsert;
export type SelectCustomer = typeof customers.$inferSelect;
```

We're using a few native SQL utilities here, such as:

* `pgTable` - a table definition.
* `timestamp` - a timestamp.
* `text` - a text.
* `uuid` - a unique identifier which is used as a primary key.
* `unique` - a unique constraint.
* `references` - a reference to another table.

What's more, Drizzle gives us the ability to export the TypeScript types for the table, which we can reuse e.g. for the API calls.

Also, we can use the drizzle extension [drizzle-zod](https://orm.drizzle.team/docs/zod) to generate the Zod schemas for the table.

```typescript title="customers.ts"
import { createInsertSchema, createSelectSchema } from "drizzle-zod";

export const insertCustomerSchema = createInsertSchema(customers);
export const selectCustomerSchema = createSelectSchema(customers);
```

Then we can use the generated schemas in our API handlers and frontend forms to validate the data.


file: ./src/content/docs/web/deployment/api.mdx
meta: {
  "title": "Standalone API",
  "description": "Learn how to deploy your API as a dedicated service."
}
        
Sometimes you want to deploy your API as a standalone service. This is useful if you want to deploy your API to a different domain or to deploy it as a microservice. You can also follow this approach if you don't need a web app, but still need API service for [mobile app](/docs/mobile) or [browser extension](/docs/extension).

Deploying your API as a standalone service provides enhanced flexibility and scalability. This allows you to independently scale your API from your web app. It's particularly beneficial for executing "long-running" tasks on your backend, such as report generation, real-time data processing, or background tasks that are likely to timeout in a serverless environment.

This guide explains how to deploy your TurboStarter API as a standalone service. As Hono has multiple deployment options (e.g. [Deno](https://hono.dev/docs/getting-started/deno), [Bun](https://hono.dev/docs/getting-started/bun)), this guide will focus primarily on the [Node.js](https://hono.dev/docs/getting-started/nodejs) deployment.

<Steps>
  <Step>
    ## Create separate API app

    We have a [dedicated guide](/docs/web/customization/add-app) on how to add another app to your project. However, in this case, only a few files need to be added, so we can do it quickly here.

    First, let's create an `api` directory inside the `apps` directory - it will be the root of your API app.

    Next, add the following files into the `apps/api` directory:

    <Tabs items={["package.json", "tsconfig.json", "src/index.ts"]}>
      <Tab value="package.json">
        ```json
        {
          "name": "api",
          "version": "0.1.0",
          "private": true,
          "scripts": {
            "build": "esbuild ./src/index.ts --bundle --platform=node --outfile=dist/index.js",
            "clean": "git clean -xdf dist .turbo node_modules",
            "dev": "dotenv -c -- tsx watch src/index.ts",
            "start": "node dist/index.js",
            "typecheck": "tsc --noEmit"
          },
          "dependencies": {
            "@hono/node-server": "1.13.7",
            "@turbostarter/api": "workspace:*"
          },
          "devDependencies": {
            "@turbostarter/tsconfig": "workspace:*",
            "@types/node": "20.16.10",
            "esbuild": "0.24.2",
            "tsx": "4.19.2",
            "typescript": "catalog:"
          }
        }
        ```
      </Tab>

      <Tab value="tsconfig.json">
        ```json
        {
          "extends": "@turbostarter/tsconfig/base.json",
          "include": ["src"],
          "exclude": ["node_modules"]
        }
        ```
      </Tab>

      <Tab value="src/index.ts">
        ```ts
        import { serve } from "@hono/node-server";
        import { appRouter } from "@turbostarter/api";

        serve(
          {
            fetch: appRouter.fetch,
            port: Number(process.env.PORT) || 3001,
          },
          ({ port }) => {
            console.log(`Server is running on ${port} 🚀`);
          },
        );
        ```
      </Tab>
    </Tabs>

    This will enable you to have a minimal configuration required to run your API as a standalone service. For sure, you can add more configuration (e.g. ESLint or Prettier) if needed, we just want to keep it minimal for the sake of this guide.
  </Step>

  <Step>
    ## Connect web app to API

    The API will be running on a different URL than your web app. For the minimal setup and to avoid handling [cross-origin resource sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) issues, we will rewrite the API URL in the web app.

    To do this, you will need to change your `next.config.js` file to include the API URL rewrite:

    ```js title="apps/web/next.config.js"
    /** @type {import("next").NextConfig} */
    const config = {
      rewrites: async () => [
        {
          source: "/api/:path*",
          destination: `${env.NEXT_PUBLIC_API_URL ?? "http://localhost:3001"}/api/:path*`,
        },
      ],
    };
    ```

    <Callout title="Use environment variable to set API url">
      It's recommended to use an environment variable (e.g. `NEXT_PUBLIC_API_URL`) to set the API URL. This is a good practice to make it easier to change the API URL in different environments (e.g. development, staging, production).
    </Callout>

    Now you should be able to run your API as a standalone service. When you run the project with `pnpm dev`, you will see the new app called `api` with your API server running on [http://localhost:3001](http://localhost:3001).
  </Step>

  <Step>
    ## Deploy!

    You can basically deploy your API as any other Node.js project. We will quickly go through the two most popular options: [PaaS](https://en.wikipedia.org/wiki/Platform_as_a_service) and [Docker](https://www.docker.com/).

    ### Platform as a Service (PaaS)

    PaaS providers like [Vercel](https://vercel.com/), [Heroku](https://www.heroku.com/), or [Netlify](https://www.netlify.com/) allow you to deploy your Node.js app with a few clicks. You can follow our [dedicated guides](/docs/web/deployment/checklist#deploy-web-app-to-production) for the most popular providers. Every process is similar, and will contains a few crucial steps:

    1. Connecting your repository to the PaaS provider
    2. Setting up build settings (e.g. build command, output directory)
    3. Setting up environment variables
    4. Deploying the project

    <Callout title="Ensure correct commands">
      To make sure your API is built and run correctly, you will need to ensure that appropriate commands are correctly set up. In our case, the following commands will need to be configured:

      <Tabs items={["Build command", "Start command"]}>
        <Tab value="Build command">
          ```bash
          pnpm turbo build --filter=api
          ```
        </Tab>

        <Tab value="Start command">
          ```bash
          pnpm --filter=api start
          ```
        </Tab>
      </Tabs>

      This is required to ensure that the PaaS provider of your choice will be able to build and run your application correctly.
    </Callout>

    ### Docker

    Deploying your API as a Docker container is a good option if you want to have more control over the deployment process. You can follow our [dedicated guide](/docs/web/deployment/docker) to learn how to deploy your API as a Docker container.

    For the API application, the `Dockerfile` will be located in the `apps/api` directory and it could look like this:

    ```dockerfile title="apps/api/Dockerfile"
    FROM node:20-alpine AS base
    ENV PNPM_HOME="/pnpm"
    ENV PATH="$PNPM_HOME:$PATH"
    RUN corepack enable

    FROM base AS pruner
    WORKDIR /app
    RUN apk add --no-cache libc6-compat
    COPY . .
    RUN pnpm dlx turbo prune api --docker

    FROM base AS builder
    WORKDIR /app
    RUN apk add --no-cache libc6-compat
    COPY --from=pruner /app/out/json/ .
    COPY --from=pruner /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
    RUN pnpm install --frozen-lockfile --ignore-scripts --prefer-offline && pnpm store prune
    ENV SKIP_ENV_VALIDATION=1 \
        NODE_ENV=production
    COPY --from=pruner /app/out/full/ .
    RUN pnpm dlx turbo build --filter=api

    FROM base AS runner
    WORKDIR /app
    RUN addgroup -g 1001 -S nodejs && \
        adduser -S api -u 1001 -G nodejs
    COPY --from=builder --chown=api:nodejs /app/apps/api/dist/ ./
    USER api
    EXPOSE 3001
    CMD ["node", "index.js"]
    ```

    To test if everything works correctly, you can run a [container](https://docs.docker.com/get-started/03_run_your_app/) locally with the following commands:

    ```bash
    docker build -f ./apps/api/Dockerfile . -t turbostarter-api
    docker run -p 3001:3001 turbostarter-api
    ```

    Make sure to also [pass](https://docs.docker.com/reference/cli/docker/container/run/#env) all the required environment variables to the container, so your API can start without any issues.

    Deploying your API as a Docker container is a great way to isolate your API from the host environment, making it easier to deploy and scale. It also simplifies the workflow if you're working with a team, as you can easily share the Docker image with your colleagues and they will run the API in the **exact same** environment.
  </Step>
</Steps>

That's it! You can now grow your API layer as a standalone service, separated from other apps in your project, and deploy it anywhere you want.


file: ./src/content/docs/web/deployment/checklist.mdx
meta: {
  "title": "Checklist",
  "description": "Let's deploy your TurboStarter app to production!"
}
        
When you're ready to deploy your project to production, follow this checklist.

This process may take a few hours and some trial and error, so buckle up — you're almost there!

<Steps>
  <Step>
    ## Create database instance

    **Why it's necessary?**

    A production-ready database instance is essential for storing your application's data securely and reliably in the cloud. [PostgreSQL](https://www.postgresql.org/) is the recommended database for TurboStarter due to its robustness, features, and wide support.

    **How to do it?**

    You have several options for hosting your PostgreSQL database:

    * [Supabase](https://supabase.com/) - Provides a fully managed Postgres database with additional features
    * [Vercel Postgres](https://vercel.com/storage/postgres) - Serverless SQL database optimized for Vercel deployments
    * [Neon](https://neon.tech/) - Serverless Postgres with automatic scaling
    * [Turso](https://turso.tech/) - Edge database built on libSQL with global replication
    * [DigitalOcean](https://www.digitalocean.com/products/managed-databases) - Managed database clusters with automated failover

    Choose a provider based on your needs for:

    * Pricing and budget
    * Geographic region availability
    * Scaling requirements
    * Additional features (backups, monitoring, etc.)
  </Step>

  <Step>
    ## Migrate database

    **Why it's necessary?**

    Pushing database migrations ensures that your database schema in the remote database instance is configured to match TurboStarter's requirements. This step is crucial for the application to function correctly.

    **How to do it?**

    You basically have two possibilities of doing a migration:

    <Tabs items={["Using Github Actions (recommended)", "Running locally"]}>
      <Tab value="Using Github Actions (recommended)">
        TurboStarter comes with predefined Github Actions workflow to handle database migrations. You can find its definition in the `.github/workflows/publish-db.yml` file.

        What you need to do is to set your `DATABASE_URL` as a [secret for your Github repository](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions).

        Then, you can run the workflow which will publish the database schema to your remote database instance.

        [Check how to run Github Actions workflow.](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow)
      </Tab>

      <Tab value="Running locally">
        You can also run your migrations locally, although this is not recommended for production.

        To do so, set the `DATABASE_URL` environment variable to your database URL (that comes from your database provider) in `.env.local` file and run the following command:

        ```bash
        pnpm db:migrate
        ```

        This command will run the migrations and apply them to your remote database.

        [Learn more about database migrations.](/docs/web/database/migrations)
      </Tab>
    </Tabs>
  </Step>

  <Step>
    ## Configure OAuth Providers

    **Why it's necessary?**

    Configuring OAuth providers like [Google](https://www.better-auth.com/docs/authentication/google) or [Github](https://www.better-auth.com/docs/authentication/github) ensures that users can log in using their existing accounts, enhancing user convenience and security. This step involves setting up the OAuth credentials in the provider's developer console, configuring the necessary environment variables, and setting up callback URLs to point to your production app.

    **How to do it?**

    1. Follow the provider-specific guides to set up OAuth credentials for the providers you want to use. For example:
       * [Google OAuth setup guide](https://www.better-auth.com/docs/authentication/google)
       * [Github OAuth setup guide](https://www.better-auth.com/docs/authentication/github)
    2. Once you have the credentials, set the corresponding environment variables in your project. For the example providers above:
       * For Google: `GOOGLE_CLIENT_ID` and `GOOGLE_CLIENT_SECRET`
       * For Github: `GITHUB_CLIENT_ID` and `GITHUB_CLIENT_SECRET`
    3. Ensure that the callback URLs for each provider are set to point to your production app. **This is crucial for the OAuth flow to work correctly.**

    You can add or remove OAuth providers based on your needs. Just make sure to follow the provider's setup guide, set the required environment variables, and configure the callback URLs correctly.
  </Step>

  <Step>
    ## Setup billing provider

    **Why it's necessary?**

    Well - you want to get paid, right? Setting up billing ensures that you can charge your users for using your SaaS application, enabling you to monetize your service and cover operational costs.

    **How to do it?**

    * Create a [Stripe](/docs/web/billing/stripe) or [Lemon Squeezy](/docs/web/billing/lemon-squeezy) account.
    * Update the environment variables with the correct values for your billing service.
    * Point webhooks from Stripe or Lemon Squeezy to `/api/billing/webhook`.
    * Refer to the [relevant documentation](/docs/web/billing/overview) for more details on setting up billing.
  </Step>

  <Step>
    ## Setup emails provider

    **Why it's necessary?**

    Setting up an email provider is crucial for your SaaS application to send notifications, confirmations, and other important messages to your users. This enhances user experience and engagement, and is a standard practice in modern web applications.

    **How to do it?**

    * Create an account with an email service provider of your choice. See [available providers](/docs/web/emails/configuration#providers) for more information.
    * Update the environment variables with the correct values for your email service.
    * Refer to the [relevant documentation](/docs/web/emails/overview) for more details on setting up email.
  </Step>

  <Step>
    ## Environment variables

    **Why it's necessary?**

    Setting the correct environment variables is essential for the application to function correctly. These variables include API keys, database URLs, and other configuration details required for your app to connect to various services.

    **How to do it?**

    Use our `.env.example` files to get the correct environment variables for your project. Then add them to your **hosting provider's environment variables**. Redeploy the app once you have the URL to set in the environment variables.
  </Step>

  <Step>
    ## Deploy web app to production

    **Why it's necessary?**

    Because your users are waiting! Deploying your Next.js app to a hosting provider makes it accessible to users worldwide, allowing them to interact with your application.

    **How to do it?**

    Deploy your Next.js app to chosen hosting provider. **Copy the deployment URL and set it as an environment variable in your project's settings.** Feel free to check out our dedicated guides for the most popular hosting providers:

    <Cards>
      <Card title="Vercel" description="Deploy your TurboStarter web app to Vercel platform." href="/docs/web/deployment/vercel" />

      {/* <Card title="Cloudflare" description="Deploy your TurboStarter web app to Cloudflare platform." href="/docs/web/deployment/cloudflare" /> */}

      <Card title="Netlify" description="Deploy your TurboStarter web app to Netlify platform." href="/docs/web/deployment/netlify" />

      <Card title="Render" description="Deploy your TurboStarter web app to Render platform." href="/docs/web/deployment/render" />

      <Card title="Railway" description="Deploy your TurboStarter web app to Railway platform." href="/docs/web/deployment/railway" />

      <Card title="Docker" description="Containerize your TurboStarter web app using Docker." href="/docs/web/deployment/docker" />

      <Card title="Fly.io" description="Deploy your TurboStarter web app to Fly.io platform." href="/docs/web/deployment/fly" />
    </Cards>

    We also have a dedicated guide for [deploying your API as a standalone service](/docs/web/deployment/api).
  </Step>
</Steps>

That's it! Your app is now live and accessible to your users, good job! 🎉

<Callout title="Other things to consider">
  * Update the legal pages with your company's information (privacy policy, terms of service, etc.).
  * Remove the placeholder blog and documentation content / or replace it with your own.
  * Customize authentication emails and other email templates.
  * Update the favicon and logo with your own branding.
  * Update the FAQ and other static content with your own information.
</Callout>


file: ./src/content/docs/web/deployment/cloudflare.mdx
meta: {
  "title": "Cloudflare",
  "description": "Learn how to deploy your TurboStarter app to Cloudflare."
}
        
[Cloudflare](https://cloudflare.com) is a versatile platform offering powerful tools for deploying and optimizing web applications. With features like serverless computing, security, and performance optimization, it ensures fast and reliable app delivery.

This guide walks you through deploying your TurboStarter app on Cloudflare. You'll learn to set up your project, configure deployment settings, and manage environment variables to leverage Cloudflare's capabilities for a seamless and efficient deployment experience.


file: ./src/content/docs/web/deployment/docker.mdx
meta: {
  "title": "Docker",
  "description": "Learn how to containerize your TurboStarter app with Docker."
}
        
[Docker](https://docker.com) is a popular platform for containerizing applications, making it easy to package your app with all its dependencies for consistent performance across environments. It simplifies development, testing, and deployment.

This guide explains how to containerize your TurboStarter app using Docker. You'll learn to create a Dockerfile, build a container image, and run your app in a container for a reliable and portable setup.

<Steps>
  <Step>
    ## Configure Next.js for Docker

    First of all, we need to configure Next.js to output the build files in the [standalone format](https://nextjs.org/docs/pages/api-reference/config/next-config-js/output) - it's required for the Docker image to work. To do this, we need to add the following to our `next.config.js` file:

    ```js title="apps/web/next.config.js"
    /** @type {import("next").NextConfig} */
    const config = {
      output: "standalone",

      ...
    };
    ```
  </Step>

  <Step>
    ## Create a Dockerfile

    [Dockerfile](https://docs.docker.com/get-started/02_our_app/) is a text file that contains the instructions for building a [Docker image](https://docs.docker.com/get-started/02_our_app/). It defines the environment, dependencies, and commands needed to run your app. You can safely copy the following Dockerfile to your project:

    ```dockerfile title="apps/web/Dockerfile"
    FROM node:20-alpine AS base
    ENV PNPM_HOME="/pnpm"
    ENV PATH="$PNPM_HOME:$PATH"
    RUN corepack enable

    FROM base AS pruner
    WORKDIR /app
    RUN apk add --no-cache libc6-compat
    COPY . .
    RUN pnpm dlx turbo prune web --docker

    FROM base AS builder
    WORKDIR /app
    RUN apk add --no-cache libc6-compat
    COPY --from=pruner /app/out/json/ .
    COPY --from=pruner /app/out/pnpm-lock.yaml ./pnpm-lock.yaml
    RUN pnpm install --frozen-lockfile --ignore-scripts --prefer-offline && pnpm store prune
    ENV SKIP_ENV_VALIDATION=1 \
        NODE_ENV=production
    COPY --from=pruner /app/out/full/ .
    RUN pnpm dlx turbo build --filter=web

    FROM base AS runner
    WORKDIR /app
    RUN addgroup -g 1001 -S nodejs && \
        adduser -S web -u 1001 -G nodejs
    COPY --from=builder --chown=web:nodejs /app/apps/web/.next/standalone ./
    COPY --from=builder --chown=web:nodejs /app/apps/web/.next/static ./apps/web/.next/static
    COPY --from=builder --chown=web:nodejs /app/apps/web/public ./apps/web/public
    USER web
    EXPOSE 3000
    CMD ["node", "apps/web/server.js"]
    ```

    Feel free to check out our [self-hosting guide](/blog/self-host-your-nextjs-turborepo-app-with-docker-in-5-minutes) for more details on how each stage of the Dockerfile works.

    And that's all we need! You can now build and run your Docker image to deploy your app anywhere you want in an [isolated environment](https://docs.docker.com/get-started/03_run_your_app/).
  </Step>

  <Step>
    ## Run a container

    To test if everything works correctly, you can run a [container](https://docs.docker.com/get-started/03_run_your_app/) locally with the following commands:

    ```bash
    docker build -f ./apps/web/Dockerfile . -t turbostarter
    docker run -p 3000:3000 turbostarter
    ```

    Make sure to also [pass](https://docs.docker.com/reference/cli/docker/container/run/#env) all the required environment variables to the container, so your app can start without any issues.

    If everything works correctly, you should be able to access your app at [http://localhost:3000](http://localhost:3000).
  </Step>
</Steps>

That's it! You can now build and deploy your app as a Docker container to any supported hosting (e.g. [Fly.io](/docs/web/deployment/fly)).

Using Docker containers is a great way to isolate your app from the host environment, making it easier to deploy and scale. It also simplifies the workflow if you're working with a team, as you can easily share the Docker image with your colleagues and they will run the app in the **exact same** environment.


file: ./src/content/docs/web/deployment/fly.mdx
meta: {
  "title": "Fly.io",
  "description": "Learn how to deploy your TurboStarter app to Fly.io."
}
        
[Fly.io](https://fly.io) makes deploying web applications to the cloud easy and efficient. It handles scaling, monitoring, and logging so you can focus on building your app.

This guide explains how to deploy your TurboStarter app on Fly.io. You'll learn how to leverage [Docker](/docs/web/deployment/docker) containers to deploy your app, set up builds, and manage environment variables for a smooth and reliable deployment.

<Callout type="warn" title="Prerequisite: Fly account and Docker configured">
  To deploy to Fly.io, you need to have an account. You can create one [here](https://fly.io/app/signup).

  You also need to have [Docker](/docs/web/deployment/docker) configured in your project.
</Callout>

<Steps>
  <Step>
    ## Setup Fly CLI

    As we will be using Fly CLI to launch and manage our app, you need to install and setup it on your machine.

    [Check the official documentation on how to install Fly CLI](https://fly.io/docs/flyctl/install/).

    After you've installed Fly CLI, you need to login to your Fly account and connect it with your machine:

    ```bash
    fly auth login
    ```

    [Read more about authenticating CLI](https://fly.io/docs/flyctl/auth/#available-commands).

    Now you're ready to launch your app!
  </Step>

  <Step>
    ## Launch project

    Use a [Dockerfile](/docs/web/deployment/docker) to launch your app with [Fly CLI](https://fly.io/docs/reference/flyctl/). You can use the following command to do this from your local machine:

    ```bash
    fly launch --dockerfile apps/web/Dockerfile
    ```

    Make sure to set all the required configuration in the CLI steps (e.g. set port to `3000`, setup additional services, choose billing plan, etc.).

    ![Fly launch](/images/docs/web/deployment/fly/launch.png)

    <Callout title="Customize region for better performance">
      If you want to achieve better performance and lower latency in your API requests, you can customize the region of your Render service. Make sure to set it to the region closest to your database and users.
    </Callout>

    After the launch is complete, Fly will output your project configuration into `fly.toml` file. The configuration of your project is stored there, feel free to customize it to your needs:

    ```toml title="fly.toml"
    app = 'web-aged-sky-5596'
    primary_region = 'ams'

    [build]
      dockerfile = 'apps/web/Dockerfile'

    [http_service]
      internal_port = 3000
      force_https = true
      auto_stop_machines = 'stop'
      auto_start_machines = true
      min_machines_running = 0
      processes = ['app']

    [[vm]]
      memory = '512mb'
      cpu_kind = 'shared'
      cpus = 1
    ```

    See [Fly.io documentation](https://fly.io/docs/reference/configuration) for more information on how to use this file.
  </Step>

  <Step>
    ## Set up secrets

    To make your app fully functional, you need to set up required environment variables. You can do this by running the following command:

    ```bash
    fly secrets set --app <your-app-name> DATABASE_URL=...
    ```

    They will be automatically added to your app's runtime environment.
  </Step>

  <Step>
    ## Deploy!

    Each time you make changes to `fly.toml` or secrets, you need to re-deploy your app to apply changes to the running app.

    To do this, just run the following command in your project directory:

    ```bash
    fly deploy
    ```

    This will build your app and deploy it to Fly.io with the latest code version.

    ![Fly deploy](/images/docs/web/deployment/fly/deploy.png)

    That's it! Your app is now deployed to Fly.io, congratulations! 🎉
  </Step>
</Steps>

Fly is a platform that allows you to deploy and manage applications in the cloud. It provides a simple and intuitive way to deploy your app, with features such as automatic scaling, load balancing, and rolling updates. With Fly, you can focus on building your app without worrying about the underlying infrastructure.


file: ./src/content/docs/web/deployment/netlify.mdx
meta: {
  "title": "Netlify",
  "description": "Learn how to deploy your TurboStarter app to Netlify."
}
        
[Netlify](https://netlify.com) is a powerful platform for deploying modern web applications. It offers continuous deployment, serverless functions, and a global CDN to ensure your application is fast and reliable.

In this guide, we will walk through the steps to deploy your TurboStarter app to Netlify. You will learn how to connect your repository, configure build settings, and manage environment variables to ensure a smooth deployment process.

<Callout type="warn" title="Prerequisite: Netlify account">
  To deploy to Netlify, you need to have an account. You can create one [here](https://netlify.com/signup).
</Callout>

<Steps>
  <Step>
    ## Create new site

    Once you've created your account and logged in, the Netlify dashboard will display an option to add a new site. Click on the *Import from Git* button to begin connecting your Git repository.

    ![Create new site](/images/docs/web/deployment/netlify/create-site.png)

    If you've already had a Netlify account, you can get to this step by clicking on the *Sites* tab in the navigation menu.
  </Step>

  <Step>
    ## Connect your repository

    Choose the Git provider of your project and select the repository you want to deploy.

    ![Connect repository](/images/docs/web/deployment/netlify/connect-repository.png)

    <Callout title="Authorization needed">
      To connect your repository, you need to authorize Netlify to access it. It's recommended to follow a *least privileged access* approach, so to only grant access to the repository you want to deploy, not the entire account.
    </Callout>
  </Step>

  <Step>
    ## Configure build settings

    Last step before deploying! Configure the build settings according to your project configuration. Use the screenshots provided below for reference to ensure a smooth deployment process.

    ![Netlify build settings](/images/docs/web/deployment/netlify/build-settings.png)

    Also, add all environment variables under *Environment variables* section - it's required to make the build process work.
  </Step>

  <Step>
    ## Deploy!

    Click on the *Deploy* button to start the deployment process.

    ![Netlify deploy](/images/docs/web/deployment/netlify/deploy.png)

    That's it! Your app is now deployed to Netlify, congratulations! 🎉
  </Step>
</Steps>

<Callout title="Customize region for better performance">
  If you want to achieve better performance and lower latency in your API requests, you can customize the region of your Netlify serverless functions. Make sure to set it to the region closest to your database and users.

  ![Netlify region](/images/docs/web/deployment/netlify/region.png)

  Unfortunately, it's a paid feature, so you need to upgrade your Netlify account to be able to change it.
</Callout>


file: ./src/content/docs/web/deployment/railway.mdx
meta: {
  "title": "Railway",
  "description": "Learn how to deploy your TurboStarter app to Railway."
}
        
[Railway](https://railway.app) is a platform that allows you to deploy your web applications to a cloud environment. It provides a simple and efficient way to manage your application's infrastructure, including scaling, monitoring, and logging.

This guide provides a step-by-step walkthrough for deploying your TurboStarter app on Railway, and taking advantage of its features in production environment. You'll discover how to link your repository, tailor build settings, and oversee environment variables, ensuring a smooth and optimized deployment process that leverages Railway's capabilities.

<Callout type="warn" title="Prerequisite: Railway account">
  To deploy to Railway, you need to have an account. You can create one [here](https://railway.app/signup).
</Callout>

<Steps>
  <Step>
    ## Create new project

    We'll use [Railway](https://railway.app) web app to deploy our project. First, let's create a new project.

    ![Railway create project](/images/docs/web/deployment/railway/create-project.png)

    Proceed with the option to *Deploy from Github repo*.
  </Step>

  <Step>
    ## Connect repository

    Choose the Git provider of your project and select the repository you want to deploy.

    ![Connect repository](/images/docs/web/deployment/railway/connect-repository.png)

    <Callout title="Authorization needed">
      If your repository is private you need to authorize Railway to access it. It's recommended to follow a *least privileged access* approach, so to only grant access to the repository you want to deploy, not the entire account.
    </Callout>
  </Step>

  <Step>
    ## Configure project settings

    Finalize your deployment by configuring the build settings to match your project's specific needs. Refer to the points below to ensure a seamless deployment process.

    ### Commands

    Configure the build and start commands to ensure that your project is built and started correctly.

    ![Railway project commands](/images/docs/web/deployment/railway/commands.png)

    Make sure to set them to the following values:

    * **Build command** - `pnpm dlx turbo build --filter=web`
    * **Start command** - `pnpm --filter=web start`

    ### Environment variables

    Last, but not least, you need to set the environment variables for your project. Make sure to check if all the required variables are set.

    ![Railway environment variables](/images/docs/web/deployment/railway/environment-variables.png)

    <Callout title="Customize region for better performance and reliability">
      If you want to achieve better performance, lower latency in your API requests or add some replicas of your application, you can customize the region of your Railway instance. Make sure to set it to the region closest to your database and users.

      ![Railway region](/images/docs/web/deployment/railway/region.png)
    </Callout>

    You can also use a [Railway config file](https://docs.railway.com/guides/config-as-code) to manage your project's settings in one place, as a code.
  </Step>

  <Step>
    ## Deploy!

    Click on the *Deploy* button to start the deployment process.

    ![Railway deploy](/images/docs/web/deployment/railway/deploy.png)

    That's it! Your app is now deployed to Railway, congratulations! 🎉
  </Step>
</Steps>

Feel free to scale your deployment to multiple regions or isolate it in the separate network. Check out the [Railway documentation](https://docs.railway.app) for more information about which services are available.


file: ./src/content/docs/web/deployment/render.mdx
meta: {
  "title": "Render",
  "description": "Learn how to deploy your TurboStarter app to Render."
}
        
[Render](https://render.com) offers a unique combination of features that make it an ideal platform for deploying modern web applications. With Render, you can leverage continuous deployment, managed databases, and a global CDN to ensure your application is not only fast and reliable but also scalable and secure.

In this guide, we will walk through the steps to deploy your TurboStarter app to Render, highlighting the benefits of using Render's platform. You will learn how to connect your repository, configure build settings, and manage environment variables to ensure a seamless and efficient deployment process that takes advantage of Render's features.

<Callout type="warn" title="Prerequisite: Render account">
  To deploy to Render, you need to have an account. You can create one [here](https://render.com/signup).
</Callout>

<Steps>
  <Step>
    ## Create a new service

    Navigate to the [Render dashboard](https://dashboard.render.com) and click on the *New* button.

    ![Create new service](/images/docs/web/deployment/render/create-service.png)

    Pick the *Web Service* option and proceed to the next step.
  </Step>

  <Step>
    ## Connect your repository

    Choose the Git provider of your project and select the repository you want to deploy.

    ![Connect repository](/images/docs/web/deployment/render/connect-repository.png)

    <Callout title="Authorization needed">
      If your repository is private you need to authorize Render to access it. It's recommended to follow a *least privileged access* approach, so to only grant access to the repository you want to deploy, not the entire account.
    </Callout>
  </Step>

  <Step>
    ## Configure service settings

    Finalize your deployment by configuring the build settings to match your project's specific needs. Refer to the screenshots below to ensure a seamless deployment process.

    ![Render service settings](/images/docs/web/deployment/render/general-settings.png)

    You can also group your service with other services (e.g. [databases](https://render.com/docs/postgresql-creating-connecting) or [cron jobs](https://render.com/docs/cronjobs)) in a [Project](https://render.com/docs/projects), which will help you manage them together.

    [Read official documentation for more information](https://render.com/docs/projects).

    <Callout title="Customize region for better performance">
      If you want to achieve better performance and lower latency in your API requests, you can customize the region of your Render service. Make sure to set it to the region closest to your database and users.
    </Callout>

    ### Commands

    Configure the build and start commands to ensure that your project is built and started correctly.

    ![Render service commands](/images/docs/web/deployment/render/commands.png)

    Make sure to set them to the following values:

    * **Build command** - `pnpm install --frozen-lockfile; pnpm dlx turbo build --filter=web`
    * **Start command** - `pnpm --filter=web start`

    ### Instance type

    Select a plan that fits your project's needs.

    ![Render instance type](/images/docs/web/deployment/render/instance-type.png)

    For testing purposes or MVPs, you can safely use the *Free* plan. Although, for the production version, it's recommended to upgrade your plan, as it offers more resources and your project won't be paused after periods of inactivity.

    ### Environment variables

    Last, but not least, you need to set the environment variables for your project. Make sure to check if all the required variables are set.

    ![Render environment variables](/images/docs/web/deployment/render/environment-variables.png)

    You can also modify *Advanced settings* to set e.g. [health checks](https://render.com/docs/deploys#health-checks) or modify [auto deploy](https://render.com/docs/deploys#automatic-git-deploys) triggers.
  </Step>

  <Step>
    ## Deploy!

    Click on the *Deploy Web Service* button to start the deployment process.

    ![Render deploy](/images/docs/web/deployment/render/deploy.png)

    That's it! Your app is now deployed to Render, congratulations! 🎉
  </Step>
</Steps>

Render is a powerful platform with a lot of integrations and features. Feel free to check out the [official documentation](https://render.com/docs) for more information.


file: ./src/content/docs/web/deployment/vercel.mdx
meta: {
  "title": "Vercel",
  "description": "Learn how to deploy your TurboStarter app to Vercel."
}
        
In general you can deploy the application to any hosting provider that supports Node.js, but we recommend using [Vercel](https://vercel.com) for the best experience.

Vercel is the easiest way to deploy Next.js apps. It's the company behind Next.js and has first-class support for Next.js.

<Callout type="warn" title="Prerequisite: Vercel account">
  To deploy to Vercel, you need to have an account. You can create one [here](https://vercel.com/signup).
</Callout>

TurboStarter has two, separate ways to deploy to Vercel, each ships with **one-click deployment**. Choose the one that best fits your needs.

<Tabs items={["Connecting repository", "Github Actions"]}>
  <Tab value="Connecting repository">
    Deploying with this method is the easiest and fastest way to get your app up and running on the cloud provider. Follow these steps:

    <Steps>
      <Step>
        ## Connect your git repository

        After signing up you will be promted to import a git repository. Select the git provider of your project and connect your git account with Vercel.

        ![Vercel import project](/images/docs/web/deployment/vercel/connect-repository.webp)
      </Step>

      <Step>
        ## Configure project settings

        As we're working in monorepo, some additional settings are required to make the build process work.

        Make sure to set the following settings:

        * **Build command**: `pnpm turbo build --filter=web` - to build only the web app
        * **Root directory**: `apps/web` - to make sure Vercel uses the web folder as the root directory (make sure to check *Include files outside the root directory in the Build Step* option, it will ensure that all packages from your monorepo are included in the build process)

        ![Vercel project settings](/images/docs/web/deployment/vercel/project-settings.png)

        <Cards>
          <Card title="Build and development settings" description="vercel.com" href="https://vercel.com/docs/deployments/configure-a-build#build-and-development-settings" />

          <Card title="Root directory" description="vercel.com" href="https://vercel.com/docs/deployments/configure-a-build#root-directory" />
        </Cards>
      </Step>

      <Step>
        ## Configure environment variables

        Please make sure to set all the environment variables required for the project to work correctly. You can find the list of required environment variables in the `.env.example` file in the `apps/web` directory.

        The environment variables can be set in the Vercel dashboard under *Project Settings* > *Environment Variables*. Make sure to set them for all environments (Production, Preview, and Development) as needed.

        **Failure to set the environment variables will result in the project not working correctly.**

        If the build fails, deep dive into the logs to see what is the issue. Our Zod configuration will validate and report any missing environment variables. To find out which environment variables are missing, please check the logs.

        <Callout title="First deployment may fail">
          The first time this may fail if you don't yet have a custom domain connected since you cannot place it in the environment variables yet. It's fine. Make the first deployment fail, then pick the domain and add it. Redeploy.
        </Callout>
      </Step>

      <Step>
        ## Deploy!

        Click on the *Deploy* button to start the deployment process.

        ![Vercel deploy](/images/docs/web/deployment/vercel/success.png)

        That's it! Your app is now deployed to Vercel, congratulations! 🎉
      </Step>
    </Steps>
  </Tab>

  <Tab value="Github Actions">
    Despite connecting your repository is the easiest way to deploy to Vercel, we recommend using preconfigured Github Actions for the most granular control over your deployments.

    We'll leverage [Vercel CLI](https://vercel.com/docs/cli) to deploy the application on the CI/CD pipeline. [See official documentation on deploying to Github Actions](https://vercel.com/guides/how-can-i-use-github-actions-with-vercel).

    <Steps>
      <Step>
        ## Get Vercel Access Token

        To deploy the application, we need to get Vercel access token.

        Please, follow [this guide](https://vercel.com/guides/how-do-i-use-a-vercel-api-access-token) to create one.

        ![Vercel access token](/images/docs/web/deployment/vercel/access-token.avif)
      </Step>

      <Step>
        ## Install Vercel CLI

        We need to install [Vercel CLI](https://vercel.com/docs/cli) locally to be able to get required credentials for our Github Actions.

        You can install it using following command:

        ```bash
        pnpm i -g vercel
        ```

        Then, login to Vercel using following command:

        ```bash
        vercel login
        ```
      </Step>

      <Step>
        ## Get credentials

        Inside your folder, run following command to create a new project:

        ```bash
        vercel link
        ```

        This will generate a `.vercel` folder, where you can find `project.json` file with `projectId` and `orgId`.
      </Step>

      <Step>
        ## Configure Github Actions

        Inside GitHub, add `VERCEL_TOKEN`, `VERCEL_ORG_ID`, and `VERCEL_PROJECT_ID` as [secrets](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions) to your repository.

        ![Github secrets](/images/docs/web/deployment/vercel/github-tokens.png)

        This will allow Github Actions to access your settings and deploy the application to Vercel.
      </Step>

      <Step>
        ## Configure project settings

        As we're working in monorepo, some additional settings are required to make the build process work.

        Make sure to set the following settings:

        * **Build command**: `pnpm turbo build --filter=web` - to build only the web app
        * **Root directory**: `apps/web` - to make sure Vercel uses the web folder as the root directory (make sure to check *Include files outside the root directory in the Build Step* option, it will ensure that all packages from your monorepo are included in the build process)

        ![Vercel project settings](/images/docs/web/deployment/vercel/project-settings.png)

        <Cards>
          <Card title="Build and development settings" description="vercel.com" href="https://vercel.com/docs/deployments/configure-a-build#build-and-development-settings" />

          <Card title="Root directory" description="vercel.com" href="https://vercel.com/docs/deployments/configure-a-build#root-directory" />
        </Cards>
      </Step>

      <Step>
        ## Configure environment variables

        Please make sure to set all the environment variables required for the project to work correctly. You can find the list of required environment variables in the `.env.example` file in the `apps/web` directory.

        The environment variables can be set in the Vercel dashboard under *Project Settings* > *Environment Variables*. Make sure to set them for all environments (Production, Preview, and Development) as needed.

        **Failure to set the environment variables will result in the project not working correctly.**

        If the build fails, deep dive into the logs to see what is the issue. Our Zod configuration will validate and report any missing environment variables. To find out which environment variables are missing, please check the logs.

        <Callout title="First deployment may fail">
          The first time this may fail if you don't yet have a custom domain connected since you cannot place it in the environment variables yet. It's fine. Make the first deployment fail, then pick the domain and add it. Redeploy.
        </Callout>
      </Step>

      <Step>
        ## Deploy!

        By default, TurboStarter comes with a Github Actions workflow that can be [triggered manually](https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow).

        The configuration is located in `.github/workflows/publish-web.yml`, you can easily customize it to your needs, for example to trigger a deployment from `main` branch.

        ```diff title=".github/workflows/publish-web.yml"
        on:
        - workflow_dispatch:
        + push:
        +   branches:
        +     - main
        ```

        Then, every time you push to `main` branch, the workflow will be triggered and the application will be deployed to Vercel.

        ![Vercel deploy](/images/docs/web/deployment/vercel/success.png)

        That's it! Your app is now deployed to Vercel, congratulations! 🎉
      </Step>
    </Steps>
  </Tab>
</Tabs>

<Card title="Vercel" href="https://vercel.com" description="vercel.com" />

## Troubleshooting

In some cases, users have reported issues with the deployment to Vercel using the default parameters. If you encounter problems, try these troubleshooting steps:

1. **Check root directory settings**

   * Set the root directory to `apps/web`
   * Enable *Include source files outside of the Root Directory* option

2. **Verify build configuration**

   * Ensure the framework preset is set to Next.js
   * Set build command to `pnpm turbo build --filter=web`
   * Set install command to `pnpm install`

3. **Review deployment logs**
   * If deployment fails, carefully review the build logs
   * Look for any error messages about missing dependencies or environment variables
   * Verify that all required environment variables are properly configured

If issues persist after trying these steps, check the [deployment troubleshooting guide](/docs/web/troubleshooting/deployment) for additional help.


file: ./src/content/docs/web/emails/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure your emails in TurboStarter."
}
        
The `@turbostarter/email` package provides a simple and flexible way to send emails using various email providers. It abstracts the complexity of different email services and offers a consistent interface for sending emails with pre-defined templates.

To configure the email service, you need to set a few environment variables.

```dotenv
EMAIL_PROVIDER="resend"
EMAIL_FROM="hello@resend.dev"
EMAIL_THEME="orange"
```

Let's break down the variables:

* `EMAIL_PROVIDER` - The email provider to use. Defaults to [Resend](/docs/web/emails/configuration#resend).
* `EMAIL_FROM` - The email address that emails will be sent from. **Please make sure that the mail address and domain are verified in your mail provider.**
* `EMAIL_THEME` - The theme color to use for the emails. See [Themes](/docs/web/customization/styling#themes) for more information.

Configuration will be validated against the schema, so you will see the error messages in the console if something is not right.

## Providers

TurboStarter supports multiple email providers, each with its own configuration. Below, you'll find detailed information on how to set up and use each supported provider. Choose the one that best fits your needs and follow the instructions in the respective accordion section.

<Accordions>
  <Accordion title="Resend" id="resend">
    To use Resend as your email provider, you need to [create an account](https://resend.com/) and [obtain your API key](https://resend.com/docs/dashboard/api-keys/introduction).

    Then, set it as an environment variable in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    RESEND_API_KEY="your-api-key"
    ```

    Also, make sure to activate the Resend provider as your email provider:

    ```dotenv
    EMAIL_PROVIDER="resend"
    ```

    To customize the provider, you can find its definition in `packages/email/src/providers/resend` directory.

    For more information, please refer to the [Resend documentation](https://resend.com/docs).
  </Accordion>

  <Accordion title="SendGrid" id="sendgrid">
    To use SendGrid as your email provider, you need to [create an account](https://sendgrid.com/) and [obtain your API key](https://sendgrid.com/docs/ui/account-and-settings/api-keys/).

    Then, set it as an environment variable in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    SENDGRID_API_KEY="your-api-key"
    ```

    Also, make sure to activate the SendGrid provider as your email provider:

    ```dotenv
    EMAIL_PROVIDER="sendgrid"
    ```

    To customize the provider, you can find its definition in `packages/email/src/providers/sendgrid` directory.

    For more information, please refer to the [SendGrid documentation](https://sendgrid.com/docs).
  </Accordion>

  <Accordion title="Postmark" id="postmark">
    To use Postmark as your email provider, you need to [create an account](https://postmarkapp.com/) and [obtain your server API token](https://postmarkapp.com/support/article/1008-what-are-the-account-and-server-api-tokens).

    Then, set it as an environment variable in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    POSTMARK_API_KEY="your-secret-api-token"
    ```

    Also, make sure to activate the Postmark provider as your email provider:

    ```dotenv
    EMAIL_PROVIDER="postmark"
    ```

    To customize the provider, you can find its definition in `packages/email/src/providers/postmark` directory.

    For more information, please refer to the [Postmark documentation](https://postmarkapp.com/developer).
  </Accordion>

  <Accordion title="Plunk" id="plunk">
    To use Plunk as your email provider, you need to [create an account](https://plunk.dev/) and [obtain your API key](https://docs.useplunk.com/api-reference/authentication).

    Then, set it as an environment variable in your `.env.local` file in `apps/web` directory and your deployment environment:

    ```dotenv
    PLUNK_API_KEY="your-api-key"
    ```

    Also, make sure to activate the Plunk provider as your email provider:

    ```dotenv
    EMAIL_PROVIDER="plunk"
    ```

    To customize the provider, you can find its definition in `packages/email/src/providers/plunk` directory.

    For more information, please refer to the [Plunk documentation](https://docs.useplunk.com).
  </Accordion>

  <Accordion title="nodemailer" id="nodemailer">
    If you're using the `nodemailer` as your email provider, you'll need to set the following SMTP configuration in your environment variables:

    ```dotenv
    NODEMAILER_HOST="your-smtp-host"
    NODEMAILER_PORT="your-smtp-port"
    NODEMAILER_USER="your-smtp-user"
    NODEMAILER_PASSWORD="your-smtp-password"
    ```

    The variables are:

    * `NODEMAILER_HOST`: The host of your SMTP server.
    * `NODEMAILER_PORT`: The port of your SMTP server.
    * `NODEMAILER_USER`: The email address user of your SMTP server.
    * `NODEMAILER_PASSWORD`: The password for the email account.

    Also, make sure to activate the nodemailer provider as your email provider:

    ```dotenv
    EMAIL_PROVIDER="nodemailer"
    ```

    To customize the provider, you can find its definition in `packages/email/src/providers/nodemailer` directory.

    For more information, please refer to the [nodemailer documentation](https://nodemailer.com/smtp/).
  </Accordion>
</Accordions>

## Templates

In the `@turbostarter/email` package, we provide a set of pre-defined templates for you to use. You can find them in the `packages/email/src/templates` directory.

When you run your development server, you will be able to preview all available templates in the browser under [http://localhost:3005](http://localhost:3005).

![Email preview](/images/docs/web/emails/development.png)

Next to the templates, you can also find some shared components that you can use in your emails. The file structure looks like this:

<Files>
  <Folder name="templates" defaultOpen>
    <Folder name="_components - Shared components used in emails" />

    <Folder name="auth - Authentication related emails" />

    <File name="index.ts - Main entrypoint for the templates" />
  </Folder>
</Files>

Feel free to add your own templates and components or modify existing ones to match them with your brand and style.

### How to add a new template?

We'll go through the process of adding a new template, as it requires a few steps to make sure everything works correctly.

<Steps>
  <Step>
    #### Define types

    Let's assume that we want to add a **welcome email**, that new users will receive after signing up.

    We'll start with defining new template type in `packages/email/src/types/templates.ts` file:

    ```ts title="templates.ts"
    export const EmailTemplate = {
      ...AuthEmailTemplate,
      WELCOME: "welcome",
    } as const;
    ```

    Also, we would need to add types for variables that we'll pass to the template (if any), in our case it will be just a `name` of the user:

    ```ts title="templates.ts"
    type WelcomeEmailVariables = {
      welcome: {
        name: string;
      };
    };

    export type EmailVariables = AuthEmailVariables | WelcomeEmailVariables;
    ```

    By doing this, we ensure that payload passed to the template will have all required properties and we won't end up with an email that tells your user "Hey, undefined!".
  </Step>

  <Step>
    #### Create template

    Next up, we need to create a file with the template itself. We'll create an `welcome.tsx` file in `packages/email/src/templates` directory.

    ```tsx title="welcome.tsx"
    import { Heading, Preview, Text } from "@react-email/components";

    import { Button } from "../_components/button";
    import { Layout } from "../_components/layout/layout";

    import type { EmailTemplate, EmailVariables } from "../../types";

    type Props = EmailVariables[typeof EmailTemplate.WELCOME];

    export const Welcome = ({ name }: Props) => {
      return (
        <Layout>
          <Preview>Welcome to TurboStarter!</Preview>
          <Heading>Hi, {name}!</Heading>

          <Text>Start your journey with our app by clicking the button below.</Text>

          <Button>Start</Button>
        </Layout>
      );
    };

    Welcome.subject = "Welcome to TurboStarter!";

    Welcome.PreviewProps = {
      name: "John Doe",
    };

    export default Welcome;
    ```

    As you can see, by defining appropriate types for the template, we can safely use the variables as a props in the template.

    To learn more about supported components, please refer to the [React Email documentation](https://react.email/docs/components).
  </Step>

  <Step>
    #### Register template

    We have to register the template in the main entrypoint of the templates in `packages/email/src/templates/index.ts` file:

    ```ts title="index.ts"
    import { Welcome } from "./welcome";

    export const templates = {
      ...
      [EmailTemplate.WELCOME]: Welcome,
    } as const;
    ```

    That way, it will be available in the `sendEmail` function, enabling us to send it from the server-side of your application.

    ```ts
    import { sendEmail } from "@turbostarter/email/server";

    sendEmail({
      to: "user@example.com",
      template: EmailTemplate.WELCOME,
      variables: {
        name: "John Doe",
      },
    });
    ```

    Learn more about sending emails in the [dedicated section](/docs/web/emails/sending).
  </Step>
</Steps>

Et voilà! You've just added a new email template to your application 🎉

### Translating templates

You can also translate your templates to support multiple languages. Each mail template is passed the `locale` property, which you can use to get the translation for the current locale. This allows you to maintain consistent translations across your application and emails.

The translation system **uses the same i18n** setup as your main application, so you can reuse your existing translation files and namespaces. The translations are loaded server-side when the email is generated, ensuring the correct language is used based on the user's preferences.

Here's how you can implement translations in your email templates:

```tsx
import { Heading, Preview, Text } from "@react-email/components";

import { getTranslation } from "@turbostarter/i18n/server";

import { Button } from "../_components/button";
import { Layout } from "../_components/layout/layout";

import type {
  EmailTemplate,
  EmailVariables,
  CommonEmailProps,
} from "../../types";

type Props = EmailVariables[typeof EmailTemplate.WELCOME] & CommonEmailProps;

export const Welcome = async ({ name, locale }: Props) => {
  const { t } = await getTranslation({ locale, ns: "auth" });

  return (
    <Layout locale={locale}>
      <Preview>{t("account.welcome.preview")}</Preview>
      <Heading>{t("account.welcome.heading", { name })}</Heading>

      <Text>{t("account.welcome.body")}</Text>

      <Button>{t("account.welcome.cta")}</Button>
    </Layout>
  );
};

Welcome.subject = async ({ locale }: CommonEmailProps) => {
  const { t } = await getTranslation({ locale, ns: "auth" });
  return t("account.welcome.subject");
};

Welcome.PreviewProps = {
  name: "John Doe",
  locale: "en",
};

export default Welcome;
```

To send the email in the specified language, you can pass the optional `locale` argument to the `sendEmail` function:

```ts
sendEmail({
  to: "user@example.com",
  template: EmailTemplate.WELCOME,
  variables: {
    name: "John Doe",
  },
  locale: "en", // [!code highlight]
});
```

Learn more about translations in the [dedicated section](/docs/web/internationalization/translations).


file: ./src/content/docs/web/emails/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with emails in TurboStarter.",
  "index": true
}
        
For mailing functionality, TurboStarter integrates [React Email](https://react.email/docs/introduction) which enables you to build your emails from composable React components.

<Callout title="Why React Email?">
  It's a simple, yet powerful library that allows you to **write your emails in React**.

  It also allows you to use **Tailwind CSS for styling**, which is a huge advantage, as we can share almost everything from the main app with the emails package, keeping them consistent with rest of the app.
</Callout>

You can read more about `react-email` package in the [official documentation](https://react.email/docs/introduction).

## Providers

TurboStarter implements multiple providers for managing and sending emails. To learn more about each provider and how to configure them, see the respective section:

<Cards>
  <Card title="Resend" href="/docs/web/emails/configuration#resend" />

  <Card title="SendGrid" href="/docs/web/emails/configuration#sendgrid" />

  <Card title="Postmark" href="/docs/web/emails/configuration#postmark" />

  <Card title="Plunk" href="/docs/web/emails/configuration#plunk" />

  <Card title="Nodemailer" href="/docs/web/emails/configuration#nodemailer" />
</Cards>

All configuration and setup is built-in with a unified API, so you can switch between providers without changing your code and even introduce your own provider without breaking any sending-related logic.

## Development

When you [setup your development environment](/docs/web/installation/development) and run `pnpm dev` command a new app will start at [http://localhost:3005](http://localhost:3005).

![Email preview](/images/docs/web/emails/development.png)

There you'll be able to check your email templates and send test emails from your app. It includes hot-reloading, so when you make change in the code - it will be reflected in the browser.

Learn more about configuration and setup of the emails in TurboStarter in the following sections.


file: ./src/content/docs/web/emails/sending.mdx
meta: {
  "title": "Sending emails",
  "description": "Learn how to send emails in TurboStarter."
}
        
The strategy for sending emails, that every provider has to implement, is **extremely simple**:

```ts
export interface EmailProviderStrategy {
  send: (args: {
    to: string;
    subject: string;
    text: string;
    html?: string;
  }) => Promise<void>;
}
```

<Callout>
  You don't need to worry much about it, as all the providers are already configured for you. Just be aware of it if you want to add your custom provider.
</Callout>

Then, we define a general `sendEmail` function that you can use as an API for sending emails in your app:

```ts
const sendEmail = async <T extends EmailTemplate>({
  to,
  template,
  variables,
  locale,
}: {
  to: string;
  template: T;
  variables: EmailVariables[T];
  locale?: string;
}) => {
  const strategy = strategies[provider];
  const { html, text, subject } = await getTemplate({
    id: template,
    variables,
    locale,
  });

  return strategy.send({ to, subject, html, text });
};
```

The arguments are:

* `to`: The recipient's email address.
* `template`: The email template to use.
* `variables`: The variables to pass to the template.
* `locale`: The locale to use for the email.

It returns a promise that resolves when the email is sent successfully. If there is an error, the promise will be rejected with an error message.

To send an email, just invoke the `sendEmail` with the correct arguments from the **server-side** of your application:

```ts
import { sendEmail } from "@turbostarter/email/server";

sendEmail({
  to: "user@example.com",
  template: EmailTemplate.WELCOME,
  variables: {
    name: "John Doe",
  },
  locale: "en",
});
```

And that's it! You're ready to send emails in your application 🚀

## Authentication emails

TurboStarter comes with a set of pre-configured authentication emails for various purposes, including magic links and password reset functionality.

To handle the sending of these emails at the right time, we use [Better Auth Hooks](https://www.better-auth.com/docs/concepts/email), which trigger when specific authentication events occur.

The logic for determining which email to send is already implemented for you in the `packages/auth/src/server.ts` file, alongside your [authentication configuration](/docs/web/auth/configuration):

```ts title="server.ts"
export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    sendResetPassword: async ({ user, url }) =>
      sendEmail({
        to: user.email,
        template: EmailTemplate.RESET_PASSWORD,
        variables: {
          url,
        },
      }),
  },
  emailVerification: {
    sendVerificationEmail: async ({ user, url }) =>
      sendEmail({
        to: user.email,
        template: EmailTemplate.CONFIRM_EMAIL,
        variables: {
          url,
        },
      }),
  },

  /* other options */
});
```

As you can see, the authentication emails are automatically sent when needed (e.g. when user requests password reset or needs to verify their email address).

You can customize authentication templates by modifying them in the `packages/email/src/templates` directory, or create your own templates for other use cases in your application.


file: ./src/content/docs/web/installation/clone.mdx
meta: {
  "title": "Cloning repository",
  "description": "Get the code to your local machine and start developing."
}
        
<Callout type="info" title="Prerequisite: Git installed">
  Ensure you have Git installed on your local machine before proceeding. You can download Git from [here](https://git-scm.com).
</Callout>

## Git clone

Clone the repository using the following command:

```bash
git clone git@github.com:turbostarter/main
```

<Callout type="info" title="If your SSH key isn't set up, use HTTPS instead:">
  ```bash
  git clone https://github.com/turbostarter/main
  ```
</Callout>

<Callout type="warn" title="Use HTTPS for all commands if not using SSH">
  If you are not using SSH, ensure you switch to HTTPS for all Git commands, not just the clone command.
</Callout>

<Card title="Git clone" description="git-scm.com" href="https://git-scm.com/docs/git-clone" />

## Git remote

After cloning the repository, remove the original origin remote:

```bash
git remote rm origin
```

Add the upstream remote pointing to the original repository to pull updates:

```bash
git remote add upstream git@github.com:turbostarter/main
```

Once you have your own repository set up, add your repository as the origin:

```bash
git remote add origin <your-repository-url>
```

<Card title="Git remote" description="git-scm.com" href="https://git-scm.com/docs/git-remote" />

## Staying up to date

To pull updates from the upstream repository, run the following command daily (preferably with your morning coffee ☕):

```bash
git pull upstream main
```

This ensures your repository stays up to date with the latest changes.

Check [Updating codebase](/docs/web/installation/update) for more details on updating your codebase.


file: ./src/content/docs/web/installation/commands.mdx
meta: {
  "title": "Common commands",
  "description": "Learn about common commands you need to know to work with the project."
}
        
<Callout>
  For sure, you don't need these commands to kickstart your project, but it's useful to know they exist for when you need them.
</Callout>

<Callout title="Want shorter commands?">
  You can set up aliases for these commands in your shell configuration file. For example, you can set up an alias for `pnpm` to `p`:

  ```bash title="~/.bashrc"
  alias p='pnpm'
  ```

  Or, if you're using [Zsh](https://ohmyz.sh/), you can add the alias to `~/.zshrc`:

  ```bash title="~/.zshrc"
  alias p='pnpm'
  ```

  Then run `source ~/.bashrc` or `source ~/.zshrc` to apply the changes.

  You can now use `p` instead of `pnpm` in your terminal. For example, `p i` instead of `pnpm install`.
</Callout>

## Installing dependencies

To install the dependencies, run:

```bash
pnpm install
```

## Starting development server

Start development server by running:

```bash
pnpm dev
```

## Building project

To build the project (including all apps and packages), run:

```bash
pnpm build
```

## Building specific app/package

To build a specific app/package, run:

```bash
pnpm turbo build --filter=<package-name>
```

## Cleaning project

To clean the project, run:

```bash
pnpm clean
```

Then, reinstall the dependencies:

```bash
pnpm install
```

## Formatting code

To format code using Prettier, run:

```bash
pnpm format:fix
```

## Linting code

To lint code using ESLint, run:

```bash
pnpm lint:fix
```

## Typechecking

To typecheck the code using TypeScript, run:

```bash
pnpm typecheck
```

## Adding UI components

<Tabs items={["Web", "Mobile"]}>
  <Tab value="Web">
    To add a new web component, run:

    ```bash
    pnpm --filter @turbostarter/ui-web ui:add
    ```

    This command will add and export a new component to `@turbostarter/ui-web` package.
  </Tab>

  <Tab value="Mobile">
    To add a new mobile component, run:

    ```bash
    pnpm --filter @turbostarter/ui-mobile ui:add
    ```

    This command will add and export a new component to `@turbostarter/ui-mobile` package.
  </Tab>
</Tabs>

## Database commands

We have a few commands to help you manage the database leveraging [Drizzle CLI](https://orm.drizzle.team/kit-docs/commands).

### Generating migrations

To generate a new migration, run:

```bash
pnpm db:generate
```

It will create a new migration `.sql` file in the `migrations` folder.

### Running migrations

To run the migrations against the db, run:

```bash
pnpm db:migrate
```

It will apply all the pending migrations.

### Pushing changes directly

<Callout type="warn" title="Don't mess up with your schema!">
  Make sure you know what you're doing before pushing changes directly to the db.
</Callout>

To push changes directly to the db, run:

```bash
pnpm db:push
```

It lets you push your schema changes directly to the database and omit managing SQL migration files.

### Checking database

To check the database schema consistency, run:

```bash
pnpm db:check
```

### Docker commands

<Callout title="Prerequisite: Docker installed">
  To run the database instance locally, you need to have [Docker](https://www.docker.com/) installed on your machine.

  You can always use the cloud-hosted solution ([Neon](https://neon.tech/), [Turso](https://turso.tech/) or any other provider) for your projects.
</Callout>

We have a few commands to help you manage the database instance (for local development).

#### Starting container

To start the database container, run:

```bash
pnpm db:start
```

It will run the PostgreSQL container. You can check its config in `packages/db/docker-compose.yml`.

#### Stopping container

To stop the database container, run:

```bash
pnpm db:stop
```

#### Displaying status

To check the status and logs of the database container, run:

```bash
pnpm db:status
```


file: ./src/content/docs/web/installation/conventions.mdx
meta: {
  "title": "Conventions",
  "description": "Some standard conventions used across TurboStarter codebase."
}
        
You're not required to follow these conventions: they're simply a standard set of practices used in the core kit. If you like them - I encourage you to keep these during your usage of the kit - so to have consistent code style that you and your teammates understand.

## Turborepo Packages

In this project, we use [Turborepo packages](https://turbo.build/repo/docs/core-concepts/internal-packages) to define reusable code that can be shared across multiple applications.

* **Apps** are used to define the main application, including routing, layout, and global styles.
* **Packages** shares reusable code add functionalities across multiple applications. They're configurable from the main application.

<Callout title="Should I create a new package?">
  **Recommendation:** Do not create a package for your app code unless you plan to reuse it across multiple applications or are experienced in writing library code.

  If your application is not intended for reuse, keep all code in the app folder. This approach saves time and reduces complexity, both of which are beneficial for fast shipping.

  **Experienced developers:** If you have the experience, feel free to create packages as needed.
</Callout>

## Imports and Paths

When importing modules from packages or apps, use the following conventions:

* **From a package:** Use `@turbostarter/package-name` (e.g., `@turbostarter/ui`, `@turbostarter/api`, etc.).
* **From an app:** Use `~/` (e.g., `~/lib/components`, `~/config`, etc.).

## Enforcing conventions

* [Prettier](https://prettier.io/) is used to enforce code formatting.
* [ESLint](https://eslint.org/) is used to enforce code quality and best practices.
* [TypeScript](https://www.typescriptlang.org/) is used to enforce type safety.

<Cards className="grid-cols-2 sm:grid-cols-3">
  <Card title="Prettier" href="https://prettier.io/" description="prettier.io" />

  <Card title="ESLint" href="https://eslint.org/" description="eslint.org" />

  <Card title="TypeScript" href="https://www.typescriptlang.org/" description="typescriptlang.org" />
</Cards>

## Code health

TurboStarter provides a set of tools to ensure code health and quality in your project.

### Github Actions

By default, TurboStarter sets up Github Actions to run tests on every push to the repository. You can find the Github Actions configuration in the `.github/workflows` directory.

The workflow has multiple stages:

* `format` - runs Prettier to format the code.
* `lint` - runs ESLint to check for linting errors.
* `typecheck` - runs TypeScript to check for type errors.

### Git hooks

Together with TurboStarter we have set up a `commit-msg` hook which will check if your commit message follows the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) message format. This is important for generating changelogs and keeping a clean commit history.

Although we didn't ship any pre-commit hooks (we believe in shipping fast with moving checking code responsibility to CI), you can easily add them by using [Husky](https://typicode.github.io/husky/#/).

#### Setting up the Pre-Commit Hook

To do so, create a `pre-commit` file in the `./..husky` directory with the following content:

```bash
#!/bin/sh

pnpm typecheck
pnpm lint
```

Turborepo will execute the commands for all the affected packages - while skipping the ones that are not affected.

#### Make the Pre-Commit Hook Executable

```bash
chmod +x ./.husky/pre-commit
```

To test the pre-commit hook, try to commit a file with linting errors or type errors. The commit should fail, and you should see the error messages in the console.


file: ./src/content/docs/web/installation/dependencies.mdx
meta: {
  "title": "Managing dependencies",
  "description": "Learn how to manage dependencies in your project."
}
        
As the package manager we chose [pnpm](https://pnpm.io/).

<Callout title="Why pnpm?">
  It is a fast, disk space efficient package manager that uses hard links and symlinks to save one version of a module only ever once on a disk. It also has a great [monorepo support](https://pnpm.io/workspaces). Of course, you can change it to use [Bun](https://bunpkg.com), [yarn](https://yarnpkg.com) or [npm](https://www.npmjs.com) with minimal effort.
</Callout>

## Install dependency

To install a package you need to decide whether you want to install it to the root of the monorepo or to a specific workspace. Installing it to the root makes it available to all packages, while installing it to a specific workspace makes it available only to that workspace.

To install a package globally, run:

```bash
pnpm add -w <package-name>
```

To install a package to a specific workspace, run:

```bash
pnpm add --filter <workspace-name> <package-name>
```

For example:

```bash
pnpm add --filter @turbostarter/ui motion
```

It will install `motion` to the `@turbostarter/ui` workspace.

## Remove dependency

Removing a package is the same as installing but with the `remove` command.

To remove a package globally, run:

```bash
pnpm remove -w <package-name>
```

To remove a package from a specific workspace, run:

```bash
pnpm remove --filter <workspace-name> <package-name>
```

## Update a package

Updating is a bit easier since there is a nice way to update a package in all workspaces at once:

```bash
pnpm update -r <package-name>
```

<Callout title="Semantic versioning">
  When you update a package, pnpm will respect the [semantic versioning](https://docs.npmjs.com/about-semantic-versioning) rules defined in the `package.json` file. If you want to update a package to the latest version, you can use the `--latest` flag.
</Callout>

## Renovate bot

By default, TurboStarter comes with [Renovate](https://www.npmjs.com/package/renovate) enabled. It is a tool that helps you manage your dependencies by automatically creating pull requests to update your dependencies to the latest versions. You can find its configuration in the `.github/renovate.json` file. Learn more about it in the [official docs](https://docs.renovatebot.com/configuration-options/).

When it creates a pull request, it is treated as a normal PR, so all tests and preview deployments will run. **It is recommended to always preview and test the changes in the staging environment before merging the PR to the main branch to avoid breaking the application.**

<Card href="https://docs.renovatebot.com" title="Renovate" description="renovatebot.com" />


file: ./src/content/docs/web/installation/development.mdx
meta: {
  "title": "Development",
  "description": "Get started with the code and develop your SaaS."
}
        
## Prerequisites

To get started with TurboStarter, ensure you have the following installed and set up:

* [Node.js](https://nodejs.org/en) (20.x or higher)
* [Docker](https://www.docker.com) (only if you want to use local database)
* [pnpm](https://pnpm.io)

## Project development

<Steps>
  <Step>
    ### Install dependencies

    Install the project dependencies by running the following command:

    ```bash
    pnpm i
    ```

    <Callout title="Why pnpm?">
      It is a fast, disk space efficient package manager that uses hard links and symlinks to save one version of a module only ever once on a disk. It also has a great [monorepo support](https://pnpm.io/workspaces). Of course, you can change it to use [Bun](https://bunpkg.com), [yarn](https://yarnpkg.com) or [npm](https://www.npmjs.com) with minimal effort.
    </Callout>
  </Step>

  <Step>
    ### Setup environment variables

    Create a `.env.local` files from `.env.example` files and fill in the required environment variables.

    Check [Environment variables](/docs/web/configuration/environment-variables) for more details on setting up environment variables.
  </Step>

  <Step>
    ### Start database

    If you want to use local database (**recommended for development purposes**), ensure Docker is running, then setup your database with:

    ```bash
    pnpm db:setup
    ```

    This command initiates the PostgreSQL container and runs migrations, ensuring your database is up to date and ready to use.
  </Step>

  <Step>
    ### Start development server

    To start the application development server, run:

    ```bash
    pnpm dev
    ```

    Your app should now be up and running at [http://localhost:3000](http://localhost:3000) 🎉
  </Step>

  <Step>
    ### Deploy to Production

    When you're ready to deploy the project to production, follow the [checklist](/docs/web/deployment/checklist) to ensure everything is set up correctly.
  </Step>
</Steps>


file: ./src/content/docs/web/installation/editor-setup.mdx
meta: {
  "title": "Editor setup",
  "description": "Learn how to set up your editor for the fastest development experience."
}
        
Of course you can use every IDE you like, but you will have the best possible developer experience with this starter kit when using **VSCode-based** editor with the suggested settings and extensions.

## Settings

We have included most recommended settings in the `.vscode/settings.json` file to make your development experience as smooth as possible. It include mostly configs for tools like Prettier, ESLint and Tailwind which are used to enforce some conventions across the codebase. You can adjust them to your needs.

### Cursor rules

For [Cursor](https://www.cursor.com/) users we have included a custom rules to ensure that AI completions are working as expected and following our conventions. You can find them in the `.cursorrules` file.

```md title=".cursorrules"
Code Style and Structure:

- Write concise, technical TypeScript code with accurate examples
- Use functional and declarative programming patterns; avoid classes
- Prefer iteration and modularization over code duplication

Naming Conventions:
....
```

We also exposed a special endpoint that will scan all the docs and return the content as a text file which you can use to train your LLM or put in a prompt. You can find it at [/api/llms.txt](/api/llms.txt).

## Extensions

Once you cloned the project and opened it in VSCode you should be promted to install suggested extensions which are defined in the `.vscode/extensions.json` automatically. In case you rather want to install them manually you can do so at any time later.

These are the extensions we recommend:

### ESLint

Global extension for static code analysis. It will help you to find and fix problems in your JavaScript code.

<Card title="Download ESLint" href="https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint" description="marketplace.visualstudio.com" />

### Prettier

Global extension for code formatting. It will help you to keep your code clean and consistent.

<Card title="Download Prettier" href="https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode" description="marketplace.visualstudio.com" />

### Pretty TypeScript Errors

Improves TypeScript error messages in the editor.

<Card title="Download Pretty TypeScript Errors" href="https://marketplace.visualstudio.com/items?itemName=yoavbls.pretty-ts-errors" description="marketplace.visualstudio.com" />

### Tailwind CSS IntelliSense

Adds IntelliSense for Tailwind CSS classes to enable autocompletion and linting.

<Card title="Download Tailwind CSS IntelliSense" href="https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss" description="marketplace.visualstudio.com" />


file: ./src/content/docs/web/installation/structure.mdx
meta: {
  "title": "Project structure",
  "description": "Learn about the project structure and how to navigate it."
}
        
The main directories in the project are:

* `apps` - the location of the main apps
* `packages` - the location of the shared code and the API

### `apps` Directory

This is where the apps live. It includes web app (Next.js), mobile app (React Native - Expo), and the browser extension (WXT - Vite + React). Each app has its own directory.

### `packages` Directory

This is where the shared code and the API for packages live. It includes the following:

* shared libraries (database, mailers, cms, billing, etc.)
* shared features (auth, mails, billing, ai etc.)
* UI components (buttons, forms, modals, etc.)

All apps can use and reuse the API exported from the packages directory. This makes it easy to have one, or many apps in the same codebase, sharing the same code.

## Repository structure

By default the monorepo contains the following apps and packages:

<Files>
  <Folder name="apps" defaultOpen>
    <Folder name="web - Web app (Next.js)" />

    <Folder name="mobile - Mobile app (React Native - Expo)" />

    <Folder name="extension - Browser extension (WXT - Vite + React)" />
  </Folder>

  <Folder name="packages" defaultOpen>
    <Folder name="api - API server (including all features logic)" />

    <Folder name="auth - Authentication setup" />

    <Folder name="billing - Billing config and providers" />

    <Folder name="cms - CMS setup and providers" />

    <Folder name="db - Database setup" />

    <Folder name="email - Mail templates and providers" />

    <Folder name="i18n - Internationalization setup" />

    <Folder name="shared - Shared utilities and helpers" />

    <Folder name="storage - Storage setup" />

    <Folder name="ui - Atomic UI components">
      <Folder name="shared" />

      <Folder name="web" />

      <Folder name="mobile" />
    </Folder>
  </Folder>

  <Folder name="tooling" defaultOpen>
    <Folder name="eslint - ESLint config" />

    <Folder name="github - Github actions" />

    <Folder name="prettier - Prettier config" />

    <Folder name="tailwind - Tailwind CSS config" />

    <Folder name="typescript - TypeScript config" />
  </Folder>
</Files>

## Web application structure

The web application is located in the `apps/web` folder. It contains the following folders:

<Files>
  <Folder name="public - Static assets" />

  <Folder name="src" defaultOpen>
    <Folder name="app - Main application" />

    <Folder name="assets - Optimized static assets" />

    <Folder name="components - Components for modules" />

    <Folder name="config - App config" />

    <Folder name="lib - Communication with packages" />

    <Folder name="providers - Shared React providers" />

    <Folder name="utils - Shared utilities" />
  </Folder>

  <File name=".env.local" />

  <File name="next.config.js" />

  <File name="package.json" />

  <File name="tailwind.config.ts" />

  <File name="tsconfig.json" />

  <File name="turbo.json" />
</Files>


file: ./src/content/docs/web/installation/update.mdx
meta: {
  "title": "Updating codebase",
  "description": "Learn how to update your codebase to the latest version."
}
        
If you've been following along with our previous guides, you should already have a Git repository set up for your project, with an `upstream` remote pointing to the original repository.

Updating your project involves fetching the latest changes from the `upstream` remote and merging them into your project. Let's dive into the steps!

<Steps>
  <Step>
    ## Stash changes

    <Callout title="Don't have changes?">
      If you don't have any changes to stash, you can skip this step and proceed with the update process.

      Alternatively, you can [commit](https://git-scm.com/docs/git-commit) your changes.
    </Callout>

    If you have any uncommitted changes, stash them before proceeding. It will allow you to avoid any conflicts that may arise during the update process.

    ```bash
    git stash
    ```

    This command will save your changes in a temporary location, allowing you to retrieve them later. Once you're done updating, you can apply the stash to your working directory.

    ```bash
    git stash apply
    ```
  </Step>

  <Step>
    ## Pull changes

    Pull the latest changes from the `upstream` remote.

    ```bash
    git pull upstream main
    ```

    When prompted the first time, please opt for merging instead of rebasing.

    Don't forget to run `pnpm i` in case there are any updates in the dependencies.
  </Step>

  <Step>
    ## Resolve conflicts

    If there are any conflicts during the merge, Git will notify you. You can resolve them by opening the conflicting files in your code editor and making the necessary changes.

    <Callout title="Conflicts in pnpm-lock.yaml?">
      If you find conflicts in the `pnpm-lock.yaml file`, accept either of the two changes (avoid manual edits), then run:

      ```bash
      pnpm i
      ```

      Your lock file will now reflect both your changes and the updates from the upstream repository.
    </Callout>
  </Step>

  <Step>
    ## Run a health check

    After resolving the conflicts, it's time to test your project to ensure everything is working as expected. Run your project locally and navigate through the various features to verify that everything is functioning correctly.

    For a quick health check, you can run:

    ```bash
    pnpm lint
    pnpm typecheck

    ```

    If everything looks good, you're all set! Your project is now up to date with the latest changes from the `upstream` repository.
  </Step>

  <Step>
    ## Commit and push

    Once everything is working fine, don't forget to commit your changes using:

    ```bash
    git commit -m "<your-commit-message>"
    ```

    and push them to your remote repository with:

    ```bash
    git push origin <your-branch-name>
    ```
  </Step>
</Steps>


file: ./src/content/docs/web/internationalization/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure internationalization in TurboStarter."
}
        
The default global configuration is defined in the `@turbostarter/i18n` package and shared across all applications. You can override it in each app to customize the internationalization setup for that specific app.

The configuration is defined in the `packages/i18n/src/config.ts` file:

```ts title="packages/i18n/src/config.ts"
export const config = {
  locales: ["en", "es"],
  defaultLocale: "en",
  namespaces: ["common", "auth", "billing", "marketing", "validation"],
  cookie: "locale",
} as const;
```

Let's break down the configuration options:

* `locales`: An array of all supported locales.
* `defaultLocale`: The default locale to use if no other locale is detected.
* `namespaces`: An array of all namespaces used in the application.
* `cookie`: The name of the cookie to store the detected locale (acts as a cache).

## Translation files

The core of the whole internationalization setup is the translation files. They are stored in the `packages/i18n/src/translations` directory and are used to store the translations for each locale and namespace.

Each directory represents a locale and contains a set of files, each corresponding to a specific namespace (e.g. `en/common.json`). Inside we define the keys and values for the translations.

```ts title="packages/i18n/src/translations/en/common.json"
{
  "hello": "Hello, world!"
}
```

That way we can ensure that we have a single source of truth for the translations and we can use them consistently in all the applications.

## Locales

The `locales` array in the configuration defines the list of supported languages in your application. Each locale is represented by a string that uniquely identifies the language.

To add a new locale, you need to:

1. Add the new locale to the `locales` array in the configuration.
2. Create a new directory in the `packages/i18n/src/translations` directory.
3. Create a new file in the new directory for each namespace and add the translations for the new locale.

For example, if you want to add the `fr` locale, you need to:

1. Add `fr` to the `locales` array in the configuration.
2. Create a new directory in the `packages/i18n/src/translations` directory.
3. Create a new file for each namespace in the created directory and add the translations for the new locale.

### Fallback locale

The `defaultLocale` option in the configuration defines the fallback locale. If a translation is not found for a specific locale, the fallback locale will be used.

We can also override this setting in each [app configuration](/docs/web/configuration/app) by configuring the `locale` property.

## Namespaces

`namespaces` are used to group translations by feature or module. This helps in organizing the translations and makes it easier to maintain them.

### Why not one big namespace?

Using multiple namespaces instead of one large namespace helps with:

1. **Performance:** load translations on-demand instead of all at once, reducing the initial bundle size.
2. **Organization:** group translations by feature (e.g., `auth`, `common`, `dashboard`).
3. **Maintenance:** easier to update and manage smaller translation files.
4. **Development:** better TypeScript support and team collaboration.

For example, you might structure your namespaces like this:

<Tabs items={["Common", "Auth", "Billing"]}>
  <Tab value="Common">
    ```ts title="packages/i18n/src/translations/en/common.json"
    {
      "hello": "Hello, world!"
    }
    ```
  </Tab>

  <Tab value="Auth">
    ```ts title="packages/i18n/src/translations/en/auth.json"
    {
      "login": "Login",
      "register": "Register"
    }
    ```
  </Tab>

  <Tab value="Billing">
    ```ts title="packages/i18n/src/translations/en/billing.json"
    {
      "invoice": "Invoice",
      "payment": "Payment",
      "subscription": "Subscription"
    }
    ```
  </Tab>
</Tabs>

Remember that while you can create as many namespaces as needed, it's important to maintain a balance - too many namespaces can lead to unnecessary complexity, while too few might defeat the purpose of separation.

## Routing

TurboStarter implements locale-based routing by placing pages under the `[locale]` folder. However, the default locale (usually `en`) is not prefixed in the URL for better SEO and user experience.

For example, with English as the default locale and Polish as an additional language:

* `/dashboard` → English version (default locale)
* `/pl/dashboard` → Polish version

The app also automatically detects the user's preferred language through cookies, HTML `lang` attribute, and browser's `Accept-Language` header.

This ensures a seamless experience where users get content in their preferred language while maintaining clean URLs for the default locale.

<Callout>
  You can override the locale by manually setting the cookie or by navigating to
  a URL with a different locale prefix.
</Callout>


file: ./src/content/docs/web/internationalization/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with internationalization in TurboStarter.",
  "index": true
}
        
TurboStarter uses [i18next](https://www.i18next.com/) for internationalization, which is one of the most popular and mature (over 10 years of development!) i18n frameworks for JavaScript.

<Callout title="Why i18next?">
  With i18next, you can easily translate your application into multiple
  languages, handle complex pluralization rules, format dates and numbers
  according to locale, and much more. The framework is highly extensible through
  plugins and provides excellent TypeScript support out of the box.
</Callout>

You can read more about `i18next` package in the [official documentation](https://www.i18next.com/overview/getting-started).

![i18next logo](/images/docs/i18next.jpg)

## Getting started

TurboStarter comes with `i18next` pre-configured and abstracted behind the `@turbostarter/i18n` package. This abstraction layer ensures that any future changes to the underlying translation library won't impact your application code. The internationalization setup is ready to use out of the box and includes:

* Multiple language support out of the box
* Type-safe translations with generated types
* Automatic language detection
* Easy-to-use React hooks for translations
* Built-in number and date formatting
* Support for nested translation keys
* Pluralization handling

To start using internationalization in your app, you'll need to:

1. Configure your supported languages
2. Add translation files
3. Use translation hooks in your components

Check out the following sections to learn more about each step:


file: ./src/content/docs/web/internationalization/translations.mdx
meta: {
  "title": "Translating app",
  "description": "Learn how to translate your application to multiple languages."
}
        
TurboStarter provides a flexible and powerful translation system that works seamlessly across your entire application. Whether you're working with React Server Components (RSC), client-side components, or server-side rendering, you can easily integrate translations to create a fully internationalized experience.

The translation system supports:

* **Server components (RSC)** for efficient server-side translations
* **Client components** for dynamic language switching
* **Server-side rendering** for SEO-friendly translated content

## Server components (RSC)

To get the translations in a server component, you can use the `getTranslation` method:

```tsx
import { getTranslation } from "@turbostarter/i18n";

export default async function MyComponent() {
  const { t } = await getTranslation();

  return <div>{t("common:hello")}</div>;
}
```

There is also a possibility to use the [Trans](https://react.i18next.com/latest/trans-component) component, which could be useful e.g. for interpolating variables:

```tsx
import { Trans } from "@turbostarter/i18n";
import { withI18n } from "@turbostarter/i18n/server";

const Page = () => {
  return <Trans i18nKey="common:hello" components={{ bold: <b /> }} />;
};

export default withI18n(Page);
```

Although, to make it available in the server component, you need to wrap it with the `withI18n` HOC.

Given that server components are rendered in parallel, it's uncertain which one will render first. Therefore, it's crucial to initialize the translations before rendering the server component on each page/layout.

## Client components

For client components, you can use the `useTranslation` hook from the `@turbostarter/i18n` package:

```tsx
"use client";

import { useTranslation } from "@turbostarter/i18n";

export default function MyComponent() {
  const { t } = useTranslation();

  return <div>{t("common:hello")}</div>;
}
```

That's the simplest way to get the translations in a client component.

## Server-side

In all other places (e.g. metadata, API routes, sitemaps etc.) you can use the `getTranslation` method to get the translations server-side:

```ts
import { getTranslation } from "@turbostarter/i18n";

export const generateMetadata = async () => {
  const { t } = await getTranslation();

  return {
    title: t("common:title"),
  };
};
```

It automatically checks the user's preferred locale and uses the correct translation.

## Language switcher

TurboStarter ships with a language switcher component that allows you to switch between languages. You can import and use the `LocaleSwitcher` component and drop it anywhere in your application to allow users to change the language seamlessly.

```tsx
import { LocaleSwitcher } from "@turbostarter/ui-web";

export default function MyComponent() {
  return <LocaleSwitcher />;
}
```

The component automatically displays all languages configured in your i18n settings. When a user switches languages, it will:

1. Update the URL to include the new locale prefix (e.g. `/es/dashboard`)
2. Store the selected locale in a cookie for persistence
3. Refresh translations across the entire application
4. Preserve the current page/route during the language switch

This provides a seamless localization experience without requiring any additional configuration.

## Best practices

Here are some recommended best practices for managing translations in your application:

* Use descriptive translation keys that follow a logical hierarchy

  ```ts
  // ✅ Good
  "auth.login.title";

  // ❌ Bad
  "loginTitleForAuth";
  ```

* Keep translations organized in separate namespaces/files based on features or sections

  ```
  translations/
  ├── en/
  │   ├── auth.json
  │   └── common.json
  └── pl/
      ├── auth.json
      └── billing.json
  ```

* Avoid hardcoding text strings - always use translation keys even for seemingly static content

* Always provide a fallback language (usually English) for when translations are missing

* Use pluralization and interpolation features when dealing with dynamic content

  ```ts
  // Pluralization
  t("items", { count: 2 }); // "2 items"

  // Interpolation
  t("welcome", { name: "John" }); // "Welcome, John!"
  ```

* Regularly review and clean up unused translation keys to keep files maintainable

* Use TypeScript for type-safe translation keys


file: ./src/content/docs/web/marketing/legal.mdx
meta: {
  "title": "Legal pages",
  "description": "Learn how to create and update legal pages"
}
        
Legal pages are defined in the `apps/web/src/app/[locale]/(marketing)/legal` directory.

TurboStarter comes with the following legal pages:

* **Terms and Conditions**: to define the terms and conditions of your application
* **Privacy Policy**: to define the privacy policy of your application
* **Cookie Policy**: to define the cookie policy of your application

For obvious reasons, **these pages are empty and you need to fill in the content.**

## Content from CMS

Content for legal pages are stored as [MDX](https://mdxjs.com/) files in [content collection](/docs/web/cms/content-collections) in `packages/cms/src/content/collections/legal` directory.

Then it's parsed and rendered as a Next.js page under corresponding slug:

```tsx title="apps/web/src/app/[locale]/(marketing)/legal/[slug]/page.tsx"
import {
  CollectionType,
  getContentItemBySlug,
  getContentItems,
} from "@turbostarter/cms";

export default async function Page({ params }: PageParams) {
  const item = getContentItemBySlug({
    collection: CollectionType.LEGAL,
    slug: (await params).slug,
    locale: (await params).locale,
  });

  if (!item) {
    notFound();
  }

  return <Mdx data={item} base={LEGAL_PREFIX} />;
}

export function generateStaticParams() {
  return getContentItems({ collection: CollectionType.LEGAL }).items.map(
    ({ slug, locale }) => ({
      slug,
      locale,
    }),
  );
}
```

As it's fully typesafe it also allows us to generate metadata for each page based on the frontmatter that you define in the MDX file:

```tsx title="apps/web/src/app/[locale]/(marketing)/legal/[slug]/page.tsx"
export async function generateMetadata({ params }: PageParams) {
  const item = getContentItemBySlug({
    collection: CollectionType.LEGAL,
    slug: (await params).slug,
    locale: (await params).locale,
  });

  if (!item) {
    return notFound();
  }

  return getMetadata({
    title: item.title,
    description: item.description,
  })({ params });
}
```

Read more about it in the [CMS section](/docs/web/cms/overview).

## ChatGPT prompts

Each `.mdx` file with legal content include a set of useful prompts that you can use to generate the content.

<Callout type="warn" title="Please, be aware of this!">
  Please, be aware that **ChatGPT is not a lawyer** and the content generated by it should be reviewed by one before publishing. Take your time and treat the generated content as a starting point not a final document.
</Callout>

```mdx title="privacy-policy.mdx"
---
title: Privacy Policy
description: Our privacy policy outlines how we collect, use, and protect your personal information.
---

{/* 💡 You can use one of the following ChatGPT prompts to generate this 💡 */}

...
```

Feel free to add your own content or even additional pages to the `legal` collection.


file: ./src/content/docs/web/marketing/pages.mdx
meta: {
  "title": "Marketing pages",
  "description": "Discover which marketing pages are available out of the box and how to add a new one."
}
        
TurboStarter comes with pre-defined marketing pages to help you get started with your SaaS application. These pages are built with Next.js and Tailwind CSS and are located in the `apps/web/src/app/[locale]/(marketing)` directory.

TurboStarter comes with the following marketing pages:

* [Blog](/docs/web/cms/blog): to display your blog posts
* **Pricing**: to display your pricing plans
* **Contact**: to enable users to contact you with a contact form

## Contact form

To make the contact form work, you need to add the following environment variable:

```dotenv
CONTACT_EMAIL=
```

Set this variable to the email address where you want to receive contact form submissions. The sender's email address will match what you configured in your [mailing configuration](/docs/web/emails/configuration).

## Adding a new marketing page

To add a new marketing page, create a new directory in `apps/web/src/app/[locale]/(marketing)` with the desired route name.

The page will automatically become available in your application at the corresponding URL path.

For example, to create a page accessible at `/about`, create a directory named `about` and add a `page.tsx` file inside it. The complete path would be `apps/web/src/app/[locale]/(marketing)/about/page.tsx`.

```tsx title="apps/web/src/app/[locale]/(marketing)/about/page.tsx"
export default function AboutPage() {
  return <div>About</div>;
}
```

This page inherits the layout at `apps/web/src/app/[locale]/(marketing)/layout.tsx`. You can customize the layout by editing this file - but remember that it will affect all marketing pages.


file: ./src/content/docs/web/marketing/seo.mdx
meta: {
  "title": "SEO",
  "description": "Learn how to optimize your app for search engines."
}
        
SEO is an important part of building a website. It helps search engines understand your website and rank it higher in search results. In this guide, you'll learn how to improve your SaaS application's search engine optimization (SEO).

<Callout title="Already optimized!">
  TurboStarter is already optimized for SEO out of the box (including meta tags, sitemaps, robots files and many more). However, there are a few things you can do to improve your application's SEO.
</Callout>

**Content:** High-quality, relevant content is the cornerstone of effective SEO. Focus on **creating valuable, engaging content** that addresses your customers' needs and questions. Regularly update your content to keep it fresh and relevant.

**Keyword optimization:** Conduct thorough keyword research to identify terms your target audience is searching for. Incorporate these keywords naturally into your content, titles, meta descriptions, and headers. Avoid keyword stuffing; prioritize readability and user experience.

**On-Page SEO:**

* Use descriptive, keyword-rich titles and meta descriptions for each page.
* Implement a clear heading structure (H1, H2, H3) to organize your content.
* Optimize images with descriptive file names and alt text.
* Ensure your URLs are clean, descriptive, and include relevant keywords.

**Technical SEO:**

* Improve website loading speed by optimizing images, minifying CSS and JavaScript, and leveraging browser caching.
* Ensure your website is mobile-friendly and responsive across all devices.
* Implement schema markup to help search engines better understand your content.
* Use HTTPS to secure your website and boost search rankings.

**User experience:**

* Design an intuitive site structure and navigation to improve user engagement.
* Reduce bounce rates by creating compelling, easy-to-read content.
* Implement internal linking to guide users through your site and distribute page authority.

**Link building:**

* Create high-quality, shareable content to naturally attract backlinks.
* Engage in guest posting on reputable sites within your industry.
* Participate in industry forums and discussions, providing valuable insights and linking to your content when relevant.
* Leverage social media to increase content visibility and encourage sharing.

**Local SEO (if applicable):**

* Claim and optimize your Google My Business listing.
* Ensure consistent NAP (Name, Address, Phone) information across all online directories.
* Encourage customer reviews on Google and other relevant platforms.

**Monitor and analyze:**

* Use [Google Search Console](https://search.google.com/search-console/about) to monitor your site's performance in search results and identify issues.
* Regularly analyze your SEO efforts using tools like Google Analytics to understand user behavior and refine your strategy.

**Stay updated:**

* Keep abreast of SEO best practices and algorithm updates to continually refine your strategy.
* Regularly audit your website to identify and fix any SEO issues.

## Sitemap

Generally speaking, Google will find your pages without a sitemap as it follows the link in your website. However, you can add pages to the sitemap by adding them to the `apps/web/src/app/sitemap.ts` file, which is used to generate the sitemap.

If you add more static pages to your website, you can add them to the sitemap by adding them to the `apps/web/src/app/sitemap.ts` returned array.

```tsx title="sitemap.ts"
export default function sitemap(): MetadataRoute.Sitemap {
  return [
    {
      ...getEntry(pathsConfig.index),
      lastModified: new Date(),
      changeFrequency: "monthly",
      priority: 1,
    },
    ...getContentItems({
      collection: CollectionType.BLOG,
      locale: appConfig.locale,
    }).items.map<MetadataRoute.Sitemap[number]>((post) => ({
      ...getEntry(pathsConfig.marketing.blog.post(post.slug)),
      lastModified: new Date(post.lastModifiedAt),
      changeFrequency: "monthly",
      priority: 0.7,
    })),

    /* other pages */
  ];
}
```

All the existing pages are already added to the sitemap. You don't need to add them manually.

## Meta tags

TurboStarter provides a helper function called `getMetadata` to easily set meta tags for your pages. This helper ensures consistent metadata formatting across your site and includes essential SEO tags like title, description, and Open Graph tags. You can use it in any page's metadata export:

```tsx title="page.tsx"
export const generateMetadata = getMetadata({
  title: "My Page Title",
  description: "My Page Description",
});
```

This will generate the following meta tags:

```html
<meta name="description" content="My Page Description" />
<meta property="og:title" content="My Page Title" />
<meta property="og:description" content="My Page Description" />
```

The `getMetadata` helper is really useful for generating consistent meta tags across your site, making SEO optimization simpler and more reliable.

<Callout title="Translations supported!">
  `getMetadata` also supports translations. You can pass a translation key to the `title` and `description` parameters, and it will automatically use the correct translation for the current locale.

  ```tsx
  export const generateMetadata = getMetadata({
    title: "billing:title",
    description: "billing:description",
  });
  ```

  In this example, the `title` and `description` will be fetched from the `billing` namespace for the current locale and placed in the meta tags.
</Callout>

## Backlinks

Backlinks are said to be the **most important factor** in modern SEO. The more backlinks you have from high-quality websites, the higher your website will rank in search results - and the more traffic you'll get.

How do you acquire backlinks? The most effective strategy is to create high-quality, valuable content that naturally attracts links from other websites. However, there are several other methods to build backlinks:

1. **Guest blogging:** Contribute articles to reputable websites within your industry. This not only provides backlinks but also exposes your brand to a new audience.
2. **Strategic outreach:** Identify websites that could benefit from linking to your content. Reach out with a personalized pitch, explaining the value your content adds to their audience.
3. **Digital PR:** Create newsworthy content or conduct original research that journalists and bloggers will want to reference and link to.
4. **Broken link building:** Find broken links on relevant websites and suggest your content as a replacement.
5. **Resource page link building:** Find resource pages in your niche and suggest your content for inclusion.
6. **Social media engagement:** While not directly impacting SEO, active social media presence can increase content visibility and indirectly lead to more backlinks.
7. **Create linkable assets:** Develop infographics, tools, or comprehensive guides that others in your industry will want to reference.
8. **Participate in industry forums and discussions:** Contribute meaningfully to conversations in your field, including your website when relevant.

Remember, the quality of backlinks is more important than quantity. Focus on acquiring links from authoritative, relevant websites in your niche. Avoid any black-hat techniques or link schemes that could result in penalties from search engines.

## Adding your website to Google Search Console

Once you've optimized your website for SEO, you can add it to Google Search Console. Google Search Console is a free tool that helps you monitor and maintain your website's presence in Google search results.

You can use it to check your website's indexing status, submit sitemaps, and get insights into how Google sees your website.

The first thing you need to do is verify your website in Google Search Console. You can do this by adding a meta tag to your website's HTML or by uploading an HTML file to your website.

Once you've verified your website, you can submit your sitemap to Google Search Console. This will help Google find and index your website's pages faster.

Please submit your sitemap to Google Search Console by going to the `Sitemaps` section and adding the URL of your sitemap. The URL of your sitemap is `https://your-website.com/sitemap.xml`.

Of course, please replace `your-website.com` with your actual website URL.

## Content

When it comes to internal factors, **content is king**. Make sure your content is relevant, useful, and engaging. Make sure it's updated regularly and optimized for SEO.

<Callout title="What should you write about?">
  Most importantly, you want to think about how your customers will search for the problem your SaaS is solving. For example, if you're building a project management tool, you might want to write about project management best practices, how to manage a remote team, or how to use your tool to improve productivity.
</Callout>

You can use the blog and documentation features in TurboStarter to create high-quality content that will help your website rank higher in search results - and help your customers find what they're looking for.

## Indexing and ranking take time

New websites can take a while to get indexed by search engines. It can take anywhere from a few days to a few weeks (in some cases, even months!) for your website to show up in search results. Be patient and keep updating your content and optimizing your website for search engines.

Also, you can edit `robots.ts` file to control which pages are indexed by search engines:

```tsx title="robots.ts"
export default function robots(): MetadataRoute.Robots {
  return {
    rules: {
      userAgent: "*",
      allow: "/",
      disallow: ["/api", "/dashboard", "/auth"],
    },
    sitemap: appConfig.url + "/sitemap.xml",
  };
}
```

Remember, **SEO is an ongoing process.** Consistently apply these practices and adapt your strategy based on performance data and industry changes to improve your search engine visibility over time.


file: ./src/content/docs/web/storage/configuration.mdx
meta: {
  "title": "Configuration",
  "description": "Learn how to configure storage in TurboStarter."
}
        
Currently, TurboStarter supports all S3-compatible storage providers, including [AWS S3](https://aws.amazon.com/s3/), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces), [Cloudflare R2](https://www.cloudflare.com/products/r2/), and [Supabase Storage](https://supabase.com/storage).

The setup process is straightforward - you just need to configure a few environment variables in both your local environment and hosting provider:

```dotenv
S3_REGION=
S3_BUCKET=
S3_ENDPOINT=
S3_ACCESS_KEY_ID=
S3_SECRET_ACCESS_KEY=
```

Let's break down each required variable:

* `S3_REGION`: The [AWS region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where your storage is located - defaults to `us-east-1`
* `S3_BUCKET`: The default name of your storage bucket - you can pass different for each request
* `S3_ENDPOINT`: The S3 [endpoint URL](https://docs.aws.amazon.com/general/latest/gr/s3.html) for your storage provider - defaults to `https://s3.amazonaws.com`
* `S3_ACCESS_KEY_ID`: Your storage provider's [access key ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)
* `S3_SECRET_ACCESS_KEY`: Your storage provider's [secret access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)

You can learn more about S3 service configuration in the [official AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html) or your specific storage provider's documentation.


file: ./src/content/docs/web/storage/managing-files.mdx
meta: {
  "title": "Managing files",
  "description": "Learn how to manage files in TurboStarter."
}
        
Before you start managing files, make sure you have [configured storage](/docs/web/storage/configuration).

## Permissions

Most S3-compatible storage providers allow you to configure bucket permissions and access policies. It's crucial to properly set these up to secure your files and control who can access them.

Here are some key security recommendations:

* Keep your bucket private by default
* Use IAM roles and policies to manage access
* Enable server-side encryption for sensitive data
* Configure CORS settings appropriately for client-side uploads
* Regularly audit bucket permissions and access logs

Making your bucket public is strongly discouraged as it can expose sensitive data and lead to unauthorized access and unexpected costs from bandwidth usage.

For detailed guidance on configuring bucket policies and permissions, refer to your storage provider's documentation:

* [AWS S3 Security Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-policy-language-overview.html)
* [DigitalOcean Spaces Security](https://docs.digitalocean.com/products/spaces/how-to/manage-access/)
* [Cloudflare R2 Security](https://developers.cloudflare.com/r2/api/s3/tokens/)
* [Supabase Storage Security](https://supabase.com/docs/guides/storage/security/access-control)

## Uploading files

As explained in the [overview](/docs/web/storage/overview), TurboStarter uses presigned URLs to upload files to your storage provider.

We prepared a special endpoint to generate presigned URLs for your uploads to use in your client-side code.

```ts title="storage.router.ts"
export const storageRouter = new Hono().get(
  "/upload",
  enforceAuth,
  validate("query", getObjectUrlSchema),
  async (c) => c.json(await getUploadUrl(c.req.valid("query"))),
);
```

<Callout title="Expiration time" type="warn">
  The signed URL is only valid for a limited time and will work for anyone who has access to it during that period. Make sure to handle the URL securely and avoid exposing it to unauthorized users.
</Callout>

Then, you can use it to upload files to the generated presigned URL from your frontend code:

```tsx title="upload.tsx"
const upload = useMutation({
    mutationFn: async (data: { file?: File }) => {
      const extension = data.file?.type.split("/").pop();
      const path = `files/${crypto.randomUUID()}.${extension}`;

      const { url: uploadUrl } = await handle(api.storage.upload.$get)({
        query: { path },
      });

      const response = await fetch(uploadUrl, {
        method: "PUT",
        body: data.file,
        headers: {
          "Content-Type": data.file?.type ?? "",
        },
      });

      if (!response.ok) {
        throw new Error("Failed to upload file!");
      }
    },
    onError: (error) => {
      toast.error(error.message});
    },
    onSuccess: async ({ publicUrl, oldImage }, _b, context) => {
      toast.success("File uploaded!");
    },
  });
```

The code above demonstrates how to implement file uploads in your application:

1. First, we have a server-side endpoint (`storageRouter`) that generates presigned URLs for uploads. This endpoint:

   * [Requires authentication](/docs/web/api/protected-routes) via `enforceAuth`
   * Validates the request parameters using `validate`
   * Returns a presigned URL for uploading

2. Then, in the frontend code (`upload.tsx`), we use React Query's `useMutation` hook to handle the upload process:
   * Requests a presigned URL from the server
   * Uploads the file directly to the storage provider using the presigned URL
   * Handles success and error cases with toast notifications

This approach ensures secure file uploads while avoiding server bandwidth costs and function timeout issues.

### Public uploads

Although **it's not recommended** to use public uploads in production, you can use the same endpoint to generate presigned URLs for public uploads:

```ts title="storage.router.ts"
export const storageRouter = new Hono().get(
  "/upload",
  validate("query", getObjectUrlSchema),
  async (c) => c.json(await getUploadUrl(c.req.valid("query"))),
);
```

Just remove the `enforceAuth` middleware from the endpoint and keep rest of the logic the same.

## Displaying files

We provide dedicated endpoints for retrieving signed URLs specifically for displaying files. These URLs are time-limited to maintain security, so they cannot be used for permanent storage or long-term access:

```ts title="storage.router.ts"
export const storageRouter = new Hono().get(
  "/signed",
  enforceAuth,
  validate("query", getObjectUrlSchema),
  async (c) => c.json(await getSignedUrl(c.req.valid("query"))),
);
```

This endpoint is perfect for displaying files that should only be accessible to authorized users for a limited time.

### Public files

For displaying files publicly (without authorization and time limitations), you can use the `/public` endpoint:

```ts title="storage.router.ts"
export const storageRouter = new Hono().get(
  "/public",
  validate("query", getObjectUrlSchema),
  async (c) => c.json(await getPublicUrl(c.req.valid("query"))),
);
```

This endpoint generates a public URL for the file that you can use to display in your application. Please ensure that your bucket policy allows public access to the files and verify that you're not exposing any sensitive information.

## Deleting files

Deleting files works almost the same way as uploading files. You just need to generate a presigned URL for deletion and then use it to remove the file:

```ts title="storage.router.ts"
export const storageRouter = new Hono().get(
  "/delete",
  validate("query", getObjectUrlSchema),
  async (c) => c.json(await getDeleteUrl(c.req.valid("query"))),
);
```

Then, in the frontend code, we use React Query's `useMutation` hook to handle the deletion process:

```tsx title="delete.tsx"
const remove = useMutation({
  mutationFn: async () => {
    const path = file.split("/").pop();
    if (!path) return;

    const { url: deleteUrl } = await handle(api.storage.delete.$get)({
      query: { path: `files/${path}` },
    });

    await fetch(deleteUrl, {
      method: "DELETE",
    });
  },
  onError: (error) => {
    toast.error(error.message);
  },
  onSuccess: () => {
    toast.success("File removed!");
  },
});
```

Now that you understand how to manage files in TurboStarter, it's time to build something awesome! Try creating a file upload component, building a photo gallery, or implementing a document management system.


file: ./src/content/docs/web/storage/overview.mdx
meta: {
  "title": "Overview",
  "description": "Get started with storage in TurboStarter.",
  "index": true
}
        
With TurboStarter, you can easily upload and manage files (images, videos, documents, and more) in your application.

Currently, all S3-compatible storage providers are supported, including [AWS S3](https://aws.amazon.com/s3/), [DigitalOcean Spaces](https://www.digitalocean.com/products/spaces), [Cloudflare R2](https://www.cloudflare.com/products/r2/), [Supabase Storage](https://supabase.com/storage), and others.

## Uploading files

The most common approach to uploading files is to use client-side uploads. With client-side uploads, you avoid paying ingress/egress fees for transferring file binary data through your server.

Additionally, most hosting platforms like [Vercel](https://vercel.com/docs/functions/runtimes#size-limits) or [Netlify](https://answers.netlify.com/t/what-is-the-maximum-file-size-upload-limit-in-a-netlify-form-submission/108419) have limitations on file size and maximum serverless function execution time.

That's why TurboStarter utilizes the **presigned URLs** feature of storage providers to upload files. Instead of sending files to the serverless function, the client requests a time-limited presigned URL from the serverless function and then uploads the file directly to the storage provider.

![Client side uploads](/images/docs/web/storage.png)

1. Client **requests** a presigned URL from the serverless function.
2. Server parses the request, validates the payload, optionally saves the metadata, and **returns the presigned URL** to the client.
3. Client **uploads the file** to the presigned URL within the expiration time.
4. (Optional) Once the file is uploaded, the serverless function is notified about the upload event, and the file metadata is saved to the database.

<Callout>
  This approach ensures that credentials remain secure, handles authorization and authentication properly, and avoids the limitations of serverless platforms.
</Callout>

The configuration and use of storage is straightforward and simple. We'll explore this in more detail in the following sections.


file: ./src/content/docs/web/troubleshooting/billing.mdx
meta: {
  "title": "Billing",
  "description": "Find answers to common billing issues."
}
        
## Checkout can't be created

This happen in the following cases:

1. The environment variables are not set correctly. Please make sure you have set the environment variables corresponding to your billing provider in `.env.local` if locally - or in your hosting provider's dashboard if in production
2. The price IDs used are incorrect. Make sure to use the exact price IDs as they are in the payment provider's dashboard.

[Read more about billing configuration](/docs/web/billing/configuration)

## Database is not updated after subscribing to a plan

This may happen if the webhook is not set up correctly. Please make sure you have set up the webhook in the payment provider's dashboard and that the URL is correct.

If working locally, make sure that:

1. If using Stripe, that the Stripe CLI or configured proxy is up and running ([see the Stripe documentation for more information](/docs/web/billing/stripe#create-a-webhook))
2. If using Lemon Squeezy, that the webhook set in Lemon Squeezy is correct and that the server is running. Additionally, make sure the proxy is set up correctly if you are testing locally ([see the Lemon Squeezy documentation for more information](/docs/web/billing/lemon-squeezy#create-a-webhook)).


file: ./src/content/docs/web/troubleshooting/deployment.mdx
meta: {
  "title": "Deployment",
  "description": "Find answers to common web deployment issues."
}
        
## Deployment build fails

This is most likely an issue related to the environment variables not being set correctly in the deployment environment. Please analyse the logs of the deployment provider to see what is the issue.

The kit is very defensive about incorrect environment variables, and will throw an error if any of the required environment variables are not set. In this way - the build will fail if the environment variables are not set correctly - instead of deploying a broken application.

Check our guides for the most popular hosting providers for more information on how to deploy your TurboStarter project correctly:

<Cards>
  <Card title="Vercel" description="Deploy your TurboStarter web app to Vercel platform." href="/docs/web/deployment/vercel" />

  {/* <Card
      title="Cloudflare"
      description="Deploy your TurboStarter web app to Cloudflare platform."
      href="/docs/web/deployment/cloudflare"
    /> */}

  <Card title="Netlify" description="Deploy your TurboStarter web app to Netlify platform." href="/docs/web/deployment/netlify" />

  <Card title="Render" description="Deploy your TurboStarter web app to Render platform." href="/docs/web/deployment/render" />

  <Card title="Railway" description="Deploy your TurboStarter web app to Railway platform." href="/docs/web/deployment/railway" />

  <Card title="Docker" description="Containerize your TurboStarter web app using Docker." href="/docs/web/deployment/docker" />

  <Card title="Fly.io" description="Deploy your TurboStarter web app to Fly.io platform." href="/docs/web/deployment/fly" />
</Cards>

## What should I set as a URL before my first deployment?

That's very good question! For the first deployment you can set any URL, and then, after you (or your provider) assign a domain name, you can change it to the correct one. There's nothing wrong with redeploying your project multiple times.

## Sign in with OAuth provider doesn't work

This is most likely a settings issues in the provider's settings. To troubleshoot this issue, follow these steps:

1. **Verify provider settings**: Ensure that the OAuth provider's settings are correctly configured. Check that the client ID, client secret, and redirect URI are accurate and match the values in your application.
2. **Check environment variables**: Confirm that the environment variables for the OAuth provider are set correctly in your application production environment.
3. **Validate callback URLs**: Ensure that the callback URLs for each provider are set correctly and match the URLs in your application. This is crucial for the OAuth flow to work correctly.

Please read [Better Auth documentation](https://www.better-auth.com/docs/concepts/oauth) for more information on how to set up third-party providers.


file: ./src/content/docs/web/troubleshooting/emails.mdx
meta: {
  "title": "Emails",
  "description": "Find answers to common emails issues."
}
        
## I want to use a different email provider

Of course! You can use any email provider that you want. All you need to do is to implement the `EmailProviderStrategy` and pass it to the `strategies` map.

[Read more about sending emails](/docs/web/emails/sending)

## My emails are landing in the spam folder

Emails landing in spam folders is a common issue. Here are key steps to improve deliverability:

1. **Configure proper domain setup**:

   * Use a dedicated subdomain for sending emails (e.g., mail.yourdomain.com)
   * Ensure [reverse DNS (PTR) records](https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/) are properly configured
   * Warm up your sending domain gradually

2. **Implement authentication protocols**:

   * Set up [SPF records](https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/) to specify authorized sending servers
   * Enable [DKIM signing](https://www.cloudflare.com/learning/dns/dns-records/dns-dkim-record/) to verify email authenticity
   * Configure [DMARC policies](https://www.cloudflare.com/learning/dns/dns-records/dns-dmarc-record/) to prevent spoofing

3. **Follow deliverability best practices**:

   * Include clear unsubscribe mechanisms in all marketing communications
   * Personalize content appropriately
   * Avoid excessive promotional language and spam triggers
   * Maintain consistent HTML formatting and styling
   * Only include links to verified domains
   * Keep a regular sending schedule
   * Clean your email lists regularly
   * Use double opt-in for new subscribers

4. **Monitor and optimize**:
   * Track key metrics like delivery rates, opens, and bounces
   * Monitor spam complaint rates
   * Review email authentication reports
   * Test emails across different clients and devices
   * Adjust sending practices based on performance data


file: ./src/content/docs/web/troubleshooting/installation.mdx
meta: {
  "title": "Installation",
  "description": "Find answers to common web installation issues."
}
        
## Cannot clone the repository

Issues related to cloning the repository are usually related to a Git misconfiguration in your local machine. The commands displayed in this guide using SSH: these will work only if you have setup your SSH keys in Github.

If you run into issues, [please make sure you follow this guide to set up your SSH key in Github.](https://docs.github.com/en/authentication/connecting-to-github-with-ssh)

If this also fails, please use HTTPS instead. You will be able to see the commands in the repository's Github page under the "Clone" dropdown.

Please also make sure that the account that accepted the invite to TurboStarter, and the locally connected account are the same.

## My environment variables from `.env.local` file are not being loaded

Make sure you are running the `pnpm dev` command from the root directory of your project (where the `pnpm-workspace.yaml` file is located)

Also, ensure that the `.env.local` files are present in the apps that need them. For example, the `.env` file should be present in the `apps/web` directory for the web app.

<Callout>
  TurboStarter uses the `dotenv-cli` to load environment variables from a `.env` files. The `dotenv-cli` is automatically used when running the `pnpm dev` command from the root directory.
</Callout>

## Next.js server doesn't start

This may happen due to some issues in the packages. Try to clean the workspace using the following command:

```bash
pnpm clean
```

Then, reinstall the dependencies:

```bash
pnpm i
```

You can now retry running the dev server.

## Local database doesn't start

If you cannot run the local database container, it's likely you have not started [Docker](https://docs.docker.com/get-docker/) locally. Our local database requires Docker to be installed and running.

Please make sure you have installed Docker (or compatible software such as [Colima](https://github.com/abiosoft/colima), [Orbstack](https://github.com/orbstack/orbstack)) and that is running on your local machine.

Also, make sure that you have enough [memory and CPU allocated](https://docs.docker.com/engine/containers/resource_constraints/) to your Docker instance.

## I don't see my translations

If you don't see your translations appearing in the application, there are a few common causes:

1. Check that your translation `.json` files are properly formatted and located in the correct directory
2. Verify that the language codes in your configuration match your translation files
3. Enable debug mode (`debug: true`) in your i18next configuration to see detailed logs

[Read more about configuration for translations](/docs/web/internationalization/configuration)

## "Module not found" error

This issue is mostly related to either dependency installed in the wrong package or issues with the file system.

The most common cause is incorrect dependency installation. Here's how to fix it:

1. Clean the workspace:

   ```bash
   pnpm clean
   ```

2. Reinstall the dependencies:
   ```bash
   pnpm i
   ```

If you're adding new dependencies, make sure to install them in the correct package:

```bash
# For main app dependencies
pnpm install --filter web my-package

# For a specific package
pnpm install --filter @turbostarter/ui my-package
```

If the issue persists, please check the file system for any issues.

### Windows OneDrive

OneDrive can cause file system issues with Node.js projects due to its file syncing behavior. If you're using Windows with OneDrive, you have two options to resolve this:

1. Move your project to a location outside of OneDrive-synced folders (recommended)
2. Disable OneDrive sync specifically for your development folder

This prevents file watching and symlink issues that can occur when OneDrive tries to sync Node.js project files.


file: ./src/content/docs/mobile/auth/oauth/apple.mdx
meta: {
  "title": "Apple",
  "description": "Configure native Apple OAuth for your application."
}
        
<Callout title="&#x22;Sign in with Apple&#x22; is coming soon" type="info">
  We are working on adding native "Sign in with Apple" support to TurboStarter. Stay tuned for updates.

  [See roadmap](https://github.com/orgs/turbostarter/projects/1)
</Callout>

You can find these resources helpful for implementing "Sign in with Apple" in your app:

<Cards>
  <Card title="Expo AppleAuthentication" href="https://docs.expo.dev/versions/latest/sdk/apple-authentication/" description="docs.expo.dev" />

  <Card title="Login with Apple" href="https://www.better-auth.com/docs/authentication/apple" description="better-auth.com" />

  <Card title="Sign in with Apple" href="https://developer.apple.com/documentation/sign_in_with_apple" description="developer.apple.com" />
</Cards>


file: ./src/content/docs/mobile/auth/oauth/google.mdx
meta: {
  "title": "Google",
  "description": "Configure native Google OAuth for your application."
}
        
<Callout title="&#x22;Sign in with Google&#x22; is coming soon" type="info">
  We are working on adding native "Sign in with Google" support to TurboStarter. Stay tuned for updates.

  [See roadmap](https://github.com/orgs/turbostarter/projects/1)
</Callout>

You can find these resources helpful for implementing "Sign in with Google" in your app:

<Cards>
  <Card title="Use Google Authentication" href="https://docs.expo.dev/guides/google-authentication/" description="docs.expo.dev" />

  <Card title="Login with Google" href="https://www.better-auth.com/docs/authentication/google" description="better-auth.com" />

  <Card title="Authenticate users with Sign in with Google" href="https://developer.android.com/identity/sign-in/credential-manager-siwg" description="developer.android.com" />
</Cards>


file: ./src/content/docs/mobile/auth/oauth/index.mdx
meta: {
  "title": "OAuth",
  "description": "Get started with social authentication.",
  "index": true
}
        
Better Auth supports almost **15** (!) different [OAuth providers](https://www.better-auth.com/docs/concepts/oauth). They can be easily configured and enabled in the kit without any additional configuration needed.

<Callout title="Everything configured!">
  TurboStarter provides you with all the configuration required to handle OAuth providers responses from your app:

  * redirects
  * middleware
  * confirmation API routes

  You just need to configure one of the below providers on their side and set correct credentials as environment variables in your TurboStarter app.
</Callout>

![OAuth providers](/images/docs/web/auth/social-providers.png)

Third Party providers need to be configured, managed and enabled fully on the provider's side. TurboStarter just needs the correct credentials to be set as environment variables in your app and passed to the [authentication API configuration](/docs/web/auth/configuration#api).

To enable OAuth providers in your TurboStarter app, you need to:

1. Set up an OAuth application in the provider's developer console (like Google Cloud Console, Github Developer Settings or any other provider you want to use)
2. Configure the provider's credentials as environment variables in your app. For example, for Google OAuth:

```dotenv title="packages/db/.env.local"
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
```

Then, pass it to the authentication configuration in `packages/auth/src/server.ts`:

```tsx title="server.ts"
export const auth = betterAuth({
  ...

  socialProviders: {
    [SOCIAL_PROVIDER.GOOGLE]: {
      clientId: env.GOOGLE_CLIENT_ID,
      clientSecret: env.GOOGLE_CLIENT_SECRET,
    },
  },

  ...
});
```

<Callout title="Remember to add your app scheme as trusted origin">
  For mobile apps, we need to define a trusted origin using an app scheme instead of a classic URL. App schemes (like `turbostarter://`) are used for [deep linking](https://docs.expo.dev/guides/linking/) users to specific screens in your app after authentication.

  To find your app scheme, take a look at `apps/mobile/app.config.ts` file and then add it to your auth server configuration:

  ```tsx title="server.ts"
  export const auth = betterAuth({
    ...

    trustedOrigins: ["turbostarter://**"],

    ...
  });
  ```

  Adding your app scheme to the trusted origins list is crucial for security - it prevents CSRF attacks and blocks malicious open redirects by ensuring only requests from approved origins (your app) are allowed through.

  [Read more about auth security in Better Auth's documentation.](https://www.better-auth.com/docs/reference/security)
</Callout>

Also, we included some native integrations (Apple for iOS and Google for Android) to make the sign-in process smoother and faster for the user.