Fonctionnalités
Ce que Kavio prend en charge une fois votre application importée, et ce qu'il ne prend délibérément pas en charge.
Ce qui est inclus
| Fonctionnalité | Ce que ça fait |
|---|---|
| Organisation | L'espace auquel appartiennent vos projets : son offre, son abonnement, ses membres |
| Variables d'environnement | Vos secrets et votre configuration, disponibles au démarrage et pendant la compilation |
| Base de données | Connexion à une base que vous hébergez ailleurs, via une simple variable |
| Domaine personnalisé | Votre propre nom de domaine à la place du sous-domaine attribué, certificat HTTPS compris |
| Logs | Le flux de sortie de votre application, en direct dans le dashboard |
| Déploiement automatique | Un déploiement à chaque push sur la branche suivie |
À quoi s'ajoutent, sans page dédiée parce qu'il n'y a rien à configurer : le certificat HTTPS émis et renouvelé automatiquement, l'historique des déploiements avec leur durée et leur statut, et le redémarrage de l'application sans reconstruire l'image.
Ce que Kavio ne fait pas
Autant le dire tout de suite, ces limites sont assumées :
- Aucune base de données fournie. Kavio héberge des applications, pas des bases. Vous branchez la vôtre, hébergée où vous voulez.
- Aucune ligne de commande. Tout passe par le site : import, variables, déploiements, logs. Il n'existe pas de commande
kavioà installer. - Pas de mise à l'échelle automatique. Vous choisissez la mémoire et le nombre d'instances de votre application ; rien ne varie tout seul avec le trafic.
- Pas d'environnements de préversion. Une branche suivie, une application en ligne. Les autres branches ne déploient rien.
Ressources et facturation
⚠️ Ce budget est celui de votre organisation, pas de votre compte. Si vous travaillez seul, cela revient au même : votre organisation a été créée avec votre compte et vous en êtes l'unique membre. La nuance compte le jour où vous partagerez un espace — le budget et le compteur d'instances sont alors communs.
Votre offre vous donne un budget de mémoire et de processeur, que vous répartissez entre vos applications comme vous l'entendez. Vous choisissez la mémoire, le processeur en est déduit proportionnellement.
Deux conséquences à connaître : le budget compte ce que vous réservez, pas ce que vous consommez — une application qui réserve 1 Go en occupe 1 Go dans votre décompte, même si elle en utilise 100 Mo. Et une application qui dépasse sa mémoire est arrêtée par le système sans laisser de trace dans les logs : si elle redémarre sans raison apparente, c'est la première piste.
Modifier les ressources d'une application ne reconstruit rien : le changement s'applique en quelques secondes, et n'apparaît pas dans l'historique des déploiements.
Instances : plusieurs copies d'une même application
À partir de l'offre Pro, vous choisissez combien d'instances de votre application tournent en parallèle. Deux instances se partagent le trafic, et surtout : votre application reste jointe pendant un déploiement, puisque les instances sont remplacées l'une après l'autre.
Une instance coûte deux choses, et c'est le point à retenir : sa part de mémoire, et une place de votre offre. Une application de 1 Go passée à 3 instances réserve 3 Go et occupe 3 des places incluses dans votre offre. Le scaling ne vous donne pas de ressources en plus — il redistribue celles que vous avez déjà.
C'est pour cette raison que votre offre compte des instances et non des projets : une offre à 6 instances, c'est 6 applications à une instance, 3 à deux instances, ou une seule à six.
⚠️ Deux instances supposent une application sans état partagé. Le disque de chaque instance lui est propre et disparaît à chaque déploiement : un fichier écrit par l'une est introuvable pour l'autre, et une session gardée en mémoire est perdue dès qu'une requête part sur l'autre instance. Pour tout ce qui doit durer, utilisez une base de données ou un stockage externe.
Sur l'offre Starter, chaque application tourne sur une instance.