Un hébergement Laravel pensé pour votre façon de déployer

Oui. Chaque formule est livrée avec un shell SSH complet : le déploiement reste le workflow Git que vous utilisez déjà en local. Clonez votre dépôt directement depuis GitHub, GitLab ou Bitbucket dans votre compte, lancez composer install pour récupérer vos paquets vendor, puis copiez vos valeurs de production dans .env. Artisan prend ensuite le relais : php artisan key:generate définit la clé de votre application et php artisan migrate construit le schéma de votre base. Livrer une version suivante est tout aussi rapide — git pull pour récupérer les nouveaux commits, composer install pour mettre à jour les dépendances, php artisan migrate pour les nouvelles migrations, et un rafraîchissement du cache pour effacer l'ancienne configuration. Comme vous disposez d'un vrai shell plutôt que d'un panneau verrouillé, vous pouvez suivre les logs, corriger les permissions de storage et relancer n'importe quelle commande si quelque chose mérite un second regard. Pointez la racine du site sur le dossier public et le site est en ligne en HTTPS.

Oui — Composer est installé sur chaque compte et déjà présent dans votre PATH : il n'y a rien à télécharger, décompresser ou configurer avant votre premier déploiement. Ouvrez une session SSH dès l'activation de votre compte et composer install, composer update, composer require et composer dump-autoload fonctionnent immédiatement avec le bon binaire PHP. C'est déterminant pour Laravel, car le framework et la quasi-totalité des paquets que vous ajoutez — des starter kits à Sanctum, Horizon et le reste — arrivent par Composer plutôt que d'être versionnés dans votre dépôt. Vous conservez vos propres composer.json et composer.lock : les versions que vous testez en local sont exactement celles qui arrivent sur le serveur. Et si vous devez un jour lancer Composer sous une version de PHP précise, c'est possible, puisque la version de PHP se choisit site par site. En résumé, votre gestion des dépendances se comporte exactement comme sur votre propre machine.

Vous disposez de PHP 8.x moderne, et vous choisissez la version de chaque site depuis le panneau de contrôle. Cette souplesse compte, car chaque version de Laravel indique une exigence PHP minimale : les versions récentes attendent PHP 8.1 ou plus, tandis qu'une application en support à long terme peut rester figée sur une build 8.x antérieure. Plutôt que d'imposer un runtime unique à tout le monde, vous définissez la version par domaine — un projet client historique et une toute nouvelle application cohabitent ainsi sur le même compte sans conflit. À côté du sélecteur, vous ajustez les réglages qui comptent pour Laravel : memory_limit pour les commandes Artisan et les imports les plus lourds, max_execution_time pour les tâches longues, et OPcache pour garder votre code compilé au chaud en mémoire. Le changement de version est instantané et réversible, ce qui rend le test d'une montée de version peu risqué : basculez d'abord un domaine de préproduction, vérifiez que votre suite de tests passe, puis faites migrer la production en un seul clic.

Les deux sont pris en charge nativement. Pour le travail en file, démarrez un worker persistant avec php artisan queue:work afin que jobs, notifications, mailables et exports lourds s'exécutent hors de la requête web, sans bloquer le chargement de page d'un visiteur. Adossez la file à Redis et les jobs sont pris en charge et vidés rapidement, même sous trafic réel. Pour le planifié, vous n'ajoutez pas une longue liste de lignes cron distinctes. Vous enregistrez tout dans le planificateur de Laravel, au sein du code de votre application, puis vous ajoutez une seule entrée cron qui exécute php artisan schedule:run chaque minute. À partir de cette unique tâche, Laravel décide quelles commandes sont dues et les déclenche : résumés horaires, nettoyages nocturnes, rapports hebdomadaires, et ainsi de suite. Après chaque déploiement, lancez php artisan queue:restart pour que vos workers chargent le nouveau code. C'est la configuration Laravel standard, telle que la décrit la documentation, sans contournement propre à la plateforme à apprendre.

Oui. Redis est disponible pour la mise en cache, le stockage des sessions et les files d'attente — la combinaison vers laquelle se tournent la plupart des applications Laravel en production. Pointez votre driver de cache sur Redis et les résultats de requêtes coûteuses, les fragments rendus et les valeurs calculées sont servis depuis la mémoire au lieu d'être reconstruits à chaque appel. Déplacez les sessions vers Redis et l'état des utilisateurs connectés reste rapide et cohérent à mesure que le trafic grimpe. Réglez votre connexion de file sur Redis et les jobs en arrière-plan sont mis en file et traités avec très peu de surcharge : vos workers restent réactifs pendant les pics. Tout cela se configure dans votre .env avec les réglages standard de driver de cache, de session et de file — aucune configuration sur mesure n'est nécessaire de notre côté. Comme Redis garde cet ensemble de données actif en RAM plutôt que sur disque, les pages autrefois lourdes deviennent nettement plus vives, et les traitements en arrière-plan suivent le rythme au lieu de s'accumuler quand une vague de trafic arrive.

Oui, et c'est la bonne façon de servir une application Laravel. Laravel place un point d'entrée unique dans son répertoire public et conserve le code de votre application, votre .env et storage au-dessus de la racine web : rien de sensible n'est accessible depuis le web. Depuis le panneau de contrôle, vous définissez la racine du document de votre domaine sur le dossier public de votre projet, et les requêtes passent par index.php exactement comme le framework le prévoit. Combiné à un SSL gratuit à renouvellement automatique, votre application répond en HTTPS avec des URL propres et lisibles, sans index.php dans la barre d'adresse. Les permissions des répertoires storage et bootstrap/cache se règlent facilement en SSH : cache, sessions et envois de fichiers fonctionnent du premier coup. Et si vous hébergez plusieurs applications sur un même compte, chaque domaine obtient sa propre racine pointée sur son propre dossier public, ce qui sépare proprement les projets tout en partageant le même serveur NVMe rapide.

Yes. Our team transfers your codebase, exports and imports your MySQL database, and carries over your storage folder so uploaded files and cached data aren't left behind. We bring everything up on a temporary address first so you can confirm queues, the scheduler and Redis-backed sessions all still work, and only then do we walk through the DNS cutover.

Yes, daily backups cover your database and storage directory, giving you a restore point that sits alongside your own Git-based code rollbacks. If a migration or seed command goes wrong, you can restore the previous day's snapshot rather than trying to reverse the damage by hand.

Yes. Addon domains let you point a staging subdomain and your live domain at the same account, each with its own document root and database. Push and test on staging first, run your Artisan migrations there, and only promote to the production domain once you're confident.

Higher tiers support up to 100 MySQL databases, which in practice means room for several Laravel projects — a mix of client sites, side projects and staging copies — on a single account, each with its own domain, database and .env.

Every plan is covered by a 30-day money-back guarantee, so you can deploy your actual project, run it under real traffic, and check queue throughput and Redis caching behave the way you expect before committing beyond the trial period.

Plans are priced in USD starting at $2.42/mo, and geo-currency detection displays that price converted into your local currency at checkout, so what you see is what gets billed rather than a rate you have to calculate yourself. Billing itself runs through Bohzo Ltd (UK).