Zelfgehost alternatief voor Calendly: de beste opties

Het korte antwoord

Een zelfgehost alternatief voor Calendly moet één ding doen wat de interne tools op uw VPS nooit doen: reageren op het publieke internet. De boekingspagina is het product. Deze heeft vanaf de eerste dag een echte domeinnaam en TLS (transport layer security) nodig, en moet e-mail kunnen afleveren bij mensen die nog nooit van uw server hebben gehoord.

Vier projecten dekken het realistische aanbod. Cal.com komt het dichtst in de buurt van Calendly en is de standaardkeuze voor een zelfstandig consultant. Eenvoudig! Easy!Appointments is de lichtgewicht optie, gebaseerd op PHP en MySQL, die uitstekend draait op een 1 GB VPS. Rallly is een tool voor groepspeilingen en heeft geen boekingspagina. DayOtter is de nieuwste toevoeging, een AGPLv3-platform voor agendabeheer met een assistent die eerst om bevestiging vraagt.

Twee vragen bepalen welke optie u daadwerkelijk kunt draaien. Synchroniseert de tool in beide richtingen met de agenda die u al gebruikt? En kan de tool e-mail versturen? De tweede vraag is waar de meeste zelfgehoste boekingsopstellingen stilletjes falen, dus die krijgt voorrang.

Uitgaande e-mail is het onderdeel dat vaak faalt

Een boekingsbevestiging wordt naar de inbox van een vreemde verstuurd. Dit is transactionele e-mail die bij Gmail of Microsoft 365 aankomt, en deze ontvangers beoordelen u op basis van het verzendende IP-adres en uw DNS-records.

Direct versturen vanaf de VPS werkt vrijwel nooit. De meeste providers blokkeren uitgaande TCP-poort 25 op nieuwe accounts, waardoor de verbinding blijft hangen en uiteindelijk een time-out geeft. Zelfs als poort 25 open is, heeft een vers VPS-adres geen verzendgeschiedenis en beschouwen grote ontvangers onbekende adressen uit hosting-ranges als verdacht. De boeking wordt naar de database geschreven, de pagina geeft aan dat de boeking is bevestigd, maar niemand ontvangt een e-mail. Aan de serverzijde lijkt niets defect, wat de reden is dat dit meestal pas weken later wordt ontdekt door een klant die nooit is komen opdagen.

Gebruik een relay. Elke aanbieder van transactionele e-mail werkt, en de applicatie heeft enkel een hostnaam, een poort, een gebruikersnaam en een wachtwoord nodig. Controleer of de poort bereikbaar is voordat u de applicatieconfiguratie aanpast:

nc -vz -w 5 "$SMTP_HOST" 587

Een succeeded-regel betekent dat het pad open is. Een hangende verbinding of Connection refused betekent dat de poort op netwerkniveau wordt geblokkeerd, en het aanpassen van .env zal dat niet verhelpen. Relays luisteren op 587 of 465 juist omdat 25 zo vaak wordt geblokkeerd.

Elk project verwerkt de relay op zijn eigen manier. Cal.com leest EMAIL_FROM, EMAIL_SERVER_HOST, EMAIL_SERVER_PORT, EMAIL_SERVER_USER en EMAIL_SERVER_PASSWORD, en accepteert ook een RESEND_API_KEY. Let daarop: de meegeleverde .env.example wijst EMAIL_SERVER_HOST naar localhost op poort 1025, wat een lokale ontwikkelingsmailbox is. Laat de standaardinstelling staan en de applicatie verstuurt e-mails naar het niets zonder foutmelding. Rallly gebruikt SMTP_HOST, SMTP_PORT, SMTP_USER en SMTP_PWD. DayOtter gebruikt SMTP-instellingen of een Resend-sleutel. Easy!Appointments verstuurt notificaties vanuit de applicatie; wijs deze dus naar dezelfde relay via de instellingenpagina voordat u een echte boeking accepteert.

