Cal.diy : le fork MIT de Cal.com sans code entreprise, pensé pour l'auto-hébergement personnel
cal.diy regroupe l'interface de planification et les intégrations de calendrier de Cal.com pour un auto-hébergement personnel et hors production.
En bref
- De quoi s’agit-il ?
- Analyse de calcom/cal.diy : édition communautaire 100% MIT sans fonctions EE, pile Next.js, tRPC et Prisma, installation yarn dx avec comptes de test et deux clés de chiffrement à générer soi-même.
- À qui s’adresse-t-il ?
- Cal.diy s'adresse aux personnes qui veulent leur propre infrastructure de prise de rendez-vous, sous MIT et sans clé de licence, à condition d'assumer l'administration du serveur, de la base et des mises à jour ; le README le réserve explicitement à un usage personnel non productif et renvoie le commercial vers Cal.com.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Ce que le fork retire : Teams, Organizations, Insights, Workflows et SSO/SAML
Cal.diy se définit par soustraction : c'est un fork de Cal.com dont tout le code entreprise et commercial a été retiré. La liste des fonctions supprimées est publiée dans le README : Teams, Organizations, Insights, Workflows et SSO/SAML, toutes réservées à l'édition EE d'origine. Le dépôt annonce 47976 étoiles et 14940 forks au moment de l'indexation, un volume qui place ce projet parmi les références du domaine.
En échange, la totalité du code passe sous MIT sans découpage open core, aucune clé de licence n'est demandée, et aucun compte Cal.com n'est requis. Il n'existe pas de version hébergée de Cal.diy : vous l'exécutez sur votre infrastructure ou pas du tout. Cette frontière nette entre projet communautaire et offre commerciale évite l'ambiguïté habituelle des éditions communautaires bridées.
Usage strictement personnel et non productif : l'avertissement en tête de README
Le README s'ouvre sur un avertissement sans détour : usage à vos risques et périls, projet strictement recommandé pour un usage personnel non productif, et auto-hébergement exigeant une connaissance avancée de l'administration serveur, de la gestion de base de données et de la protection des données sensibles.
Le même encadré renvoie tout besoin commercial ou entreprise vers Cal.com, hébergé ou sur accès enterprise on-prem via cal.com/sales. Cette position assumée change le contrat : Cal.diy n'est pas une alternative gratuite à un SaaS de production, mais une plateforme complète à administrer soi-même, avec la responsabilité de ses sauvegardes et de ses mises à jour de sécurité. Qui veut produire doit soit accepter Cal.com, soit prendre en charge ces tâches en connaissance de cause.
Next.js, tRPC, Prisma et Daily.co : la pile technique à administrer
La pile annoncée comprend Next.js, tRPC, React, Tailwind CSS, Prisma et Daily.co pour la visioconférence. Les prérequis fixes sont précis : Node.js en version 18 ou supérieure, PostgreSQL en version 13 ou supérieure, Yarn en gestionnaire recommandé. Chaque intégration activée peut exiger des identifiants supplémentaires auprès du fournisseur concerné.
Pour un auto-hébergeur, cette pile a une conséquence directe : l'application ne se limite pas à un conteneur unique. La base PostgreSQL porte l'état entier du planificateur, et Daily.co n'intervient que si vous activez les rendez-vous vidéo, ce qui sort alors des données vers ce fournisseur. Le README ne documente pas de chemins de migration entre versions, d'où l'intérêt de figer une release comme la v6.2.0 et de tester les montées de version hors production.
NEXTAUTH_SECRET et CALENDSO_ENCRYPTION_KEY : les deux clés du .env
L'installation démarre par un git clone suivi de yarn, puis la copie de .env.example vers .env. Deux clés y sont à générer, avec les commandes données par le README : openssl rand -base64 32 pour NEXTAUTH_SECRET, qui signe les sessions d'authentification, et openssl rand -base64 24 pour CALENDSO_ENCRYPTION_KEY, qui chiffre les identifiants d'intégrations stockés.
La seconde clé mérite une attention particulière : elle protège les accès aux calendriers tiers, et la perdre ou la changer sans précaution rend ces identifiants illisibles. Windows a son lot d'instructions dédiées : le clone doit passer par Git Bash avec core.symlinks=true, et le lien symbolique packages/prisma/.env doit être remplacé par une copie réelle pour éviter l'erreur Prisma unexpected character / in variable name. Le README fournit la commande rm puis cp exacte pour cela.
yarn dx : cinq comptes semés et une base Postgres locale en une commande
Le chemin d'essai rapide passe par yarn dx, qui exige Docker et Docker Compose : la commande lance un Postgres local avec des utilisateurs de test, dont les identifiants s'affichent en console. Le README publie la table complète : free@example.com, pro@example.com, trial@example.com, onboarding@example.com et admin@example.com avec le mot de passe ADMINadmin2022!, connexion sur http://localhost:3000.
Ces comptes servent à explorer les rôles sans configurer quoi que ce soit, et yarn db-studio ouvre le navigateur de base sur http://localhost:5555 pour voir l'ensemble des données semées. Le nom même du compte admin avec son mot de passe publié rappelle qu'il s'agit d'un environnement de développement : rien de tout cela ne doit surviving dans une instance exposée.
Mémoire Node et NEXT_PUBLIC_LOGGER_LEVEL : les réglages qui débloquent le développement
Deux conseils de développement figurent dans le README. Le premier augmente la limite mémoire du processus Node via export NODE_OPTIONS="--max-old-space-size=16384", valeur à adapter à la RAM disponible, indice que la compilation et l'exécution de l'application sont gourmandes. Le second contrôle la verbosité des logs tRPC par NEXT_PUBLIC_LOGGER_LEVEL dans le .env, avec sept niveaux documentés, de 0 pour silly à 6 pour fatal, chaque niveau incluant les suivants.
Le niveau 3, info, sert de point d'équilibre pour diagnostiquer les requêtes et mutations. Un environnement Gitpod est aussi prévu pour ceux qui veulent tester sans installation locale. Ces réglages montrent un projet dont le développement local est documenté avec soin, signe que la courbe d'entrée est réelle mais cartographiée.
1429 tickets ouverts et un fork actif : l'état du dépôt avant de s'engager
Le dépôt affiche 1429 tickets ouverts, volume cohérent avec une communauté de cette taille, et la maintenance suit un rythme soutenu : v6.1.15 et v6.1.16 le 12 février 2026, puis v6.2.0 le 1er mars 2026. Les contributions vont directement dans ce projet, selon CONTRIBUTING.md, avec un code de conduite Contributor Covenant et des tickets help wanted étiquetés.
Avant une installation durable, le parcours utile est court : yarn dx pour vérifier que la pile tourne chez vous, lecture de CONTRIBUTING.md pour mesurer l'activité réelle, puis choix d'une release figée à déployer. Le projet n'ayant ni version hébergée ni support commercial, votre plan de mise à jour et de sauvegarde de PostgreSQL est la pièce que rien ne fournira à votre place.
Conclusion éditoriale
Cal.diy s'adresse aux personnes qui veulent leur propre infrastructure de prise de rendez-vous, sous MIT et sans clé de licence, à condition d'assumer l'administration du serveur, de la base et des mises à jour ; le README le réserve explicitement à un usage personnel non productif et renvoie le commercial vers Cal.com. Avant d'installer, passez par yarn dx pour voir l'application tourner avec les comptes semés, puis générez NEXTAUTH_SECRET et CALENDSO_ENCRYPTION_KEY par openssl avant toute exposition.
Notes de la communauté