Cet article contient une liste de frameworks et de langages ainsi que des informations indiquant s’ils fonctionnent avec l’hébergement d’applications et l’hébergement de bases de données Kinsta.

Si vous ne voyez pas le framework ou le langage que vous souhaitez utiliser dans cette liste, veuillez contacter nos équipes de vente ou de support.

Adobe Content Server

Peut-être. L’hébergement d’applications et de bases de données ne prend actuellement pas en charge les applications qui nécessitent un stockage persistant. Si Adobe Content Server a besoin d’un stockage persistant sur disque, nous ne pouvons actuellement pas l’héberger. Dans le cas contraire, nous pouvons l’héberger mais ne pouvons pas fournir de support technique.

Applications Angular

Oui. Nous pouvons héberger des applications Angular ; toutefois, vous devez suivre le guide Hébergement de sites statiques.

En particulier, les sites statiques nécessitent un script appelé start dans leurs fichiers package.json et utilisent le package serve pour servir leurs actifs statiques. (index.html, styles, polices, images). Similaire au référentiel Gatsby hello world.

ASP.NET

Oui. Les utilisateurs peuvent exécuter des applications construites avec Dotnet Core. DotNet Core peut être exécuté dans des conteneurs Linux ; voir cet exemple.

.NET évolue vers un environnement Core/Cross-platform supported/cloud-ready. Le hub Docker du moteur d’exécution ASP.NET Core contient quelques conteneurs Docker pré-construits pour Core, et les échantillons .NET contiennent quelques exemples d’utilisation des configurations typiques MS SQL + ASP.NET Core avec Docker compose.

Astro

Oui. Nous avons un repo GitHub d’exemples de démarrage rapide pour Astro.

Cascade CMS

Peut-être. Vous pourriez être en mesure d’héberger Cascade CMS avec un Dockerfile, il y a un dépôt GitHub, mais cela nécessite beaucoup d’ajustements. Vous devrez savoir comment écrire des Dockerfiles et comprendre les exigences techniques de Cascade CMS. Kinsta ne peut pas fournir de support technique pour cela.

CodeIgniter

Oui. CodeIgniter est une application basée sur PHP, donc pendant le processus de déploiement, Kinsta installe automatiquement les dépendances définies dans votre fichier composer.json.

commercetools

Oui. commercetools utilise Java, JavaScript et PHP et peut être utilisé sur l’hébergement d’applications.

Répliques de base de données

Non. Nous ne fournissons pas actuellement de répliques de base de données.

Adresses IP dédiées

Non. Nous ne fournissons pas d’adresses IP dédiées. Chaque nouveau déploiement peut avoir un pod programmé sur un hôte différent, ce qui entraine une adresse IP différente. Un changement d’adresse IP peut également se produire si Kubernetes doit déplacer un pod vers un autre hôte en raison de la consommation de ressources ou si le pool de nœuds sur lequel il se trouve est en cours de mise à niveau.

Deno

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Deno.

Accès SSH direct aux pods

Non. Nous ne fournissons pas actuellement d’accès SSH direct aux pods ; cependant, c’est quelque chose que nous espérons développer à l’avenir. Pour une base de données, vous pouvez utiliser des connexions externes pour accéder aux données.

Django

Oui. Nous avons un repo GitHub d’exemples de démarrage rapide pour Django. Vous pouvez suivre ce guide sur la mise en place d’une application Django à Kinsta.

Docusaurus

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Docusaurus. Vous pouvez suivre notre guide sur la mise en place d’un site statique avec Docusaurus.

Flask

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Flask.

Flutter

Oui. Si l’application Flutter est une application web et possède un Dockerfile, vous pouvez l’héberger sur l’hébergement d’applications.

Gatsby

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Gatsby.

Go

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Go.

Applications headless telles que sanity.io

Oui. Le backend utiliserait la plateforme Sanity et le frontend ReactJS.

Pour que cela fonctionne sur l’hébergement d’applications, vous devez modifier les scripts dans package.json dans le projet Sanity pour qu’ils ressemblent à ceci :

"scripts": {
"dev": "npx -y @sanity/cli start",
"build": "npx -y @sanity/cli build",
"start": "npx -y serve dist"
},

Vous devez également ajouter le nom de domaine temporaire MyKinsta (their-app-name.kinsta.app) qui est attribué à l’application dans les réglages d’origine project/API/CORS.

Régénération statique incrémentielle sur Next.js

Oui. Cela fonctionne sur l’hébergement d’applications ; pour plus d’informations sur la configuration de l’application, veuillez vous reporter à cet article de Next.js.

Jamstack

Oui. Nous avons les exemples de dépôts GitHub suivants :

Java

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Java.

Joomla

Peut-être. L’hébergement d’applications ne prend en charge que les applications sans état, et Joomla n’a pas été conçu pour être utilisé dans un environnement sans état. Cependant, il est techniquement possible d’exécuter Joomla comme une application sans état. Il existe une extension qui peut stocker les fichiers statiques sur S3, et il existe une image docker officielle de Joomla.

Laravel

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour Laravel.

Magento

Non. Magento nécessite un stockage sur disque persistant, que nous ne proposons pas actuellement dans le cadre de l’hébergement d’applications.

Mastadon

Peut-être. Il est possible d’exécuter Mastadon sur l’hébergement d’applications, mais comme il nécessite beaucoup de ressources, le coût d’exécution peut être élevé. Vous aurez probablement besoin du pod de 4 Go car il utilise ~1,5 Go de RAM. Il n’y a pas non plus de stockage persistant pour l’instant, donc si votre pod est cyclique ou déplacé, il devra tout récupérer à nouveau. Les pods ne redémarrent pas souvent, mais lorsqu’ils le font, le système de fichiers se réinitialise sur le système de fichiers du conteneur d’origine.