Publiceer vervolgens de DNS-records die uw relay verstrekt. Een SPF (sender policy framework)-record geeft aan welke servers namens uw domein mogen verzenden, en een DKIM (domainkeys identified mail)-sleutel ondertekent elk bericht zodat de ontvanger kan verifiëren dat het niet is gewijzigd. Voeg een DMARC (domain-based message authentication, reporting and conformance)-beleid toe zodra beide zijn geslaagd. Verstuur een testboeking naar een echt adres bij een grote provider, open de berichtheaders en bevestig dat de authenticatieregels pass aangeven. Een boekingspagina die niet kan verzenden is erger dan helemaal geen boekingspagina, omdat deze geruisloos faalt.

Welke kalender-backends ondersteunen daadwerkelijk tweerichtingssynchronisatie

Synchronisatie verloopt in twee richtingen en deze kunnen onafhankelijk van elkaar falen. De leesrichting betreft beschikbaarheid: de applicatie moet uw bestaande bezette blokken kunnen inzien, anders wordt een tijdslot aangeboden waarin u al bezet bent. De schrijfrichting betreft de boeking zelf: het bevestigde evenement moet verschijnen in de kalender die u daadwerkelijk raadpleegt, en niet enkel binnen de boekingstool.

Google Calendar en Microsoft 365 ondersteunen beide richtingen, met één voorwaarde bij een self-hosted installatie. U moet de OAuth (open authorization) client zelf aanmaken, omdat de client ID van het gehoste product niet in de broncode staat. Voor Cal.com is dat GOOGLE_API_CREDENTIALS in .env, waar u de JSON plaatst die u downloadt vanuit de Google Cloud console. DayOtter accepteert Google- en Microsoft OAuth-referenties op dezelfde wijze.

Twee zaken gaan hier vaak mis, en het is nuttig deze te kennen voordat u begint. Ten eerste moet de redirect URI die u registreert exact overeenkomen met uw publieke URL, inclusief het schema en eventuele achterliggende paden; anders blokkeert Google de verbinding met redirect_uri_mismatch in het toestemmingsscherm. Ten tweede geeft een Google-project dat in de Testing publicatiestatus blijft staan, refresh tokens uit die na zeven dagen verlopen. De synchronisatie werkt de hele week en stopt daarna, waarbij de applicatielogs bij de volgende verversing invalid_grant tonen. Zet het toestemmingsscherm op In production, of accepteer dat u elke maandag handmatig opnieuw verbinding moet maken.

CalDAV (calendaring extensions to WebDAV) is de open optie, maar de ondersteuning is beperkter. Cal.com levert een CalDAV-app die nog als bèta is gemarkeerd, geverifieerd tegen servers zoals Baikal, Radicale, Nextcloud en Kerio Connect. Apple iCloud werkt via dezelfde app, maar vereist een app-specifiek wachtwoord in plaats van uw Apple ID-wachtwoord. DayOtter vermeldt Apple via CalDAV naast Google en Microsoft 365.

Een ICS-feed is geen synchronisatie. Een geabonneerde .ics URL is inherent alleen-lezen; het kan dus wel tijd blokkeren op uw boekingspagina, maar het kan nooit de boeking zelf ontvangen. Als een tool enkel ICS aanbiedt voor uw kalender, beschikt u slechts over de helft van de benodigde infrastructuur en zult u evenementen alsnog handmatig moeten kopiëren.

Easy!Appointments synchroniseert enkel met Google Calendar en niets anders. Rallly leest de beschikbaarheid helemaal niet: het verzamelt stemmen voor een reeks kandidaat-data. Dat is de juiste tool voor "wanneer kunnen wij met zijn zessen afspreken" en de verkeerde tool voor "boek 30 minuten met mij".

Een boekingspagina is openbaar, dus TLS is prioriteit

Het meeste wat mensen zelf hosten is privé. Een wiki, een forum of een dashboard kan achter een VPN of een SSO-login staan en hoeft nooit verbinding te maken met het openbare internet. Een boekingslink kan dat niet. Iedereen naar wie u de link stuurt, moet deze kunnen laden. Dit verandert de configuratie op drie concrete punten.

