Démarrage rapide

Créer un nouveau projet

pnpm dlx @rebasepro/cli init my-app

Cela génère un projet contenant trois packages. Si l’un des termes collection, Studio, managed runtime, bundle ou resource vous est inconnu, l’encadré en cinq points sur la page Structure du projet les définit.

Dossier	Description
frontend/	SPA React — Vite + TypeScript avec l’interface d’administration Rebase
backend/	Vos fonctions personnalisées et crons, ainsi que le schéma Drizzle généré. Il n’y a pas de fichier serveur — le runtime publié démarre le projet
config/	Fichiers de configuration et définitions de collections partagés par les deux parties

Prérequis

• Node.js 22.22+ — chaque modèle généré, y compris headless, déclare "node": ">=22.22.0"
• pnpm (recommandé) ou npm

Aucune base de données à installer, et pas de Docker. rebase dev exécute un PostgreSQL géré pour le projet, avec ses données stockées sous .rebase/. Consultez Variante : utiliser votre propre PostgreSQL si vous préférez en fournir un — une installation locale, Neon, Supabase, ou le conteneur fourni avec ce scaffold.

Votre environnement est déjà configuré

init génère un fichier .env prêt à l’emploi à la racine du projet avec un vrai JWT_SECRET, un mot de passe de base de données et un port local libre pour la base de données. Vous n’avez rien besoin de créer ou de modifier pour commencer.

Attention

N’exécutez pas cp .env.example .env. .env.example est une référence pour les variables disponibles — le copier sur votre .env écraserait les secrets générés et ferait pointer DATABASE_URL vers une base de données inexistante. Modifiez directement .env si vous souhaitez changer une valeur.

Démarrer les serveurs de développement

pnpm install
pnpm run dev

C’est tout pour le premier lancement. Il n’y a aucune base de données à installer ni d’étape de schéma : sans DATABASE_URL défini, rebase dev démarre un PostgreSQL géré (PGlite) dans le répertoire du projet, génère le schéma Drizzle à partir de vos collections et crée les tables au démarrage — y compris les exemples posts, authors et tags.

Il démarre les deux parties ensemble :

• Backend — API REST, authentification, stockage, WebSocket
• Frontend — le panneau : Rebase CMS et Rebase Studio
• Rechargement à chaud (Hot reload) pour les deux

Les deux ports sont dérivés du chemin de ce projet plutôt que d’être fixes, ce qui permet à plusieurs projets Rebase de fonctionner côte à côte. rebase dev affiche les deux URL associées — utilisez celles-ci, et non localhost:3001 / localhost:5173. (PORT et VITE_API_URL dans .env configurent rebase start, qui exécute le bundle compilé, et sont ignorés ici.) Fixez un port avec rebase dev --port 3001.

Options utiles à connaître

Option	Commande	Ce qu’elle fait
--yes	init	Ne jamais poser de questions. Requis lorsqu’aucun terminal n’est disponible pour répondre, comme en CI. Ignore git init et l’installation des dépendances — les valeurs par défaut interactives répondent oui aux deux, passez donc --git / --install si vous les souhaitez
--headless	init	Un backend sans fichiers de collections et sans interface utilisateur — voir Backend seul
--template <name>	init	Démarrer à partir d’un autre template que celui par défaut
--install / --no-install	init	Exécuter le gestionnaire de paquets pour vous, ou l’ignorer
--docker	dev	Utiliser PostgreSQL dans un conteneur au lieu de l’instance gérée. Depuis 0.25 Les autres commandes la suivent jusqu’à ce que rebase dev soit lancé sans elle. Un DATABASE_URL l’emporte sur elle : elle ne démarre alors rien, et le dit
--no-db	dev	Ne démarrer aucune base de données — ni le conteneur ni l’instance gérée. Définissez DATABASE_URL vous-même

Variante : utiliser votre propre PostgreSQL

La base de données gérée est une commodité, pas une obligation. Pour faire pointer le projet vers un Postgres que vous gérez, décommentez DATABASE_URL dans .env :

DATABASE_URL=postgresql://username:password@localhost:5432/your_database

Démarrez ensuite les serveurs de développement comme ci-dessus. Une variable DATABASE_URL définie n’est jamais modifiée, et si elle pointe ailleurs que sur cette machine, elle est totalement laissée intacte.

Les commandes de migration planifient les modifications avec Atlas, le moteur de migration de schéma avec lequel Rebase fonctionne, qui nécessite une seconde base de données vide pour comparaison. Sur votre propre base de données, Rebase en crée une à côté ; sur la base gérée, qui n’en dessert qu’une seule, il démarre un PGlite jetable pendant la durée de la commande. Depuis 0.25 En 0.24, les commandes de migration refusent la base gérée et exigent la vôtre. Dans les deux cas :

pnpm run db:push