Applications mobiles

Peut-être. Cela dépend de l’application ; vous pouvez héberger le backend d’une application mobile avec l’hébergement d’applications, mais pas la construction ou la distribution de l’application mobile elle-même.

MODX

Peut-être. MODX est une plateforme CMS PHP à code source ouvert, mais elle peut nécessiter un stockage permanent que l’hébergement d’applications ne prend pas en charge actuellement. Si le site peut être utilisé sans stockage permanent, il peut être hébergé sur un hébergement d’applications.

Moodle

Non. Moodle a besoin d’un stockage/volume persistant pour fonctionner correctement ; il ne peut pas fonctionner comme une application sans état (où aucun fichier critique n’est écrit dans le système de fichiers pour que l’application puisse fonctionner correctement). Cela signifie que nous ne pouvons pas le supporter, car chaque déploiement effacerait certaines données sur lesquelles Moodle s’appuie.

MSSQL

Non. MSSQL nécessite un stockage persistant, que nous ne proposons pas actuellement dans le cadre de l’hébergement d’applications. Lorsque le stockage persistant sera disponible dans l’hébergement d’applications, il devrait être possible de l’exécuter, selon cet article.

n8n

Oui. Selon la documentation de Docker n8n, elle recommande le stockage persistant comme meilleure pratique, mais il n’est pas explicitement requis :

« Il est important de continuer à faire persister les données dans le répertoire /root/.n8n car il contient les données des utilisateurs de n8n et, plus important encore, la clé de chiffrement des informations d’identification… …Faire persister le répertoire /root/.n8n même en utilisant des bases de données alternatives est la meilleure pratique recommandée, mais n’est pas explicitement requis. »

Par conséquent, il devrait fonctionner sur l’hébergement d’applications sans stockage persistant si vous utilisez une base de données, aussi ; cependant, il fonctionnera mieux lorsque le stockage persistant est disponible dans l’hébergement d’applications.

NodeJS

Oui. Nous avons les dépôts GitHub d’exemples de démarrage rapide suivants pour NodeJS :

Nous avons différents guides que vous pouvez suivre :
Configurer une application Node.js
Configurer une application Node.js avec un Dockerfile
Configurer une application Node.js pour envoyer des e-mails

NuxtJS

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour NuxtJS.

PHP

Oui. Nous avons le dépôt GitHub d’exemple de démarrage rapide suivant pour PHP :

Vous pouvez suivre ce guide sur la façon de configurer une application PHP chez Kinsta.

Prestashop

Non. Le fichier officiel docker-compose spécifie un volume de stockage persistant, et nous ne supportons pas actuellement le stockage persistant.

QPDF

Peut-être. QPDF est un outil en ligne de commande. Le site web indique également ceci :

QPDF est inclus dans la plupart des distributions Linux et dans de nombreuses autres distributions de logiciels.

Cela indique qu’ils ont une application basée sur Dockerfile, qui s’appuie sur l’outil CLI. Il existe quelques dépôts publics sur GitHub qui installent QPDF dans le Dockerfile avec quelques commandes, voici un exemple. Si vous ajoutez les mêmes commandes au Dockerfile, vous serez en mesure d’utiliser QPDF, cependant, nous ne l’avons pas testé sur notre plateforme.

QPDF est une librairie C++, et peut nécessiter l’installation de composants supplémentaires sur l’instance Linux afin qu’elle puisse être compilée avec succès.

Ruby

Oui. Nous avons un repo GitHub d’exemples de démarrage rapide pour Ruby on Rails.

Scala

Oui. Nous avons un repo GitHub d’exemples de démarrage rapide pour Scala.

Shopify

Peut-être. Tous les dépôts dans le github de Shopify sont pour différentes parties de leur application, vous ne pouvez pas auto-héberger le site entier. Cependant, vous pouvez utiliser Hydrogen pour créer une vitrine personnalisée auto-hébergée, qui serait utilisable sur l’hébergement d’applications si vous créez un Dockerfile pour celle-ci.

Shopware

Oui, Shopware est une plateforme de commerce headless propulsée par Symfony 5.4 (PHP) et Vue.js 2.6 et peut être utilisée sur l’hébergement d’applications.

Moteur de stockage Spider dans MariaDB

Non. Ceci n’est actuellement pas pris en charge car il utilise un niveau plus élevé de clustering de base de données.

Statamic

Oui. Statamic est basé sur Laravel, ce qui signifie qu’il s’agit d’une application PHP normale. Pendant le processus de déploiement, Kinsta installe automatiquement les dépendances définies dans votre fichier composer.json.

Symfony

Oui. Symfony est un framework PHP pour créer des sites web et des applications web et peut être utilisé sur un hébergement d’applications.

SvelteKit

Oui. SvelteKit est un framework UI qui compile vos composants en vanilla JavaScript et peut être utilisé sur l’hébergement d’applications.

Velo par Wix

Non. Velo n’a pas d’option d’auto-hébergement. Vous pouvez uniquement utiliser Wix Cloud, vous ne pouvez donc pas accéder au code pour l’utiliser sur notre hébergement d’applications.

VuePress

Oui. Nous avons un repo GitHub d’exemple de démarrage rapide pour VuePress.

Applications Windows Server

Peut-être. Si l’application peut être exécutée dans un conteneur Linux, vous pourrez peut-être l’héberger dans le cadre de l’hébergement d’applications.

Wix

Non. Wix n’est pas open source, vous ne pouvez donc pas accéder au code pour déplacer l’application ou le site web sur nos services d’hébergement.

Yarn

Oui, Yarn est supporté pour l’hébergement d’applications.