U heeft een domeinnaam nodig met een A-record dat naar de VPS wijst, nog voordat u iets installeert. U heeft vanaf de eerste dag een certificaat nodig, omdat browsers een gewoon HTTP-formulier als onveilig markeren en uw klant daar zijn naam en e-mailadres invult. Daarnaast moet de publieke URL van de applicatie correct in de configuratie staan. Deze waarde wordt namelijk verwerkt in de links binnen uitgaande e-mails en in de OAuth redirect-URI's. Stel NEXT_PUBLIC_WEBAPP_URL in bij Cal.com, DOMAIN bij Rallly, BASE_URL bij Easy!Appointments, of DAYOTTER_DOMAIN tijdens de installatie, en stel deze in op het https://-adres dat u daadwerkelijk gaat gebruiken.

Rallly en DayOtter regelen TLS voor u. De gebundelde stack van Rallly bevat Traefik en geeft Let's Encrypt-certificaten uit met het adres in ACME_EMAIL. Het installatieprogramma van DayOtter start Caddy met automatische HTTPS. Cal.com en Easy!Appointments doen dit niet, dus plaatst u nginx ervoor en vraagt u het certificaat zelf aan, op dezelfde manier als voor een Let's Encrypt-certificaat op nginx met Certbot. Koppel de applicatiecontainer aan 127.0.0.1, zodat de enige toegangsweg via de proxy loopt die u beheert. Als op dezelfde server al een zelfgehost Trello-alternatief voor uw interne borden draait, houd deze dan achter uw bestaande authenticatie en geef alleen de boekingshost een publiek serverblok.

Cal.com op uw VPS

De Docker-configuratie bevindt zich in een eigen repository en de images zijn vooraf gebouwd op Docker Hub, dus u haalt deze op in plaats van ze zelf te bouwen.

git clone --recursive https://github.com/calcom/cal.diy.git
cd cal.diy
cp .env.example .env
openssl rand -base64 32
openssl rand -base64 24
docker compose pull
docker compose up -d

De eerste willekeurige waarde plaatst u in NEXTAUTH_SECRET en de tweede in CALENDSO_ENCRYPTION_KEY. Beide zijn vereist. Stel DATABASE_URL in en laat NEXT_PUBLIC_WEBAPP_URL naar uw publieke adres wijzen. De gebundelde stack bestaat uit de web-app, PostgreSQL en Prisma Studio; de documentatie geeft docker compose up -d calcom voor het draaien van de app zonder de meegeleverde database, wat de gewenste methode is zodra de installatie is afgerond.

Haal de image op en bouw deze niet op de VPS. De instructies van het project zelf adviseren om NODE_OPTIONS="--max-old-space-size=16384" te exporteren bij het bouwen vanuit de broncode, wat neerkomt op een heap van 16 GB voor alleen Node. Voeg op ARM-hardware het achtervoegsel -arm toe aan de image-tag. Het project specificeert geen minimumvereisten voor het draaien van de vooraf gebouwde image, dus hanteer 2 GB voor de app plus PostgreSQL als mijn werkbare schatting in plaats van als gedocumenteerde waarde, en monitor het geheugengebruik gedurende de eerste week.

Controleer of de service is opgestart:

docker compose ps
docker compose logs -f calcom
curl -sI https://cal.example.com | head -n 1

De curl-opdracht zou HTTP/2 200 moeten retourneren. Een 502 Bad Gateway van Nginx terwijl de container als actief wordt weergegeven, betekent meestal dat de eerste opstart nog bezig is met het toepassen van database-migraties. Wacht enkele minuten en lees de logs voordat u concludeert dat er een fout is opgetreden. De webhooks van Cal.com worden geactiveerd bij elke bevestigde boeking, waardoor een boeking de automatisering kan aansturen die u al gebruikt, bijvoorbeeld een n8n-instantie die via HTTPS op uw VPS bereikbaar is.

De kern is AGPLv3, waarbij sommige functies zijn ondergebracht in een enterprise-directory onder een afzonderlijke commerciële licentie. Lees die licentie door voordat u een betaald bedrijfsproces bouwt op basis van de teamfuncties.

Easy!Appointments op een 1 GB server

De vereisten zijn Apache of Nginx, PHP 8.2 of nieuwer, en MySQL. Er is een officiële image beschikbaar op alextselegidis/easyappointments.

Eerst een waarschuwing. De docker-compose.yml in de repository is een ontwikkelomgeving. Deze verwacht dat u een shell opent in de container en npm install && composer install && npm start uitvoert. Dit is geen deployment. Gebruik in plaats daarvan de gepubliceerde image:

