Déploiement¶

La production tourne sur Dokploy, dans le projet « todos », environnement production.

flowchart LR
    G["GitHub<br/>DuncanCos/todolist (main)"]
    subgraph D["Dokploy : projet todos / production"]
        B["Backend<br/>Nixpacks, /todoback/<br/>port 8080"]
        F["frontend<br/>Railpack, /todofront/<br/>port 80"]
        P[("postgres<br/>base todos")]
    end
    I["Internet"]

    G -- "push (autoDeploy)" --> B
    G -- "push (autoDeploy)" --> F
    B --> P
    I -- "https://api.todo.dunkan.xyz" --> B
    I -- "https://todo.dunkan.xyz" --> F

Applications¶

Le rôle de chaque variable est décrit dans Développement.

Backend¶

• Le port d'écoute est codé en dur (0.0.0.0:8080) : le domaine Dokploy doit pointer sur le port 8080.
• Les 3 variables sont obligatoires : s'il en manque une, le binaire panique au démarrage.
• DATABASE_URL doit viser la base Dokploy « postgres » (base todos), de préférence via son URL de connexion interne.

frontend¶

• VITE_BACKEND_URL doit contenir l'URL publique de l'API (https://api.todo.dunkan.xyz), puisque c'est le navigateur qui l'appelle.
• VITE_CLERK_PUBLISHABLE_KEY doit appartenir à la même application Clerk que la CLERK_SECRET_KEY du backend, sinon toutes les requêtes finissent en 401.
• Les variables VITE_* sont figées au build : après les avoir modifiées, il faut redéployer (rebuild) l'application, un simple redémarrage ne suffit pas.

Base de données¶

CORS¶

Le front (todo.dunkan.xyz) et l'API (api.todo.dunkan.xyz) sont sur des origines différentes : le navigateur exige des en-têtes CORS. Ils sont définis dans todoback/src/routes/mod.rs :

Points importants :

• L'origine doit correspondre exactement (schéma + hôte + port, sans / final). Changer le domaine du front impose de modifier cette liste et de redéployer le backend.
• La couche CORS est ajoutée après ClerkLayer, elle s'exécute donc avant elle. Les requêtes préliminaires OPTIONS, envoyées sans jeton, reçoivent ainsi une réponse CORS au lieu d'un 401, et les 401 portent eux aussi les en-têtes CORS.
• Avec allow_credentials(true), tower-http refuse les jokers (Any) pour les origines, méthodes et en-têtes, et panique au démarrage. Il faut des listes explicites.

Vérification du préflight :

curl -i -X OPTIONS https://api.todo.dunkan.xyz/todo/todo \
  -H "Origin: https://todo.dunkan.xyz" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: authorization,content-type"

Réponse attendue : 200 avec access-control-allow-origin: https://todo.dunkan.xyz, access-control-allow-credentials: true, access-control-allow-headers: authorization,accept,content-type et access-control-allow-methods: GET,POST,PUT,DELETE,OPTIONS.

Redéployer¶

curl -X POST "<url-dokploy>/api/application.deploy" \
  -H "x-api-key: <jeton-api>" \
  -H "Content-Type: application/json" \
  -d '{"applicationId": "<id-de-l-application>"}'

Que redéployer ?

Vérifier après un déploiement¶

# API en ligne : 401 attendu sans jeton
curl -i https://api.todo.dunkan.xyz/todo/todo

# Front en ligne : 200 attendu
curl -I https://todo.dunkan.xyz

Puis, dans le navigateur, se connecter sur https://todo.dunkan.xyz et créer une tâche de test.

Dépannage¶

Les logs de l'API (requêtes, réponses et erreurs SQL) sont consultables dans l'onglet Logs de l'application Backend sur Dokploy.