---
title: "Payload template"
description: "Scaffold, configure and maintain the Payload + Next.js starter."
requested_language: fr
language: en
translation_notice: "This page isn't translated yet"
url: https://docs.systhema.app/fr/getting-started/templates/payload
version: unreleased (main)
docs_index: https://docs.systhema.app/fr/llms.txt
---
> This page isn't translated yet. Showing English.


Scaffold the Payload and Next.js starter with the CLI, configure it and keep it current. To build the same setup by hand, see [Install in a Payload project](https://docs.systhema.app/fr/getting-started/installation/payload.md).

## Quick start

### 1. Configure registry access

Set up the `.npmrc` and `GITHUB_TOKEN` described in [Registry access](https://docs.systhema.app/fr/getting-started/registry-access.md) before installing.

### 2. Scaffold the project

Use the global CLI:

```bash
pnpm dlx @systhemaui/cli@latest create my-app --template payload

# Or with the global CLI installed.
pnpm add -g @systhemaui/cli
systhema create my-app --template payload
```

Run one scaffold command, then enter its output directory:

```bash
cd my-app
```

### 3. Install dependencies

```bash
pnpm install
```

### 4. Copy design tokens

Place exported token JSON files in `src/tokens/`. They come out of the [Figma plugin](https://docs.systhema.app/fr/design/figma.md).

### 5. Sync tokens and types

Synchronize the project's token files into the `@systhemaui/core` package, generate `payload-types.ts`, and rebuild Payload's `importMap.js`:

```bash
pnpm sync
```

The template's `sync` script chains together Systhema's sync, Payload type generation, and import-map generation. Re-run it whenever tokens, config, or `@systhemaui/*` packages change. Its install hook refreshes the package token cache when generated artifacts already exist. Otherwise, run `pnpm sync` before the first type check.

### 6. Start building

```bash
pnpm dev
```

You're ready to use Systhema components in your Payload + Next.js app.

## Replacing the placeholder branding

Everything the visitor sees ships with Systhema's mark as a **placeholder**. It's there so a fresh scaffold is never iconless, and so you have a checklist of what a real project needs. Replace all of it with the project's own branding before launch:

| File(s)                                                                  | What it is                                                                        |
| ------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| The `Logo` component in `src/app/(site)/template.tsx`                    | Header and footer logo                                                            |
| `src/app/icon.svg`                                                       | Browser tab icon, vector, swaps color with the visitor's light/dark theme         |
| `src/app/favicon.ico`                                                    | Legacy fallback (16/32/48px) for browsers without SVG favicon support             |
| `src/app/apple-icon.png`                                                 | iOS home-screen icon                                                              |
| `src/app/manifest.json`, `public/web-app-manifest-{192x192,512x512}.png` | Web app manifest and its `maskable` install icons, edit the name and theme colors |
| General Settings → SEO → default share image                             | The social/OG card image, set in the admin rather than as a file                  |

These are never overwritten by an upgrade. `(site)/template.tsx` is a scaffold file (user-owned, written once), and the favicons only ship with `systhema create`, so once you've replaced them, they stay replaced.

> [!NOTE]
> **The Payload admin is not a placeholder.** `admin.components.graphics.Logo` / `.Icon` (login logo, sidebar icon, and the front-end admin bar, which resolves the same `Icon`) and the admin favicon `public/systhema-icon.svg` (`admin.meta.icons`) are Systhema's own visuals and are meant to stay. Override them only when you're whitelabeling the admin for a client. Because they're Systhema's, an upgrade _does_ keep them current: the package components update with the dependency bump, and the `replace-admin-favicon` codemod refreshes the icon file, unless you've customized it, in which case your version is preserved.

To build the same project by hand and see what each piece does, follow [Install in a Payload project](https://docs.systhema.app/fr/getting-started/installation/payload.md).

## Ongoing maintenance

- Re-run `pnpm sync` (or the three sub-commands) after any design-system update.
- Keep your `GITHUB_TOKEN` active. Package installs fail immediately if it expires.
- Check in exported token inputs so every environment uses the same baseline.
- Run `systhema upgrade` when new Systhema versions ship, see [`@systhemaui/cli`](https://docs.systhema.app/fr/cli/upgrade.md).
- After upgrading `@systhemaui/payload`, the upgrade flow re-runs `pnpm systhema-core payload create-app-files --override` for you. Managed files use `.systhema/managed-files.json` to distinguish an old Systhema version from local edits. An edited managed file stays in place and the latest template appears beside it as `<path>.new`; scaffold files (your customized `layout.tsx`, `globals.css`, `template.tsx`, etc.) are left alone. Diff the files, merge the changes, and delete the `.new` file. The first differing pre-ledger managed file is backed up to `<path>.bak` before refresh, except a customized `src/proxy.ts`, which is kept with the template beside it as `src/proxy.ts.new`.

- For production builds and hosting, see [Deploying](https://docs.systhema.app/fr/guides/deploying.md).