Aller au contenu

Déployer

Déployer votre site.

Un site Kreiz se compose de deux parties : un site public prérendu, entièrement statique — et un petit serveur pour le back-office et les endpoints publics. Vercel est la cible de référence, l'adaptateur est fourni.

La forme du déploiement

Le partage est net, et il explique tout le reste :

  • Statique — pages publiques, sitemap.xml,robots.txt et beacon analytics : prérendus au build, servis par le CDN, sans serveur.
  • Serveur — /admin/* et /api/* : une fonction unique couvre le back-office, la réception des formulaires et la collecte analytics.

Côté hébergeur, vous fournissez la base PostgreSQL (Neon recommandé) et, optionnellement, le stockage des médias (S3, R2, MinIO) et le relais email. Le reste appartient au Core.

Les variables de production

Elles se configurent dans l'hébergeur (dashboard Vercel ou CLI). Les groupes optionnels sont tout-ou-rien : sans stockage, la médiathèque est simplement indisponible ; sans relais, les demandes restent dans l'admin.

VariableÀ quoi elle sert
KREIZ_DATABASE_URLLa base PostgreSQL du site en production. Utilisée par le back-office, la CLI et le build.
KREIZ_SECRETClé de signature (sessions, jetons de formulaire). Unique par déploiement (openssl rand -base64 32), présente au build et au runtime.
KREIZ_REBUILD_DEPLOY_HOOK_URLLe deploy hook Vercel : chaque publication déclenche la reconstruction du site public.
KREIZ_STORAGE_*Optionnel — stockage S3-compatible des médias, plusKREIZ_STORAGE_PUBLIC_BASE_URL (CDN des variantes) dès qu'une image est publiée.
KREIZ_MAIL_*Optionnel — relais email des notifications de contact. Persistance d'abord, notification ensuite : une panne ne perd jamais une demande.
KREIZ_MAINTENANCE_TOKENOptionnel — autorise le cron de maintenance à appelerPOST /api/maintenance. Sans valeur, l'endpoint refuse tout.

La référence exhaustive — chaque variable, défauts, dev vs production — est dans leguide de configuration (ouvre GitHub dans un nouvel onglet).

Le cycle de publication

  1. Vous publiez dans l'admin

    Le contenu courant est validé puis figé dans un snapshot public. Le bouton « publier » appelle le deploy hook.

  2. Le site se reconstruit

    Le build lit uniquement les snapshots publiés — jamais les brouillons — et régénère les pages, le sitemap et les redirections 301.

  3. Le site servi ne bouge qu'avec un build réussi

    Un build raté ne change rien en ligne : la version précédente reste servie, la base garde tout, et vous relancez depuis l'admin.

La maintenance récurrente

Les rétentions (analytics, demandes de contact) et les récupérations (notifications en attente, médias bloqués) attendent un déclencheur externe : un appel du cron à POST /api/maintenance toutes les 30 minutes environ, authentifié parKREIZ_MAINTENANCE_TOKEN. Une GitHub Action planifiée ou n'importe quel planificateur capable d'un POST authentifié suffit.

Le tableau complet des récupérations et leurs fréquences sont dans leguide d'exploitation (ouvre GitHub dans un nouvel onglet).

Checklist avant mise en ligne

  • Base PostgreSQL dédiée à la production
  • KREIZ_SECRET unique, présent au build et au runtime
  • Deploy hook branché — sinon les publications ne reconstruisent pas le site
  • Stockage branché si vous publiez des médias
  • Relais email branché si vos formulaires doivent notifier
  • Cron de maintenance en place
  • Premier administrateur créé, mot de passe robuste
  • Base canonique SEO déclarée — le Core n'invente jamais une URL