Liste de vérification pour la production (PRO) · Documentation

Starter ProProduction

Valider la fondation avant le lancementLien vers la section

Utilisez le Guide de couverture automatique pour vérifier ce qui est vérifié avec des données synthétiques. Exécuter pnpm ops:diagnose, vérifier /api/readiness, connectez le signaux opérationnels à votre surveillance et répéter une restauration vérifiée avant de conserver les données client. Configurez vos propres quotas si votre offre a besoin de plafonds; les valeurs par défaut ne sont pas plafonnées et la facturation reste personnelle.

Starter Pro vous donne la base adaptées à la production.

Cette liste de contrôle vous aide à valider cette base avant d’exposer le produit à de vrais utilisateurs, à de vrais paiements et à de vraies données client.

Un SaaS prêt pour le lancement ne devrait pas seulement "construire avec succès".

Il devrait valider :

Authentification
facturation
Répétition backend
Routes protégées
livraison sécurisée
variables d'environnement
Comportement de déploiement
chemins de récupération
acheteur confiance

C’est prêt quand les systèmes sont d’accord.

Auth identifie l'utilisateur. La facturation confirme le client. Le backend protège les données. La livraison complète l'achat.

Guide de configuration

Paiement unique — Accès instantané après achat

Règle de production

Ne lancez pas car l'interface semble terminée. Lancer lorsque les systèmes critiques se comportent correctement.

Ce que couvre cette checklistLien vers la section

Res

Sessions, fournisseurs, réinitialisation des flux, vérification et routes protégées.

Facturation

Checkout, portail, webhooks, factures, abonnements et accès.

Backend

Base de données, propriété, migrations, règles de serveur et données de produit.

Modèle de préparation au lancementLien vers la section

La préparation de la production n'est pas un contrôle. C’est l’alignement de l’identité, du paiement, des données, de l’accès et de la livraison.

Couche	Question de production
Res	Les utilisateurs réels peuvent-ils se connecter en toute sécurité et récupérer l'accès?
Facturation	Les vrais clients peuvent-ils payer et avoir un état synchronisé?
Backend	Les données produits peuvent-elles persister avec les règles de propriété et d'accès ?
Livraison	L'accès payant peut-il être effectué en toute sécurité après l'achat?
Environnement	Les secrets de production sont-ils complets et séparés du local/test ?
Déploiement	La production se comporte-t-elle comme le flux validé local ?

Principe Go-Live

Une liste de contrôle de production devrait vérifier le comportement, pas seulement la configuration.

Liste récapitulativeLien vers la section

Valider les variables d'environnementLien vers la section

Vérifiez que les environnements locaux, de prévisualisation et de production sont séparés.

.env.production

NEXT_PUBLIC_APP_URL=
DATABASE_URL=
AUTH_SECRET=

AUTH_GITHUB_ID=
AUTH_GITHUB_SECRET=
AUTH_GOOGLE_ID=
AUTH_GOOGLE_SECRET=

STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
STRIPE_PRICE_STARTER_PRO_ONE_TIME=

RESEND_API_KEY=
AUTH_EMAIL_FROM=

Les secrets de production ne doivent pas réutiliser les valeurs de test locales à moins que le système ne soit intentionnellement encore en mode test.

Valider l'authentificationLien vers la section

Testez le cycle de vie complet de l'auth :

identifiants de connexion
OAuth se connecter
enregistrement
e-mail vérification
mot de passe oublié
réinitialiser le mot de passe
changement de mot de passe
route protégée redirige
navigation de session-conscient
Comportement du compte connecté

Valider la facturationLien vers la section

Testez le cycle de vie complet de Stripe :

Création de session de paiement
Paiement réussi
Paiement annulé
session du portail de facturation
vérification de signature webhook
abonnement créé événement
Abonnement événement mis à jour
Abonnement annulé
facture paiement réussi événement
facture paiement événement échoué

Valider le backend et l'accèsLien vers la section

Confirmez que les données du produit ne sont pas seulement affichées, mais protégées correctement :

Migrations exécutées
Le client de base de données est généré
Les données de données d’exemple ne fonctionnent que là où elles sont attendues
travail de contrôle de propriété
Les données protégées nécessitent une session
Les fonctionnalités payantes nécessitent un état de facturation valide
Les règles côté serveur correspondent à l'état de l'interface utilisateur

Valider une livraison sécuriséeLien vers la section

Si votre produit inclut des téléchargements payants ou l'exécution, testez :

confirmation de paiement
mappage achat-accès
stockage de biens privés
télécharger token creation
Expiration du token
comportement d'accès non autorisé
Récupération de session interrompue

Valider le déploiement de la productionLien vers la section

Construire et déployer intentionnellement.

terminal

pnpm build
pnpm start

Puis validez l'URL de production :

/login
/register
/dashboard
/billing
/settings
Flux d'accès payants
webhook endpoint

Autre checklistLien vers la section

Requis

Comportement auth requis

Confirmez que l'authentification fonctionne de bout en bout pour les utilisateurs réels avant le lancement.