services:
  easyappointments:
    image: alextselegidis/easyappointments  # pin the current tag from Docker Hub
    environment:
      - BASE_URL=https://book.example.com
      - DB_HOST=mysql
      - DB_NAME=easyappointments
      - DB_USERNAME=easyapp
      - DB_PASSWORD=change-me
    ports:
      - '127.0.0.1:8080:80'
    depends_on:
      - mysql
  mysql:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=change-me-too
      - MYSQL_DATABASE=easyappointments
      - MYSQL_USER=easyapp
      - MYSQL_PASSWORD=change-me
    volumes:
      - ./mysql:/var/lib/mysql

BASE_URL moet het publieke HTTPS-adres zijn. Als dit onjuist is, verwijzen de boekingslinks in bevestigingsmails naar een host die uw klant niet kan bereiken. De image serveert standaard HTTP op poort 80 zonder eigen certificaat; daarom is de poort gekoppeld aan 127.0.0.1 en handelt Nginx de TLS-terminatie aan de voorzijde af. Als de compose-syntaxis nieuw voor u is, begin dan bij Docker Compose basisbeginselen op een VPS en keer daarna terug.

Dit is met grote afstand de lichtste optie in dit overzicht. Twee containers, een PHP-applicatie en MySQL, draaien moeiteloos op een 1 GB VPS. De prijs voor deze lichtheid is het bereik: Google Calendar is de enige ondersteunde kalender-backend en de interface is een traditioneel beheerderspaneel in plaats van een moderne boekingsflow. Als uw kalender Microsoft 365, Fastmail of Nextcloud is, dan is deze optie niet geschikt voor u.

Rallly voor groepspeilingen

Rallly beantwoordt een andere vraag. Het publiceert niet uw beschikbaarheid. Het legt een reeks kandidaat-tijden voor aan een groep en verzamelt stemmen; dit is wat u nodig heeft voor een bestuursvergadering, maar het is onbruikbaar voor een boekingslink voor klanten.

curl -fsSL https://get.rallly.co | bash

Lees elk script voordat u het naar een shell pipe. Vervang bash door less, lees wat het doet en voer het daarna uit. De handmatige methode voert hetzelfde werk uit in stappen die u kunt volgen:

git clone https://github.com/lukevella/rallly-selfhosted.git
cd rallly-selfhosted
./rallly.sh setup
./rallly.sh start

De gedocumenteerde vereisten zijn minimaal 2 GB RAM, Docker 19.03 of nieuwer met Compose v2, vrije poorten 80 en 443, en een domein dat naar de server wijst. De gebundelde stack bestaat uit Traefik voor HTTPS, de webapplicatie, PostgreSQL en Garage voor S3-compatibele objectopslag. Stel DOMAIN in, een SECRET_PASSWORD van minimaal 32 tekens, SUPPORT_EMAIL en INITIAL_ADMIN_EMAIL. Als u al een reverse proxy gebruikt, stel dan PROXY_MODE=external en WEB_PORT in, zodat Traefik niet in de weg zit. Als u al een zelfgehoste S3-compatibele objectopslag met MinIO gebruikt, wijs de S3_*-variabelen daar dan naar en verwijder de Garage-container.

SMTP is hier niet optioneel, omdat het inloggen via een magic link verloopt. Zonder werkende relay kan niemand inloggen, inclusief het beheerdersaccount dat u zojuist heeft aangemaakt. Dat is de gunstige versie van een e-mailfout: het blokkeert u bij de deur in plaats van dat u drie weken later de boeking van een klant verliest.

DayOtter, de nieuwste toetreder

DayOtter is een AGPLv3-platform voor agendabeheer met een ingebouwde assistent. De productie-installatie bestaat uit één commando:

curl -fsSL https://raw.githubusercontent.com/Dayotter/dayotter/main/deploy/install.sh \
  | sudo DAYOTTER_DOMAIN=cal.example.com bash

Lees het script door voordat u het uitvoert, zoals hierboven vermeld. Het installatieprogramma configureert Docker, genereert geheimen en start de volledige stack: de Next.js-webapplicatie, een achtergrondproces voor herinneringen, agendasync en webhooks, PostgreSQL, Redis en Caddy met automatische HTTPS.

