1. Pilae
2. Apps
3. Cal.com

Running Cal.com in production: what it takes

1. Pin and deploy

   Cal.diy at a version we have tested, on PostgreSQL, with the encryption key generated for you and kept apart from the database.

2. Register the calendar apps

   Calendar connections go through app registrations in your own Microsoft or Google tenant, so the credentials are yours and can be revoked by you.

3. Publish the booking pages

   Booking pages answer publicly through the Pilae gate on port 443, the one hardened entry point. The machine and its database stay on your private network.

4. Back up and restore on a schedule

   The database goes offsite daily, encrypted, in your chosen country, with the key backed up separately. Once a month we restore it into a scratch instance, book a test slot and record the result in the console.

5. Follow upstream fixes

   We follow Cal.diy releases and the security advisories on its repository. The Pilae Agent tests each release on a copy of your data, waits for your approval and applies it in your window.

What Cal.com is, and who runs it

Cal.com system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory

2 vCPU · 4 GBOne Next.js application container. Booking pages are light, and calendar sync scales with the number of connected calendars, not with visitors.

Database

PostgreSQLHolds users, event types, availability, bookings and the tokens for connected calendars. It is the one thing that has to come back after a restore.

Encryption key

AES-256 key, stored apartEncrypts the calendar and video credentials in the database. It is backed up separately, so a database dump alone does not expose your calendars.

Calendar connection

Entra ID app · Google OAuth · CalDAVAn app registration in your own tenant reads free and busy times and writes bookings. CalDAV covers Nextcloud and other standard servers.

Outgoing mail

SMTP relayConfirmations, cancellations and reschedules go to attendees from your own domain.

DNS and TLS

1 public hostnameBooking pages must be reachable by the people booking, so unlike most apps we run, Cal.com has a public hostname, served through the Pilae gate on port 443.

Migrating from Calendly to Cal.com

There is no import from Calendly, and not much needs one. What a Calendly account holds is event types, availability and connected calendars, and each person sets those up again in a few minutes. The bookings themselves already live in your calendars, so nothing is lost when the account closes. The parts to plan are the links. Every booking link in email signatures, on the website and in old messages points at Calendly, so we list them, publish the new pages, and keep the Calendly pages open with a pointer to the new ones until the subscription ends. Team scheduling is the other thing to check first. Round-robin and collective events are not in Cal.diy, so a team that relies on them needs a different setup, and we say so before the move rather than after.

1. List people and links

   Who books meetings through Calendly, which event types they use, and where their links are published: signatures, the website, templates, forms.

2. Check team scheduling

   Round-robin and collective events are not in Cal.diy. If a team depends on them, we settle how they will book before anyone moves.

3. Set up event types and calendars

   Each person connects their Microsoft 365, Google or CalDAV calendar and recreates their event types and availability, with us on hand for the first ones.

4. Swap the links, then close Calendly

   New links go into signatures, the website and templates. Calendly stays open until no new bookings have arrived there for a full cycle.

Where a booking goes

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Cal.com costs

On Starter, Cal.com runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Cal.com: common questions

Also in business