Les utilisateurs peuvent s'inscrire
Les utilisateurs peuvent se connecter
Les utilisateurs peuvent se déconnecter
Les sessions persistent correctement
Les routes protégées redirigent les utilisateurs anonymes
Les utilisateurs authentifiés n'ont pas besoin de pages d'authentification inutiles

Sécurité

Contrôles de sécurité

Validez la récupération, le fournisseur et le comportement d'erreur avant que le produit n'atteigne les utilisateurs réels.

mot de passe oublié ne révèle pas si un e-mail existe
reset tokens expirent
La déconnexion du fournisseur ne peut pas bloquer les utilisateurs
La validation côté serveur existe pour les actions auth
Les messages d'erreur sont utiles mais pas trop spécifiques

Autres contrôles UX

Auth devrait se sentir calme, prévisible et clair à travers le chargement, l'erreur et les états de succès.

Les états de chargement sont visibles
les formulaires désactivent l'envoi pendant le traitement
les erreurs sont au niveau du terrain lorsque cela est possible
Les erreurs d'authentification globales sont claires et calmes
Le succès explique la prochaine étape

Liste de contrôle de facturationLien vers la section

Checkout

Checkout checks

Validez les points d'entrée de paiement et la création de session Stripe avant utilisation en production.

Les sessions de paiement sont créées sur le serveur
L'URL de succès fonctionne
Annuler l'URL fonctionne
La association des comptes aux clients Stripe est correcte
test et les prix de production ne sont pas mélangés

Webhooks

Vérifications Webhook

L'état du Webhook doit être vérifié, idempotent et reflété correctement dans votre application.

Les signatures webhook sont vérifiées
Les événements sont traités idempotently
abonnement create/update/delete events sync correctement
facture paiement événements mise à jour état de facturation
Les paiements échoués montrent un état clair du produit

Accès

Vérifications d'accès à la facturation

L'accès payant devrait dépendre de l'état de facturation du backend synchronisé, et pas seulement de l'interface client.

Les fonctionnalités payantes nécessitent un accès actif
Les abonnements annulés suppriment l'accès lorsque cela est approprié
l'état passé-due est traité clairement
La page de facturation reflète l'état du backend synchronisé
l'accès au portail est uniquement disponible pour le client correct

Liste de contrôle backendLien vers la section

Vérifier	Pourquoi c'est important
Les migrations se déroulent proprement	Empêche le déploiement de la production cassée
Le client Prisma est généré	Assure l'accès à la base de données typée
Les modèles sont présents	Supporte les sessions et les comptes
Les modèles de facturation sont présents	Prend en charge les abonnements et les factures
Les contrôles de propriété existent	Protège les données utilisateur
Les vérifications de plan sont vérifiables par le serveur	Empêche le contrôle d'accès client uniquement
Les événements Webhook sont suivis	Réduit le risque de traitement en double
Les données spécifiques à l'environnement sont séparées	Évite le mélange test et production

Principe de backend

Si une règle affecte l'argent, l'identité ou les données privées, elle ne devrait pas se limiter au frontend.

Liste de contrôle de livraisonLien vers la section

Utilisez cette option si la livraison Starter Pro ou un autre flux de produits numériques payant est actif.

Vérifier	Comportement requis
Le paiement est confirmé par webhook	L'accès n'est pas accordé à partir de la redirection seule
Le téléchargement de l'actif est privé	Pas d'URL de fichier public permanent
Le token de livraison existe	L'accès peut être contrôlé
Le token expire	Les liens partagés ont une valeur limitée
L'accès non autorisé est refusé	Les non-acheteurs ne peuvent pas télécharger
Le chemin du token expiré est géré	L'acheteur a un chemin de récupération
La copie de confirmation est claire	L'acheteur sait ce qui se passe ensuite

Go / no-go decisionLien vers la section

Ready to launch when

Les flux d'authentification passent de bout en bout
webhooks de facturation synchronisent l'état correctement
les routes protégées imposent l'accès correctement
Les migrations de base de données sont stables
La livraison est sécurisée et testée

Do not launch if

checkout fonctionne mais les webhooks ne sont pas testés
l'accès est accordé à partir de l'état client uniquement
les flux de réinitialisation de mot de passe ou de vérification sont rompus
Les secrets de production sont incomplets
Les fichiers payants sont exposés publiquement

Erreurs courantesLien vers la section

Séquence finale de pré-lancementLien vers la section

Avant le lancement, parcourez cette dernière séquence :

Déployer vers Preview
exécuter auth flows
lancer Stripe test checkout
vérifier les événements webhook
confirmer les mises à jour de la base de données
Confirmer l'état d'accès payant
Tester les routes protégées
accès de livraison de test
examiner les variables d'environnement de production
déployer la production
Faire un test final de fumée

Lancement en toute confiance

Un lancement fort n'est pas seulement une interface utilisateur propre. C'est un produit où l'identité, les revenus, les données et l'accès se comportent correctement ensemble.

Lancer lorsque les systèmes critiques sont d'accord.

Starter Pro vous donne les bases, mais la préparation de la production vient de la validation de l'authentification, de la facturation, du backend, de la livraison et du déploiement ensemble.

Voir les tarifs