Le démarrage crée déjà les tables manquantes — et leurs politiques RLS (Row-Level Security de PostgreSQL, mécanisme par lequel Rebase contrôle qui peut lire une ligne) — de manière additive, donc db push sert pour ce qu’il laisse délibérément de côté : toute modification qui n’est pas purement additive — une colonne renommée, un type restreint, un champ supprimé.

Le scaffold fournit également un fichier docker-compose.yml avec un service PostgreSQL, si vous préférez un conteneur à une installation locale de Postgres :

docker compose up -d db

Introspecter une base de données existante (Optionnel)

Si vous vous connectez à une base de données existante contenant déjà des tables, vous pouvez l’introspecter pour générer automatiquement vos fichiers de collections TypeScript :

pnpm rebase schema introspect

Cela analysera les tables de votre base de données et générera les fichiers TypeScript correspondants dans config/collections/ afin que vous n’ayez pas à les écrire manuellement.

Première connexion

Lorsque vous ouvrez l’URL frontend affichée par rebase dev, vous verrez l’écran de connexion. Le premier utilisateur à s’inscrire devient automatiquement administrateur — c’est le flux d’initialisation (bootstrap).

1. L’écran s’ouvre sur Welcome!, le formulaire de ce premier compte
2. Entrez votre email et votre mot de passe, puis cliquez sur Create account
3. Vous êtes connecté — avec un accès administrateur complet

rebase init a également inscrit REBASE_ADMIN_EMAIL et un mot de passe généré REBASE_ADMIN_PASSWORD dans le fichier .env. Ce ne sont pas vos identifiants ici : rebase dev les ignore et l’indique au démarrage. Ils sont destinés à un démarrage en production — docker compose up, ou tout environnement avec NODE_ENV=production — où cette fenêtre d’initialisation est fermée, car le serveur répond sur un nom d’hôte avant même que vous n’ayez saisi quoi que ce soit. Voir Votre premier administrateur.

Définir votre première collection

Ouvrez config/collections/ et créez un nouveau fichier. Exportez la collection en tant qu’export par défaut — c’est ce que le backend et le panneau d’administration chargent depuis chaque fichier du répertoire. Le nom de la table est optionnel : il utilise par défaut le slug, ne le définissez donc que lorsqu’ils diffèrent :

import { defineCollection } from "@rebasepro/cms-types";

const productsCollection = defineCollection({
    slug: "products",
    name: "Products",
    properties: {
        name: {
            type: "string",
            name: "Name",
            validation: { required: true }
        },
        price: {
            type: "number",
            name: "Price",
            validation: { required: true, min: 0 }
        },
        description: {
            type: "string",
            name: "Description",
            admin: { multiline: true }
        },
        active: {
            type: "boolean",
            name: "Active",
            defaultValue: true
        },
        createdAt: {
            type: "date",
            name: "Created At",
            autoValue: "on_create"
        }
    }
});

export default productsCollection;

Ajoutez-la ensuite au tableau collections dans config/collections/index.ts. Ce tableau est un ordre de tri, pas un registre : chaque fichier de collection du répertoire est chargé — par le backend, le panneau d’administration et le générateur de SDK — qu’il figure ou non dans le tableau, et le tableau décide seulement de sa place dans la navigation. Pour supprimer une collection, supprimez son fichier :

// ...existing imports
import productsCollection from "./products.js";

export const collections = [
    postsCollection, authorsCollection, tagsCollection, usersCollection, productsCollection
];

Créer la table

Enregistrez le fichier. C’est tout ce qu’il y a à faire : rebase dev régénère backend/src/schema.generated.ts et les types du SDK dans generated/sdk/ à partir de vos collections, redémarre le backend, et le démarrage crée la nouvelle table — votre collection Products apparaît alors dans la navigation.

Sur la 0.23, rebase dev ne régénère que le schéma, exécutez donc rebase generate-sdk après une modification de collection avant d’importer ses types.

Il en va de même pour une propriété ajoutée à une collection existante : sauvegardez, et la colonne est créée.

rebase db push est réservé aux modifications que le démarrage ignore délibérément — une colonne renommée, un type restreint, un champ supprimé :

pnpm run db:push

Depuis 0.25 Elle s’exécute sur la base gérée comme sur la vôtre. En 0.24, elle exige votre propre PostgreSQL.

Référence des commandes de base de données

Commande	Description
rebase schema generate	Génère le schéma Drizzle à partir de vos collections TypeScript. Aucune base de données requise — rebase dev l’exécute pour vous
rebase schema introspect	Génère des collections TypeScript à partir d’une base de données existante
rebase db push	Applique directement les changements de schéma à la base de données, y compris la base gérée
rebase db generate	Génère les fichiers de migration SQL
rebase db migrate	Exécute les migrations en attente

Depuis 0.25 Les trois commandes db fonctionnent sur la base gérée. En 0.24, elles exigent votre propre PostgreSQL.

Étapes suivantes

• Structure du projet — Comprendre le code généré
• Collections — Découvrir en détail la définition de schémas
• Environnement & Configuration — Toutes les options de configuration
• Déploiement — Déployer en production