Peut-on installer Redmine sur un hébergement mutualisé ? Ce qu’il lui faut, et trois options s’il ne passe pas
Redmine est gratuit, et vous payez déjà une offre d’hébergement mutualisé sur laquelle tourne votre site WordPress. Pourquoi ne pas installer Redmine juste à côté ? Puis vous ouvrez le guide d’installation et tombez sur une longue liste de commandes.
Redmine est un outil open source de gestion de projets utilisé dans le monde entier depuis de nombreuses années. Il est bien documenté et riche en fonctions. Mais il ne fonctionne pas comme WordPress et les autres logiciels PHP, ce qui fait de l’hébergement mutualisé un environnement peu adapté.
Cet article passe en revue les prérequis et les étapes d’installation officiels de Redmine, et montre ce qui coince sur un hébergement mutualisé. Il présente ensuite trois options lorsque Redmine ne peut pas y être installé.
L’essentiel
- L’installation de Redmine suppose un accès en ligne de commande et un environnement capable de faire tourner en permanence un programme Ruby. Il ne peut pas être installé avec un simple navigateur et un accès FTP.
- La version actuelle, Redmine 7.0, nécessite Ruby 3.2 ou supérieur. Sur les cinq hébergeurs mutualisés connus que nous avons examinés, un seul propose un Ruby aussi récent, et aucun ne publie de guide pour installer le Redmine actuel.
- Lorsque Redmine ne passe pas, les choix réalistes sont un VPS, un service Redmine hébergé ou un autre outil conçu pour l’hébergement mutualisé.
Remarque : cet article est rédigé par le développeur de GeckoFlag. Les informations sur Redmine et les hébergeurs reposent sur leurs pages officielles, consultées le 5 octobre 2026.
Ce dont Redmine a besoin
Commençons par le guide d’installation officiel. En octobre 2026, la branche de versions actuelle est la 7.0.
| Critère | Exigence de Redmine 7.0 |
|---|---|
| Environnement d’exécution | Ruby 3.2, 3.3, 3.4 ou 4.0 (fonctionne sous Ruby on Rails 8.1) |
| Base de données | MySQL 8.0 à 8.4, PostgreSQL 14, SQL Server 2012 ou supérieur, ou SQLite 3. SQLite n’est pas destiné à un usage en production multi-utilisateur |
| Réglage MySQL | Passer le niveau d’isolation des transactions à READ COMMITTED |
| Facultatif | ImageMagick (export du Gantt en image, miniatures), Sidekiq (le backend de files d’attente recommandé en production) |
Source : Installing Redmine (guide officiel)
Le guide officiel comporte 11 étapes :
- Télécharger et décompresser le paquet Redmine
- Créer une base de données vide et un utilisateur de base de données
- Écrire les informations de connexion dans un fichier de configuration (config/database.yml)
- Installer les bibliothèques nécessaires en ligne de commande (bundle install)
- Générer un secret de session en ligne de commande
- Compiler les ressources (assets) en ligne de commande
- Créer les tables de la base de données en ligne de commande
- Charger les données par défaut en ligne de commande
- Donner les droits d’écriture sur quelques dossiers
- Démarrer un serveur en ligne de commande et tester l’installation
- L’ouvrir dans un navigateur et se connecter
On est loin du modèle WordPress, où l’on envoie des fichiers puis ouvre un installateur dans le navigateur. Les étapes 4 à 8 et l’étape 10 se font en se connectant au serveur et en tapant des commandes.
Ce qui suit l’étape 10 compte tout autant. Redmine sert ses pages depuis un programme Ruby qui tourne en permanence. Le serveur lancé à l’étape 10 n’est qu’un test. Pour utiliser Redmine au quotidien, il faut une configuration distincte dans laquelle un serveur d’applications tourne en continu derrière le serveur web.
Quatre obstacles sur un hébergement mutualisé
Mettez ces exigences en regard d’une offre d’hébergement mutualisé ordinaire, et quatre problèmes apparaissent.
1La version de Ruby peut être trop ancienne, voire absente
Beaucoup d’hébergeurs mutualisés proposent Ruby, mais la version varie fortement. Les pages d’aide de HostGator indiquent Ruby 1.8.7 pour les offres mutualisées. hosting.com (anciennement A2 Hosting) liste des versions jusqu’à 2.6 dans son sélecteur Ruby. Namecheap monte jusqu’à 3.4.
Redmine 7.0 nécessite Ruby 3.2 ou supérieur. Ruby 2.5, que plusieurs hébergeurs proposent encore, est en fin de vie depuis 2021.
Il est parfois possible de compiler un Ruby plus récent dans votre propre dossier personnel. Cela implique de compiler des logiciels sur le serveur, ce qui ajoute encore un cran de difficulté.
2Il vous faut la ligne de commande (SSH)
Plus de la moitié des étapes d’installation sont des commandes. Pour les exécuter, il vous faut un accès SSH, et l’obtenir dépend de l’hébergeur et de l’offre. Chez certains hébergeurs, il est désactivé par défaut et doit être activé ou demandé.
Même avec SSH, vous n’avez pas d’accès administrateur (root). Si une étape nécessite un paquet système supplémentaire, par exemple pour compiler l’une des bibliothèques de Redmine, vous ne pourrez peut-être pas l’installer.
3Vous ne pouvez pas faire tourner votre propre programme en continu
C’est le point le plus important. L’hébergement mutualisé place de nombreux clients sur un même serveur ; lancer ses propres processus permanents ne fait donc généralement pas partie de l’offre. La mémoire et le nombre de processus sont également plafonnés. Namecheap, par exemple, limite son offre mutualisée d’entrée de gamme à 1 Go de mémoire.
La seule voie proposée par certains hébergeurs est la fonction « Setup Ruby App » de cPanel. Elle exécute une application Ruby via Passenger, géré par l’hébergeur : ce n’est donc pas vous qui démarrez un serveur. Si cette fonction est absente, ou ne propose qu’un Ruby ancien, il n’existe aucune méthode prise en charge pour faire tourner Redmine en continu.
4La base de données ne figure peut-être pas dans la liste de Redmine
Pour MySQL, le guide officiel indique les versions 8.0 à 8.4. Beaucoup d’hébergeurs mutualisés fournissent plutôt MariaDB, compatible avec MySQL sur la plupart des points mais absent de la liste des bases de données prises en charge par Redmine. L’hébergement mutualisé de Namecheap, par exemple, fonctionne avec MariaDB 11.4.
Les points 1 et 4 sont des problèmes de version. Les points 2 et 3 découlent de la manière dont l’hébergement mutualisé est conçu. Les versions finiront peut-être par suivre, mais la limite du point 3 fait partie de la nature même de l’hébergement mutualisé.
Où en sont les hébergeurs mutualisés connus
Nous avons vérifié ce que cinq hébergeurs connus indiquent sur leurs propres pages d’assistance au sujet de Ruby dans les offres mutualisées. Consulté le 5 octobre 2026.
| Hébergeur | Ruby dans les offres mutualisées | Compatible Redmine 7.0 (3.2 ou supérieur) ? | Ce que dit l’hébergeur sur les applications Ruby |
|---|---|---|---|
| Namecheap | 3.0 à 3.4Choisi dans « Setup Ruby App » de cPanel | ✓Pour la version, oui | Publie un guide sur « Setup Ruby App ». La base de données est MariaDB 11.4. SSH peut être activé sur toutes les offres |
| hosting.comanciennement A2 Hosting | 1.8 à 2.6 | Non | Prend en charge Rails via « Setup Ruby App » et indique d’utiliser Ruby 2.5 pour cela |
| HostGator | 1.8.7Rails 2.3.18 | Non | Les versions plus récentes de Ruby et de Rails sont réservées aux VPS ou aux serveurs dédiés |
| DreamHost | Installé, version non indiquée | NonLes applications Ruby ne peuvent pas tourner sur les offres mutualisées | L’exécution d’une application Ruby n’est possible que sur un VPS géré ou un serveur dédié. Passenger n’est pas pris en charge |
| Bluehost | Version non indiquée | IncertainL’hébergeur ne publie pas de version | « Limited support for Ruby applications. Not ideal for running full Ruby on Rails environments. » Recommande un VPS ou un hébergement dédié |
D’après les pages d’assistance et de caractéristiques de chaque hébergeur. Les caractéristiques peuvent varier selon l’offre et la date de souscription.
Quatre des cinq proposent soit un Ruby trop ancien, soit indiquent clairement que les applications Ruby ont leur place sur un VPS ou un serveur dédié.
Namecheap est le cas intéressant. Son hébergement mutualisé propose Ruby jusqu’à 3.4 via « Setup Ruby App » de cPanel : l’exigence de version est donc satisfaite et il existe un moyen, géré par l’hébergeur, de faire tourner une application en continu. Des questions restent néanmoins ouvertes : la base de données est MariaDB et non l’une des versions de MySQL de la liste de Redmine, les bibliothèques de Redmine doivent être installées sans accès root, et le tout doit tenir dans la limite de mémoire de l’offre. Le guide de Namecheap porte sur les applications Ruby en général, pas sur Redmine. Nous n’avons pas testé cette configuration nous-mêmes : considérez-la comme une expérimentation, et non comme une manière prise en charge de faire tourner Redmine.
Rien de tout cela n’est un défaut de l’hébergement mutualisé. Il est conçu pour des sites qui fonctionnent avec PHP, et pour PHP, ces mêmes hébergeurs proposent des versions à jour. Une application comme Redmine, qui tourne en continu sur Ruby, sort simplement du cadre pour lequel l’hébergement mutualisé a été pensé.
Trois options lorsque Redmine ne passe pas
Si Redmine ne peut pas être installé sur votre hébergement mutualisé, trois voies s’offrent à vous. La bonne dépend de ce que vous cherchez : Redmine lui-même, ou la gestion de tickets sur l’hébergement que vous avez déjà.
| Option | Convient si | Ce que vous prenez en charge |
|---|---|---|
| 1. Louer un VPS et installer Redmine | Vous voulez Redmine et quelqu’un dans l’équipe est à l’aise avec la ligne de commande | La mise en place, les mises à jour et la sécurisation du serveur |
| 2. Utiliser un service Redmine hébergé | Vous voulez Redmine sans gérer de serveur | Un abonnement mensuel |
| 3. Utiliser un autre outil qui fonctionne sur un hébergement mutualisé | Vous voulez garder votre hébergement actuel et il n’est pas nécessaire que ce soit Redmine | Les différences de fonctions avec Redmine et le transfert de vos données |
1Louer un VPS et installer Redmine
Si vous voulez garder la main sur l’ensemble de Redmine, c’est la voie classique. Un VPS vous donne un accès administrateur : vous pouvez suivre les étapes officielles telles qu’elles sont écrites.
Certains fournisseurs proposent un VPS livré avec Redmine déjà installé. Hostinger, par exemple, propose un modèle de VPS Redmine sous Ubuntu 24.04. Vérifiez quelle version de Redmine un modèle installe, car ce n’est pas toujours la plus récente.
En contrepartie, l’entretien du serveur devient votre affaire. Mettre à jour le système d’exploitation et Ruby, faire des sauvegardes et se protéger contre les intrusions vous incombe. La question décisive est de savoir si quelqu’un dans l’équipe peut s’occuper d’un serveur, et continuer à le faire.
2Utiliser un service Redmine hébergé
Il existe des services qui font tourner Redmine pour vous, sans installation ni maintenance. Planio en fait partie et figure sur le site même de Redmine. Le fournisseur gère le serveur et vous utilisez Redmine dans le navigateur.
Planio propose une offre gratuite pour 2 utilisateurs et 1 projet, et les offres payantes commencent à 25 $ par mois pour 5 utilisateurs. Si votre point de départ était « Redmine, parce que c’est gratuit », notez que l’hypothèse change ici.
3Utiliser un autre outil qui fonctionne sur un hébergement mutualisé
Si vous avez seulement besoin de gérer des tickets et des tâches sur l’hébergement que vous avez déjà, tournez-vous vers des outils qui fonctionnent uniquement avec PHP et une base de données. Leantime, Kanboard et notre propre GeckoFlag en sont des exemples.
Leurs prérequis et l’effort d’installation sont comparés dans Les outils de gestion de projets que vous pouvez installer sur un hébergement mutualisé sans Docker.
Aucun d’eux ne fait tout ce que fait Redmine. L’intégration aux dépôts, les permissions et workflows fins, ainsi que les plugins, sont les points forts de Redmine. Si vous en avez besoin, l’option 1 ou 2 vous conviendra mieux.
Ce qu’il faut savoir avant de passer de Redmine à GeckoFlag
Cet article est rédigé par le développeur de GeckoFlag. Pour les lecteurs qui envisagent GeckoFlag comme troisième option, voici les limites d’une migration ainsi que ses avantages.
Ce que fait GeckoFlag
GeckoFlag est un outil de gestion de projets et de tickets vendu en paiement unique. Il fonctionne avec PHP 8.2 ou supérieur et MySQL ou MariaDB. Envoyez les fichiers, ouvrez le site dans un navigateur, et l’installateur démarre. Aucune ligne de commande n’intervient. Les mises à jour et les sauvegardes se font également depuis l’écran d’administration.
Il réunit tickets, tickets parents et enfants, commentaires, un tableau Kanban, un diagramme de Gantt, un wiki et le partage de fichiers. L’interface est pensée pour que designers, chefs de projet et clients, des personnes qui ne sont pas ingénieurs, puissent l’utiliser sans s’y perdre.
Les limites à vérifier avant de migrer
- Il n’existe pas d’outil de migration dédié. Vous exportez les tickets de Redmine en CSV et les importez dans GeckoFlag. Les tickets importés sont enregistrés comme de nouveaux tickets, et leurs numéros sont réattribués.
- Seuls les champs de base des tickets sont repris. Il s’agit de champs comme le statut, la priorité, l’assigné, la date de début et l’échéance. L’historique des commentaires, les pièces jointes et les pages wiki ne peuvent pas être transférés. Les relations parent-enfant ne sont pas non plus reprises par le CSV.
- L’import demande un peu de préparation. Les statuts, priorités et assignés doivent d’abord être créés dans GeckoFlag. Les lignes qui font référence à des éléments inexistants sont ignorées. Consultez le manuel d’import et d’export pour plus de détails.
- Redmine possède des fonctions que GeckoFlag n’a pas. Suivi du temps, champs personnalisés, paramétrage des workflows, intégration aux dépôts, plugins, une API et des permissions fines pour chaque rôle.
- Il n’est pas gratuit. C’est un paiement unique de 30 $ / 27 €, et l’hébergement est à prévoir en plus.
GeckoFlag n’est pas le bon choix pour migrer un Redmine riche de plusieurs années d’historique. Il convient aux équipes qui partent de zéro, ou à celles qui ne reprennent que leurs tickets ouverts et repartent sur de nouvelles bases.
Pour une comparaison fonction par fonction, consultez GeckoFlag vs Redmine. Vous pouvez essayer les vrais écrans dans la démo.
En résumé : voulez-vous Redmine, ou gérer des tickets sur votre hébergement ?
Redmine n’a pas été conçu pour être installé sur un hébergement mutualisé. Il nécessite la ligne de commande et un environnement qui fait tourner en permanence un programme Ruby. La plupart des hébergeurs mutualisés connus proposent un Ruby trop ancien pour la version actuelle ou vous orientent vers un VPS pour les applications Ruby, et aucun ne publie de guide pour installer le Redmine actuel.
Si vous hésitez, voici une manière simple de trancher :
- Vous avez besoin des fonctions de Redmine et quelqu’un peut s’occuper d’un serveur : installez-le sur un VPS.
- Vous avez besoin des fonctions de Redmine sans vouloir de serveur : utilisez un service hébergé.
- Gérer des tickets sur votre hébergement actuel vous suffit : choisissez un outil qui fonctionne avec PHP.
Si la troisième option est la vôtre, la lecture suivante est le comparatif des outils pour hébergement mutualisé. Les étapes d’installation de GeckoFlag figurent dans le manuel, et le prix sur la page des tarifs. Nous espérons que cet article vous aidera à trouver la configuration qui convient à votre équipe.
Sources
- Installing Redmine (Redmine : prérequis et étapes d’installation)
- Ruby Maintenance Branches (Ruby : état de prise en charge de chaque version)
- Commercial Offerings (Redmine : services d’hébergement)
- Pricing (Planio)
Remarque : les caractéristiques et les prix sont ceux du 5 octobre 2026. Consultez chaque page officielle pour obtenir les informations les plus récentes avant d’installer ou de souscrire.