Deploy and Host Cal.com on Railway

Cal.com is the leading open-source scheduling platform — a self-hosted alternative to Calendly for letting people book meetings on your calendar without the back-and-forth. Create event types, share a booking link, sync with Google and Outlook, run team round-robin scheduling, and collect payments — unlimited event types, no per-seat fees. This template deploys Cal.com with PostgreSQL and the encryption keys and app URL configured correctly — so your scheduling server is live, with the setup traps that corrupt calendar connections already avoided.

What This Template Deploys

Service	Purpose
Cal.com	The scheduling app, booking pages, and admin (Next.js) on port `3000`
PostgreSQL	Bookings, event types, users, and encrypted calendar credentials

Both connect over Railway's private network. Cal.com serves the booking interface and API, with PostgreSQL holding all data including the encrypted OAuth tokens for connected calendars. Railway provides automatic HTTPS, which Cal.com needs for correct booking links.

About Hosting

Cal.com is powerful, and two secrets plus the app URL are the difference between a smooth setup and a corrupted one — this template handles all three.

CALENDSO_ENCRYPTION_KEY must never change after first run — this is critical. This key encrypts your users' stored calendar credentials (Google and Microsoft OAuth tokens). If it changes after the first start, every connected calendar's credentials become permanently unreadable, and all users must reconnect their calendars. This template generates it once and keeps it stable — but back it up externally, because it can never be rotated without breaking every integration.

NEXTAUTH_SECRET secures sessions. A separate 32-byte secret signs sessions and must also stay stable, or active logins are invalidated. This template generates it; keep it constant across redeploys.

NEXT_PUBLIC_WEBAPP_URL must be your final HTTPS domain. Cal.com bakes its public URL into booking pages and confirmation emails, so it must be your Railway (or custom) HTTPS domain. If it's wrong, booking links and email links point at localhost or the wrong host and don't work. This template sets it to your Railway domain, and Railway's automatic HTTPS means secure links work immediately.

PostgreSQL holds everything — back it up. Bookings, event types, availability, users, and the encrypted calendar credentials all live in PostgreSQL — the single source of truth. Database migrations run automatically on startup when the schema changes, so upgrades apply cleanly; check the logs confirm migrations completed after an update.

Configure SMTP for confirmations and reminders. Scheduling depends on email: booking confirmations, reminders, and cancellations all send over SMTP. Set the EMAIL_* variables with your provider so invitees receive their booking emails — without it, bookings work but no one gets notified. On first visit, Cal.com redirects to /auth/setup to create your admin account (NEXT_PUBLIC_LICENSE_CONSENT=agree is set for the community edition).

Typical cost: ~$5–15/month on Railway for Cal.com and PostgreSQL — a small instance runs comfortably, with more RAM for high booking volume. Cal.com's community edition is AGPL-3.0 and free, versus Calendly's per-user pricing.

How It Compares

	Cal.com (self-hosted)	Calendly	Google Calendar	Acuity
Cost model	Flat infra	Per user/month	Free (no booking pages)	Subscription
Event types	Unlimited	By plan	N/A	By plan
Team / round-robin	Yes	Higher tiers	No	Some
Calendar sync	Google, Outlook	Yes	Native	Yes
Data ownership	Full — your infra	Vendor	Google	Vendor
Self-hostable	Yes	No	No	No

Calendly is polished but bills per user and holds your data. Google Calendar has no public booking pages. Acuity is capable but subscription-based. Cal.com's edge is a complete, developer-friendly scheduling platform — unlimited event types, team scheduling, round-robin, payments, and calendar sync — self-hosted at flat cost, with your booking data and calendar credentials on infrastructure you own.

Deploy in Under 5 Minutes

Click Deploy on Railway — Cal.com and PostgreSQL build and wire together (~4 minutes)
Confirm NEXT_PUBLIC_WEBAPP_URL is your Railway domain, and the two secrets are set
Open your Railway URL — Cal.com redirects to the /auth/setup wizard
Create your admin account, then set the EMAIL_* variables for booking notifications
Connect your Google or Outlook calendar and create your first event type and booking link

