[{"data":1,"prerenderedAt":229},["ShallowReactive",2],{"seo-verification":3,"blog-cal-com-closed-source-scheduling-alternatives-vps-2026-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-cal-com-closed-source-scheduling-alternatives-vps-2026-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":32,"intro":35,"sections":36,"ctaTitle":166,"ctaBody":167,"ctaButton":168,"ctaUrl":169,"relatedPosts":170},405,"cal-com-closed-source-scheduling-alternatives-vps-2026",{"fr":12,"en":10,"ar":13,"es":14},"cal-com-closed-source-alternatives-scheduling-vps-2026","cal-com-مصدر-مغلق-بدائل-تحديد-المواعيد-vps-2026","cal-com-codigo-cerrado-alternativas-planificacion-vps-2026","Cal.com goes closed source: 3 open-source scheduling alternatives","Cal.com dropped AGPL in April 2026. Compare Rallly, Easy!Appointments and Tymeslot: three truly open-source scheduling alternatives to deploy on a VPS.",9,0,false,"2026-10-02T00:00:00+00:00","2026-10-02T14:03:20+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},5,"Comparison","comparatif","bg-info\u002F10 text-info",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcal-com-closed-source-alternatives-scheduling-vps-2026-poster.svg",{"categorySlug":33,"appSlug":34},"collaboration-productivity","cal-com","On April 14, 2026, Cal.com moved its commercial codebase to a private repository and relicensed the public code as Cal.diy (MIT), removing SSO, Teams, Workflows and Routing Forms. Users who had chosen Cal.com specifically for its AGPL are now faced with a choice: stay on an intentionally stripped-down cal.diy, upgrade to the closed commercial offer, or migrate to a truly free alternative. This article compares Rallly, Easy!Appointments and Tymeslot to help you decide.",[37,41,53,56,62,84,153,156,160,163],{"type":38,"title":39,"body":40},"h2","What changed at Cal.com in April 2026","Cal.com published its decision on April 14, 2026: the rise of AI tools capable of scanning public code to detect vulnerabilities led the team to close the commercial codebase. Version v6.4 marks the tipping point.\n\nThe public repository `calcom\u002Fcal.com` was renamed `calcom\u002Fcal.diy` and relicensed from AGPL-3.0 to MIT. This change may look permissive at first glance — MIT is a permissive license — but the core issue is what was **removed** from the public code, not the license itself. Cal.diy is officially described as a tool for personal and non-production use: the cal.diy site explicitly recommends Cal.com (the closed version) for any commercial or production use.",{"type":42,"title":43,"items":44},"ul","Features removed from cal.diy compared to AGPL",[45,46,47,48,49,50,51,52],"**Teams and Organizations**: multi-member management and team spaces, now reserved for the closed Enterprise offer.","**Workflows**: reminder automations, notifications and triggered actions, absent from the public code.","**SSO and SAML**: single sign-on via your identity provider, removed from cal.diy.","**Routing Forms**: qualification forms to route bookings to the right team member, removed.","**Instant Booking**: immediate booking without manual confirmation, reserved for the commercial offer.","**Insights**: booking analytics dashboard, absent from the open code.","**API v1**: the legacy documented REST API, replaced by API v2 on the commercial side only.","**AI phone agent**: AI-powered scheduling via phone call, closed source.",{"type":38,"title":54,"body":55},"Requirements compared: RAM, CPU and stack per alternative","Before choosing, verify that your VPS fits the tool's profile. The three alternatives have very different stacks — one in Node.js\u002FPostgreSQL, one in PHP\u002FMySQL, one in Elixir\u002FPostgreSQL — which translates into different resource requirements and administration constraints.",{"type":42,"title":57,"items":58},"Resource profiles per tool",[59,60,61],"**Rallly** (AGPL-3.0): Next.js + PostgreSQL via Docker Compose. Plan for at least **2 GB of RAM**, 1 vCPU is sufficient for light load. A domain, SMTP relay and Docker Compose v2 are required. The official bundle includes PostgreSQL, S3-compatible object storage and an HTTPS reverse proxy — a single command gets you running.","**Easy!Appointments** (GPL-3.0): PHP 8.2+ + MySQL\u002FMariaDB. Runs on any standard LAMP server or Docker. **512 MB of RAM** is sufficient for individual or small-team use — the lightest of the three. Compatible with cPanel shared hosting, not just VPS.","**Tymeslot** (AGPL-3.0): Elixir\u002FPhoenix LiveView + PostgreSQL bundled in the Docker container. Compiled stack, very low memory footprint at runtime. A single Docker container with bundled PostgreSQL — designed for a clean VPS installation.",{"type":63,"title":64,"steps":65},"steps","Deploy Rallly on a VPS with Docker Compose",[66,69,72,75,78,81],{"title":67,"body":68},"Prepare the server","Log in as root on your VPS. Install Docker and Docker Compose v2 if not already done:\n\n```bash\ncurl -fsSL https:\u002F\u002Fget.docker.com | sh\ndocker compose version\n```\n\nOpen ports 80 and 443 in your firewall. Point a subdomain (`cal.your-domain.com`) to your VPS IPv4 via a DNS A record.",{"title":70,"body":71},"Get the official configuration","Clone the Rallly self-hosted example repository and create your environment file:\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Flukevella\u002Frallly-selfhosted.git\ncd rallly-selfhosted\ncp .env.example .env\n```",{"title":73,"body":74},"Configure environment variables","Open `.env` and fill in the key variables:\n\n```bash\nSECRET_PASSWORD=\u003Crandom-32-char-string>\nNEXT_PUBLIC_BASE_URL=https:\u002F\u002Fcal.your-domain.com\nSMTP_HOST=smtp.your-provider.com\nSMTP_PORT=587\nSMTP_USER=your@email.com\nSMTP_PWD=\u003Csmtp-password>\nSUPPORT_EMAIL=your@email.com\n```\n\nGenerate the random string with `openssl rand -hex 16`. Do not leave `SECRET_PASSWORD` empty — Rallly will refuse to start without a non-empty value.",{"title":76,"body":77},"Launch the containers","Start the full stack in the background. The Rallly bundle includes the application, PostgreSQL, object storage and a reverse proxy with automatic TLS:\n\n```bash\ndocker compose up -d\n```\n\nVerify all services are `healthy`:\n\n```bash\ndocker compose ps\n```\n\nThe reverse proxy obtains a Let's Encrypt certificate automatically on first start — wait one minute before accessing the domain.",{"title":79,"body":80},"Verify the installation and create the first poll","Open `https:\u002F\u002Fcal.your-domain.com` in your browser. The Rallly interface does not require participants to create an account — only the organizer does. Create a first availability poll to verify that SMTP email delivery is working correctly.\n\nIf email is not arriving, check the application service logs:\n\n```bash\ndocker compose logs app --tail=50\n```",{"title":82,"body":83},"Enable automatic updates (optional)","To stay up to date without manual intervention, install Watchtower, which monitors new images and restarts affected containers:\n\n```bash\ndocker run -d \\\n  --name watchtower \\\n  -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n  containrrr\u002Fwatchtower --cleanup --interval 86400\n```\n\nWatchtower checks for new images once a day. Rallly regularly publishes security patches — do not leave your instance unmonitored.",{"type":85,"title":86,"headers":87,"rows":93},"comparison","Rallly vs Easy!Appointments vs Tymeslot vs cal.diy",[88,89,90,91,92],"Criterion","Rallly","Easy!Appointments","Tymeslot","cal.diy",[94,99,104,109,115,121,127,131,135,139,144,147],[95,96,97,96,98],"License","AGPL-3.0","GPL-3.0","MIT (stripped code)",[100,101,102,103,101],"Stack","Next.js + PostgreSQL","PHP 8.2 + MySQL","Elixir\u002FPhoenix + PostgreSQL",[105,106,107,108,106],"Minimum RAM","2 GB","512 MB","Not documented",[110,111,112,113,114],"Docker Compose","Yes, official bundle","Yes, image available","Yes, single container","Yes",[116,117,118,119,120],"Primary use case","Availability polls, group voting","Structured appointments (services\u002Fproviders)","Individual and group scheduling","Individual scheduling (non-prod)",[122,123,124,125,126],"Calendar sync","Google, Outlook (iCal)","Google Calendar","Google, Outlook, iCloud, CalDAV, Nextcloud","Google, Outlook",[128,129,129,129,130],"SSO \u002F SAML","No","Removed (commercial offer)",[132,129,133,134,130],"Multi-member Teams","Multi-provider (services)","Yes (groups)",[136,137,137,138,130],"Workflows \u002F auto reminders","Yes (emails)","Yes (emails, Slack, Telegram)",[140,114,141,142,143],"REST API","Yes (full REST)","Yes + webhooks","API v2 only",[145,114,114,114,146],"Recommended for production","No (official statement)",[148,149,150,151,152],"Maturity (2026)","Active, v4.15.2 (Sept 2026)","Active, v1.6.0 (May 2026)","Active, launched in response to Cal.com","Maintained, intentionally limited scope",{"type":38,"title":154,"body":155},"Migrating from Cal.com AGPL: exporting your data","If you have been self-hosting Cal.com under AGPL and want to migrate to one of the alternatives, here is how to extract your data before shutting down your old instance.\n\n**Exporting from an existing Cal.com AGPL instance.** Cal.com stores its data in PostgreSQL. You can export the bookings, availability and event type tables via `pg_dump`:\n\n```bash\npg_dump -U calcom -d calcom -t bookings -t event_types -t schedules > calcom_export.sql\n```\n\nThe data to prioritize: existing bookings (for your CRM history), participant email addresses (if you send reminders), and your availability rules (hours, blocked slots).\n\n**What you cannot import directly.** None of the three alternatives offer import in Cal.com format — migration is a manual reconfiguration, not a restore. Focus on exporting your contact list and availability rules, then reconfigure event types in the target tool. For Rallly (group polls) or Tymeslot (individual booking links), reconfiguration typically takes less than an hour.\n\n**For Easy!Appointments**, if you are coming from a system with structured services (30-minute slots per provider), this is the tool whose logic is closest to a traditional professional calendar. Import your providers and services via the admin interface, then reconfigure time slots.",{"type":157,"title":158,"body":159},"tip","Post-installation hardening","A few steps before exposing your instance to real traffic.\n\nProtect admin access with HTTP basic authentication in front of your reverse proxy if the tool does not offer native 2FA — particularly important for Easy!Appointments on public access. Set up automatic backups of the PostgreSQL volume or MySQL data directory: a scheduled `docker exec` with `pg_dump` or `mysqldump` to external storage is sufficient. Verify that your VPS only exposes necessary ports (80\u002F443 for web, 22 for SSH) and that direct access to the database port (5432 or 3306) is not open on the public interface.\n\nFinally, enable release notifications on the GitHub repository of your chosen tool (Watch → Custom → Releases): all three projects are active in 2026 and regularly publish patches.",{"type":38,"title":161,"body":162},"Common troubleshooting","**Rallly: the application starts but emails are not arriving.** Check `SMTP_HOST`, `SMTP_PORT` and `SMTP_USER` in your `.env` file. Some hosting providers block port 25 outbound — use port 587 (STARTTLS) or 465 (SSL). Inspect logs with `docker compose logs app --tail=100 | grep -i smtp`.\n\n**Easy!Appointments: 500 error or blank page after installation.** Verify that the `storage\u002F` directory is writable by the web process (`chmod -R 775 storage\u002F`). In Docker, check that the MySQL container is started and reachable before the application container — a `depends_on` with `condition: service_healthy` in your Compose resolves race condition startups.\n\n**Tymeslot: container starts but calendar sync fails.** Google\u002FOutlook sync requires OAuth2 credentials (Client ID and Client Secret) configured in environment variables. Create a project in the Google Cloud Console, enable the Google Calendar API, and set `GOOGLE_CLIENT_ID` and `GOOGLE_CLIENT_SECRET`. The OAuth callback URL must exactly match your production domain.\n\n**Rallly: `SECRET_PASSWORD must be set` error.** This variable is mandatory and must be at least 32 characters. Generate one with `openssl rand -hex 16` (produces 32 hexadecimal characters) and set it in `.env` before running `docker compose up -d` again.",{"type":38,"title":164,"body":165},"Which alternative to choose?","**Rallly** is the right fit if you need availability polls to find a time slot that works for multiple participants — team meetings, workshops, group calls. No real-time booking flow, but a lightweight collaborative vote with no friction. Its maturity (v4.15.2 in September 2026, complete official Docker bundle) makes it the easiest option to deploy.\n\n**Easy!Appointments** is the right choice if your use case looks like a structured professional calendar: services (consultation, class, interview), providers, fixed slots and email confirmation. It works on cPanel shared hosting as well as VPS, making it accessible without Docker. Its version 1.6.0 (May 2026) is the most recent.\n\n**Tymeslot** positions itself as the direct response to the departure of Cal.com AGPL: individual scheduling with booking links, multi-calendar sync (Google, Outlook, iCloud, CalDAV, Nextcloud), and webhook integrations for connecting to n8n or Make. Born in the wake of Cal.com's closure, it directly targets developers who were looking for an equivalent-scope alternative, with an AGPL license guaranteeing longevity.\n\n**Cal.diy** remains an option if you only need a basic individual booking page with no commitment on feature longevity — the Cal.com team is explicit: cal.diy is not recommended for commercial production. If that is your starting point, Rallly or Tymeslot offer the same core features with a community that is not trying to upsell you.","Deploy your scheduling tool on a VPS","Rallly, Easy!Appointments and Tymeslot self-host on a root VPS with Docker. Root access, dedicated IPv4, choice of OS, no software restrictions.","Deploy my alternative on VPS","\u002Fvps-cloud",[171,192,208],{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":188,"featuredImage":29,"bgImage":30,"posterImage":190,"relatedSolution":191},88,"host-calcom-on-your-own-vps",{"fr":175,"en":173,"ar":176,"es":177},"heberger-cal-com","استضافة-calcom-على-خادمك-الافتراضي-الخاص-vps","alojar-cal-com-en-un-vps","Host Cal.com on Your VPS: Complete Docker Guide","Deploy Cal.com on a VPS with Docker, PostgreSQL and reverse proxy. Fix CLIENT_FETCH_ERROR, first-boot invariants, safe updates and troubleshooting.","2026-03-24T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":183,"name":184,"slug":185,"color":186,"icon":187},7,"Self-hosting","self-hosting","bg-indigo-500\u002F10 text-indigo-400","cloud",[189],{"id":183,"name":184,"slug":185,"color":186,"icon":187},"\u002Fblog\u002Fcovers\u002Fheberger-cal-com-poster.svg",{"categorySlug":185,"appSlug":34},{"id":193,"slug":194,"slugs":195,"title":199,"excerpt":200,"readTime":201,"views":202,"isPinned":19,"publishedAt":203,"updatedAt":181,"category":204,"categories":205,"featuredImage":29,"bgImage":30,"posterImage":207,"relatedSolution":29},219,"bsl-and-sspl-the-traps-of-source-available-licenses",{"fr":196,"en":194,"ar":197,"es":198},"bsl-sspl-licences-self-hosting","bsl-وsspl-مخاطر-تراخيص-المصدر-المتاح","bsl-y-sspl-trampas-licencias-source-available","BSL and SSPL: the traps of source-available licenses","BSL, SSPL, AGPLv3: understand what each license allows or forbids before adding a tool to your stack.",12,1,"2026-08-04T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[206],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fbsl-sspl-licences-self-hosting-poster.svg",{"id":209,"slug":210,"slugs":211,"title":215,"excerpt":216,"readTime":217,"views":18,"isPinned":19,"publishedAt":218,"updatedAt":219,"category":220,"categories":226,"featuredImage":29,"bgImage":30,"posterImage":228,"relatedSolution":29},390,"self-hosted-app-longevity-signals",{"fr":212,"en":210,"ar":213,"es":214},"perennite-stack-self-hosted-signaux-resilience-projet","إشارات-استدامة-تطبيق-مستضاف-ذاتيا","senales-durabilidad-app-self-hosted","5 signals to assess a self-hosted app's long-term viability","Before deploying an open-source app for a client, five measurable indicators to know whether it will hold up over time — governance, funding, licence and more.",10,"2026-09-27T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":221,"name":222,"slug":223,"color":224,"icon":225},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[227],{"id":221,"name":222,"slug":223,"color":224,"icon":225},"\u002Fblog\u002Fcovers\u002Fperennite-stack-self-hosted-signaux-resilience-projet-poster.svg",1790987745013]