De ondersteuning voor agenda's is de meest uitgebreide van de vier. Google, Microsoft 365, Apple via CalDAV en ICS-feeds worden ondersteund, met inachtneming van de eerder genoemde voorbehouden voor ICS. Elke andere integratie is optioneel en wordt geactiveerd via omgevingsvariabelen, waaronder SMTP of Resend voor e-mail, ANTHROPIC_API_KEY voor de assistent, Twilio voor sms en Stripe voor betalingen. De assistent werkt volgens het principe 'bevestiging eerst': deze doet een voorstel, u keurt dit goed en er wordt niets aan uw agenda toegevoegd zonder expliciete toestemming. Laat de API-sleutel leeg en dat onderdeel van het product wordt simpelweg niet uitgevoerd.

De licentiëring is transparant voor self-hosters. De kern is AGPLv3 en een ee/-directory bevat een commerciële licentie die alleen voor de cloud geldt en inactief blijft tenzij DAYOTTER_CLOUD=1 is ingesteld. Dit betekent dat de teamfuncties van het gehoste abonnement, dat per augustus 2026 $9 per gebruiker per maand kost, beschikbaar zijn op uw eigen server.

Dit is tevens de zwaarste stack in dit overzicht en het jongste project. Laat het twee weken naast uw huidige boekingslink draaien, verwerk echte boekingen via beide systemen en controleer de logs van de worker voordat u uw klanten migreert.

Wat elke stack u daadwerkelijk kost

Het aantal containers is de betrouwbare graadmeter voor de belasting die een stack van een kleine VPS vraagt, aangezien elke service een eigen minimaal geheugengebruik heeft. Dit zijn de aantallen uit de gepubliceerde Docker-stacks van elk project, zoals vastgesteld in augustus 2026.

[
  {
    "tool": "Easy!Appointments",
    "containers": 2,
    "database": "MySQL"
  },
  {
    "tool": "Cal.com",
    "containers": 3,
    "database": "PostgreSQL"
  },
  {
    "tool": "Rallly",
    "containers": 4,
    "database": "PostgreSQL"
  },
  {
    "tool": "DayOtter",
    "containers": 5,
    "database": "PostgreSQL and Redis"
  }
]

Easy!Appointments heeft 2 containers nodig en past op 1 GB. De gebundelde stack van Rallly bevat 4 containers en de documentatie adviseert 2 GB. De installer van DayOtter start 5 containers, waardoor dit de zwaarste optie is van de 4 hier. Cal.com en DayOtter publiceren geen minimaal geheugenvereiste; daarom hanteer ik 2 GB als uitgangspunt in plaats van een officieel ondersteund getal.

Twee van deze aantallen vallen lager uit als u al over infrastructuur beschikt. De Traefik- en Garage-containers van Rallly kunnen worden verwijderd wanneer u de applicatie koppelt aan uw eigen proxy en object storage. Prisma Studio van Cal.com is een development-tool die u niet op een publieke server moet laten draaien.

Welk zelfgehost alternatief voor Calendly moet u kiezen

Een zelfstandig consultant kan het beste Cal.com gebruiken. Het is het enige project in dit overzicht dat een herkenbare boekingspagina combineert met kant-en-klare images, waardoor uw VPS geen Node-build hoeft uit te voeren. Daarnaast biedt het een CalDAV-pad voor gebruikers die geen agenda bij Google of Microsoft bijhouden. Eén PostgreSQL-database en één applicatiecontainer vormen een onderhoudslast die u jarenlang kunt dragen. Plan een middag in voor de OAuth-client en de mail-relay. Houd er rekening mee dat de CalDAV-app nog in bèta is; test daarom een volledige boeking van begin tot eind voordat u de link publiceert.

Een klein team kan beter naar DayOtter kijken. Weighted round robin en collectieve boekingen zijn onderdeel van de AGPLv3-kern. Zelf-hosting biedt u hierdoor functies waarvoor bij gehoste diensten per gebruiker betaald moet worden. Het worker-proces is bovendien ontworpen voor de herinneringen en webhooks waar een team daadwerkelijk op vertrouwt. Het nadeel is de volwassenheid: het is het nieuwste project in deze lijst. Draai het daarom eerst parallel aan uw huidige systeem en houd de oude link actief totdat u een volledige maand aan boekingen heeft gemonitord.

