Comparatif
Plateforme vs PaaS historique
La première génération de PaaS a simplifié les déploiements. La plateforme garde cette simplicité et ajoute ce qui manquait aux équipes en croissance.
L'essentiel
- Gardez le déploiement à chaque push, et ajoutez réseau privé et environnements de prévisualisation.
- Facturation des instances à la seconde : un service inactif ne coûte plus un forfait mensuel.
- Choisissez une région pour chaque service et base de données, sans marketplace de modules à brancher.
Côte à côte
Le même workflow, moins de limites
Là où un PaaS historique s'arrête, et ce que vous obtenez à la place.
| Fonctionnalité | Plateforme | PaaS historique |
|---|---|---|
| Déploiements | ||
| Déploiement à chaque push | Inclus | Inclus |
| Environnements de prévisualisation | Inclus | Module payant |
| Déploiements sans interruption | Inclus | Offres supérieures uniquement |
| Tâches en arrière-plan et tâches cron | Intégrées | Processus supplémentaires |
| Infrastructure | ||
| Réseau privé | Inclus | Non inclus |
| Régions | Au choix par service | Deux ou trois |
| Postgres géré | Intégré | Module de la marketplace |
| Autoscaling | Inclus | Manuel ou payant |
| Tarification | ||
| Facturation | Par instance, à la seconde | Forfait par processus et par mois |
| Sites statiques gratuits | Inclus | Non inclus |
| Mise en veille des instances gratuites | Non inclus | Inclus |
Pourquoi les équipes changent
Les raisons que nous entendons le plus souvent chez les équipes qui ont dépassé leur premier PaaS.
Payez ce qui tourne
Avec la facturation à la seconde, un service calme ne coûte presque rien la nuit.
Privé par défaut
Services et bases de données communiquent sur un réseau privé plutôt que sur l'internet public.
Prévisualisations incluses
Chaque pull request obtient un environnement de prévisualisation, sur toutes les offres payantes.
Les régions de votre choix
Faites tourner chaque service près de ses utilisateurs et gardez les données là où elles doivent rester.
Migrez sans tout réécrire
Votre build fonctionne déjà. La migration tient surtout à la configuration.
- 01Clonage du dépôt depuis main
- 02Runtime Ruby détecté
- 03Procfile trouvé : web, worker
- 04Build terminé en 51 s
- 05Contrôle de santé réussi
- 06Le déploiement est en ligne
- Service web
- Worker
- Tâche cron
- Postgres
- Cache
- Site statique
- Base restaurée depuis un dump
- Variables d'environnement importées
- Domaine personnalisé vérifié
- Certificat TLS émis
- Trafic basculé vers la plateforme
- Anciennes applications réduites à zéro
“Nous avons gardé le workflow que tout le monde aimait et abandonné la facture des modules. Les environnements de prévisualisation ont, à eux seuls, changé notre façon de relire le travail.”
FAQ
Vous venez d'un PaaS historique
Ce que les équipes demandent avant de migrer leurs applications.
Contacter le support01Mon Procfile fonctionne-t-il toujours ?
Oui. Chaque type de processus devient un service : web devient un service web, et les autres entrées deviennent des workers ou des tâches cron.
02Comment déplacer mes données Postgres ?
Créez une base Postgres gérée, puis restaurez-y un dump. Les bases plus volumineuses peuvent d'abord être répliquées, puis basculées avec quelques secondes en lecture seule.
03Mes coûts vont-ils augmenter ?
La plupart des équipes paient moins, car les instances sont facturées à la seconde et se réduisent quand le trafic baisse. La page Tarifs détaille chaque prix.
04Puis-je garder mes domaines personnalisés ?
Oui. Ajoutez le domaine à un service, mettez à jour l'enregistrement DNS, et le certificat TLS est émis automatiquement.