Aller au contenu
duxt

Déployer un site

Où un site duxt peut tourner, ce qu’il lui faut là-bas, et pourquoi le contenu n’est pas rafraîchi à l’exécution.

Un site duxt est une application Nuxt. Tout ce qui exécute Nuxt l’exécute.

Étapes

  1. Préférez le statique. nuxt generate produit un dossier de HTML — pas de serveur, pas de coût d’exécution, chaque page mise en cache en périphérie. C’est le bon défaut pour de la documentation.
pnpm run generate

nuxt build produit un serveur Node, dont vous n’avez besoin que si une page doit réagir à une requête.

  1. Donnez à la compilation ce qu’il lui faut. Node 24 (la base de données est lue via node:sqlite, aucun pilote natif n’est donc installé), un accès réseau à toute source distante, et un jeton pour les dépôts privés.
  2. Indiquez l’origine. NUXT_PUBLIC_I18N_BASE_URL, ou i18n.baseUrl dans la configuration. Sans elle, hreflang, canonical, le sitemap et les cartes sociales retombent sur une sortie relative.
  3. Définissez un secret d’image OG si vous déployez plus d’une instance.NUXT_OG_IMAGE_SECRET, généré une fois. Sans lui, chaque compilation signe les URL d’image avec un secret qui lui est propre, et une carte signée par une instance est rejetée par la suivante.
  4. Planifiez une recompilation. Un site qui lit un autre dépôt en récupère les changements quand il compile, pas quand ils sont poussés.

Pourquoi il n’y a pas de rafraîchissement à l’exécution

Content télécharge un dépôt distant à la compilation et le compile dans la base de données que la compilation livre. Rafraîchir cela à l’exécution reviendrait à reconstruire la base à l’intérieur d’un serveur en fonctionnement — Content n’offre aucune voie prise en charge pour cela, et la seule disponible est la base de données client que lit la recherche. Une recompilation planifiée, ou déclenchée depuis le dépôt source, garde le déploiement immuable et le contenu reproductible.

Quand une compilation annonce database is locked

Content conserve son cache d’analyse dans .data/content/contents.sqlite, et une compilation que le noyau ou un Ctrl-C a laissée derrière lui peut continuer à le retenir. Chaque compilation suivante échoue alors avec database is locked — un message qui ne nomme ni le fichier ni le processus.

duxt place cette base de données en mode WAL avant que Content ne l’ouvre, ce qui permet à un lecteur et à un rédacteur de coexister et supprime entièrement la version quotidienne du problème. Ce qu’il ne peut pas supprimer, c’est un second processus toujours en cours :

pgrep -af 'nuxt (build|dev|generate)'   # le processus orphelin, s’il y en a un
kill <pid>

Si rien n’apparaît et que l’erreur persiste, supprimez .data/content/ : c’est un cache, et la compilation suivante le reconstruit à partir des sources.

Ce que le site sert en plus des pages

/llms.txt, /llms-full.txt, le source .md de n’importe quelle page, /mcp, /sitemap.xml, /robots.txt et — une fois configuré — /rss.xml. La liste complète avec ses réserves est dans la référence des points de terminaison.

Liste de contrôle

  • nuxt generate se termine sans erreur du validateur
  • L’origine est définie dans le déploiement, pas seulement en local
  • /sitemap.xml liste des URL absolues sur le vrai domaine
  • Une recompilation est planifiée, ou déclenchée depuis chaque dépôt source
  • NUXT_OG_IMAGE_SECRET est défini si plus d’une instance sert le site
Cette page vous a-t-elle été utile ?