Share your booking link, and invitees pick a time that syncs straight to your calendar.

Common Use Cases

Personal booking page — share a link and let people book time without email back-and-forth
Team scheduling — round-robin and collective booking across your team, no per-seat fees
Sales and demos — let prospects book calls that sync to your calendar automatically
Data-owned scheduling — keep booking data and calendar credentials on your infrastructure

Configuration

Variable	Required	Description
`CALENDSO_ENCRYPTION_KEY`	Generated	Encrypts calendar credentials — never change after first run
`NEXTAUTH_SECRET`	Generated	Signs sessions — keep stable
`NEXT_PUBLIC_WEBAPP_URL`	Required	Your Railway HTTPS domain — baked into links and emails
`DATABASE_URL`	Auto-injected	PostgreSQL connection via Railway reference
`EMAIL_*`	Recommended	SMTP for booking confirmations and reminders

Never change CALENDSO_ENCRYPTION_KEY. It encrypts calendar credentials — rotating it after first run permanently corrupts every connected calendar. This template sets it once; back it up and keep it stable, along with NEXTAUTH_SECRET.

Set the webapp URL and SMTP. NEXT_PUBLIC_WEBAPP_URL must be your Railway domain or links break, and EMAIL_* must be configured for booking emails to send.

Dependencies for Cal.com Hosting

Railway account — ~$5–15/month for Cal.com and PostgreSQL
PostgreSQL (included and wired via Railway references)
An SMTP provider for booking confirmations and reminders
Optional: Google Cloud or Microsoft OAuth credentials for calendar sync

Deployment Dependencies

Implementation Details

The template runs the official calcom/cal.com:latest image (a Next.js application on port 3000) with a Railway-managed PostgreSQL database over the private network. Two secrets are generated at deploy and must remain stable: NEXTAUTH_SECRET (32 bytes, signing sessions) and CALENDSO_ENCRYPTION_KEY (24 bytes, encrypting stored calendar OAuth credentials). The encryption key in particular must never change after first run — rotating it permanently corrupts all stored calendar connections and forces every user to reconnect — so it should be backed up externally.

NEXT_PUBLIC_WEBAPP_URL is set to the Railway domain because Cal.com embeds its public URL in booking pages and confirmation emails; a wrong value produces broken links pointing at localhost or the wrong host. NEXT_PUBLIC_LICENSE_CONSENT=agree is set for the community edition, and database migrations run automatically on startup when schema changes are present, so upgrades apply on redeploy — logs should be checked to confirm migrations completed.

All data — bookings, event types, users, and encrypted calendar credentials — persists in PostgreSQL, the single backup target. Email for confirmations and reminders is configured through the EMAIL_* SMTP variables, and calendar sync (Google, Microsoft) through OAuth credentials after deployment. First-run setup happens at the /auth/setup wizard.

Frequently Asked Questions

Why must I never change the encryption key? CALENDSO_ENCRYPTION_KEY encrypts your users' stored calendar credentials. Changing it after the first run makes those credentials permanently unreadable, so everyone must reconnect their calendars. This template sets it once — back it up and never rotate it.

Why do booking links or emails show the wrong URL? NEXT_PUBLIC_WEBAPP_URL must be your Railway HTTPS domain — Cal.com bakes it into links and emails. This template sets it correctly, and Railway's automatic HTTPS means secure links work immediately.

Do I need email configured? Yes, for a working scheduler — confirmations, reminders, and cancellations send over SMTP. Set the EMAIL_* variables with your provider, or invitees won't receive booking notifications.

Can I sync Google and Outlook calendars? Yes — set up OAuth credentials for Google (Calendar and People APIs) or Microsoft after deploy, and users connect their calendars so bookings sync both ways.

Why Deploy Cal.com on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Cal.com on Railway you get an open-source scheduling platform with the hard parts solved — PostgreSQL wired, the encryption keys generated once and kept stable, the app URL set, and automatic HTTPS for working booking links. Let people book meetings on your calendar with no per-seat fees, self-hosted on infrastructure you own.