Twee specifiekere gevallen: als u enkel een peiling nodig heeft om een geschikt tijdstip voor een groep te vinden, installeer dan Rallly en zoek niet verder. Als u beschikt over een VPS van 1 GB, uitsluitend Google Calendar gebruikt en de kleinst mogelijke oplossing zoekt voor het aannemen van boekingen, dan zal Easy!Appointments langer meegaan dan elke complexere optie die u op die server zou kunnen plaatsen. Voor de bredere vraag wat nog meer de moeite waard is om op dezelfde server te hosten, zie wat is de moeite waard om in 2026 zelf te hosten.

FAQ

Kan ik een zelfgehoste boekingspagina draaien zonder domeinnaam?

Nee. Elk van deze applicaties schrijft de publieke URL in de links binnen bevestigingsmails. Bovendien vergelijken Google en Microsoft de OAuth redirect URI met diezelfde waarde, waardoor een kaal IP-adres leidt tot redirect_uri_mismatch in het toestemmingsscherm. Let’s Encrypt geeft evenmin certificaten uit voor IP-adressen, waardoor de pagina via onbeveiligd HTTP laadt en de browser het formulier als onveilig markeert. Koop eerst het domein, wijs een A record naar de VPS en installeer daarna de software.

Waarom komen mijn boekingsbevestigingen nooit aan?

Dit komt bijna altijd doordat de server de mail zelf probeert te bezorgen. De meeste VPS-providers blokkeren uitgaande poort 25 op nieuwe accounts, waardoor de verbinding blijft hangen. Zelfs als de poort open is, heeft een nieuw IP-adres geen verzendreputatie en weigeren grote mailontvangers de berichten. Koppel de applicatie aan een transactionele mail-relay op poort 587, controleer of de poort bereikbaar is met nc -vz -w 5 "$SMTP_HOST" 587 en publiceer vervolgens de SPF- en DKIM-records die de relay verstrekt. Als u Cal.com draait, controleer dan of u de meegeleverde EMAIL_SERVER_HOST=localhost en EMAIL_SERVER_PORT=1025 standaardwaarden heeft vervangen, aangezien deze naar een lokale ontwikkelingsmailbox verwijzen.

Synchroniseert zelfgehoste Cal.com met CalDAV, of alleen met Google?

Met beide, al verschilt de volwassenheid. De CalDAV-app heeft een bèta-status en is geverifieerd tegen servers zoals Baikal, Radicale, Nextcloud en Kerio Connect. Apple iCloud werkt hier via een app-specifiek wachtwoord. Google Calendar en Microsoft 365 synchroniseren beide in twee richtingen, maar bij een zelfgehoste installatie moet u uw eigen OAuth-client aanmaken en deze opgeven via GOOGLE_API_CREDENTIALS, omdat de inloggegevens van de gehoste dienst niet in de broncode staan.

Waarom stopt mijn Google Calendar-synchronisatie na een week?

Omdat het Google Cloud-project nog de publicatiestatus Testing heeft. Google geeft in die status refresh tokens uit die na zeven dagen verlopen. De verbinding werkt dus aanvankelijk, maar verbreekt bij de volgende tokenvernieuwing, waarna het applicatielogboek invalid_grant toont. Zet het OAuth-toestemmingsscherm op In production en koppel de agenda eenmalig opnieuw. Opnieuw koppelen zonder de status te wijzigen levert u slechts nog eens zeven dagen op, en niet meer.

Welke van deze applicaties draaien op een 1 GB VPS?

Easy!Appointments wel, aangezien dit een PHP-applicatie met MySQL is. Rallly documenteert een minimum van 2 GB en de gebundelde stack draait vier services. Cal.com en DayOtter publiceren geen minimum, maar een Next.js-applicatie met PostgreSQL (en in het geval van DayOtter ook Redis en een worker-proces) betekent dat u moet rekenen op 2 GB of meer. Bouw Cal.com nooit vanaf de broncode op een kleine machine: de eigen bouwinstructies van het project vereisen een Node-heap van 16 GB; haal daarom de vooraf gebouwde image op.