Déployer une application depuis du code

Une application CODE est déployée à partir d'une image que vous avez buildée depuis votre dépôt (voir Builds). Cette page détaille tous les paramètres du déploiement.

Choisir le framework

Au déploiement, vous choisissez le framework correspondant à votre application. Ce choix applique des valeurs par défaut adaptées (port, ressources) que vous pouvez ajuster.

ℹ️ Certains frameworks attendent des variables d'environnement spécifiques (par exemple DJANGO_SETTINGS_MODULE pour Django, FLASK_APP pour Flask). Renseignez-les dans les variables d'environnement (ci-dessous).

Sites HTML statiques

Le template HTML statique sert un site de fichiers (HTML, CSS, JS) via Nginx, sans serveur applicatif. C'est le bon choix pour une landing page, une documentation générée ou un export de site.

Type de charge : web, worker ou cron

Toutes les applications ne servent pas du HTTP. Le champ Type de charge décrit comment la vôtre tourne :

ℹ️ Worker et cron ne servent pas de HTTP : ni port, ni exposition publique, ni health check HTTP. Ces champs disparaissent du formulaire quand vous choisissez l'un de ces types.

Pour un cron, renseignez la planification au format cron standard :

Port de l'application

Le port est pré-rempli selon le framework choisi. Modifiez-le si votre application écoute ailleurs.

Ressources

Les valeurs sont libres (pas de paliers imposés) mais plafonnées par les quotas du projet. Si le quota est insuffisant, le déploiement est refusé — ajustez les ressources ou le quota du projet.

💡 Les valeurs par défaut du framework sont des recommandations. Une API FastAPI démarre confortablement avec peu de ressources ; un Spring Boot ou un Django en demandent davantage.

Variables d'environnement et secrets

Deux catégories distinctes :

• Ajoutez/éditez les deux types à la création et plus tard via la mise à jour du déploiement.
• Les secrets sont chiffrés au repos et injectés à l'exécution — ils n'apparaissent ni dans les logs ni dans les réponses de l'API.

🔒 Mettez les identifiants de base de données (la chaîne DATABASE_URL récupérée d'un service managé) dans les secrets, pas dans les variables publiques.

Domaine et TLS

• Sous-domaine automatique : sans configuration, votre application est exposée sur une URL du type https://nom-xxxx.nubiecloud.io (le sous-domaine intègre la région pour les régions dédiées).
• Domaine personnalisé : renseignez un ou plusieurs domaines (séparés par des virgules) dans le champ Domaine. Le certificat TLS est obtenu et renouvelé automatiquement.

ℹ️ Les domaines sont déclarés individuellement (pas de wildcard pour l'instant). Voir Domaines & TLS pour la configuration DNS.

Health check

Nubiecloud surveille la santé de votre application :

• HTTP : renseignez un chemin de health check (ex. /, /health, /api/health). L'application est considérée saine si ce chemin répond correctement.
• TCP : laissez le chemin vide → seule l'ouverture du port est vérifiée.

Le chemin par défaut est /.

💡 Laisser le champ vide (contrôle TCP) est le réglage recommandé au démarrage : il vérifie simplement que votre application écoute. Renseignez un chemin quand vous voulez qu'une application qui répond mal soit détectée comme dégradée.

Configuration Nginx personnalisée

Pour les applications servies par Nginx (HTML statique, React, Vue.js, Next.js), la plateforme génère automatiquement une configuration adaptée — repli sur index.html pour les applications d'une seule page, redirection vers l'application pour Next.js.

Le champ Configuration nginx.conf personnalisée permet de la remplacer par la vôtre. Utile pour :

• des redirections spécifiques,
• des en-têtes HTTP personnalisés,
• une authentification basique.

ℹ️ Laissez le champ vide pour conserver la configuration automatique. Depuis la page de gestion d'un déploiement, vider le champ puis enregistrer remet la configuration par défaut.

Réplicas

Le champ Réplicas fixe le nombre d'instances de votre application (défaut : 1). Augmentez-le pour répartir la charge et améliorer la disponibilité.

ℹ️ Le scaling est manuel (nombre d'instances fixe) ; il n'y a pas d'autoscaling automatique pour l'instant.

Migrations de base de données

Pour exécuter des migrations (Django, Alembic, etc.) avant que l'application ne démarre :

💡 Laissez Bloquer si échec activé en production : une migration ratée ne doit pas livrer une version cassée.

Une fois activée, la migration s'exécute automatiquement avant chaque déploiement. Ses logs sont consultables dans l'onglet Logs du déploiement, section Migration.

Utiliser une autre image pour la migration

Par défaut, la migration tourne avec l'image de votre application. Cochez Utiliser une image différente pour la migration si vos outils de migration vivent ailleurs (une image plus complète, un conteneur d'outillage dédié).

Laisser ces champs vides revient à utiliser l'image principale de l'application.

Voir aussi

• Builds — produire l'image à déployer.
• Cycle de vie d'un déploiement — mise à jour, rollback, pause.
• Services managés — brancher une base de données.
• NubiStack — déployer plusieurs services et leurs bases en une seule fois.