Which fits a solo practitioner: Acuity Scheduling or Cal.diy?
A solo provider who takes client bookings usually asks one question first: does Acuity's bundled set of features justify paying by bookable calendar, or is the MIT license of Cal.diy enough to start with? The answer depends on what has to work on the first day. Acuity fits when intake forms, packages, gift certificates and payments must be live before anyone books, because those features are part of the product rather than something you assemble later. Cal.diy is built around event types, availability and calendar connections, and its integrations with Google Calendar and Microsoft Graph cover the calendar side well. It does not include the intake, package and gift certificate workflows that a practice running paid sessions often relies on, so each of those would need to be designed, built and tested by you or a contractor.
Cal.diy fits personal, non-production scheduling run by someone comfortable with server administration. The project's README says self-hosting is at your own risk, strongly recommended for personal, non-production use, and requires advanced knowledge of server administration, database management and securing sensitive data. The stack is Next.js, Prisma and PostgreSQL 13 or later, so the operator owns upgrades, backups, TLS and patching. Before choosing it, confirm the calendar connections you need in the Settings, Integrations page, check the current release notes on the GitHub releases page, and decide who will apply security updates. If that person does not exist, the saving on subscription fees is likely to be spent on time when something breaks.
The decision turns on three things. The first is production need: whether client bookings with payments and intake are a business dependency or a personal convenience. The second is data control: intake answers and client contact details are sensitive, and self-hosting keeps them on servers you choose, but only if you secure them. The third is operating capacity: who will run the server, restore backups and handle outages. Ask Acuity for its current plan pricing and what each feature requires, and map each intake or payment requirement to a concrete check. If the list of must-have features is long and the operator is one person without server experience, the hosted tool is the lower-risk choice even though it costs more each month.
Which option fits which practice scenario
This table matches common Acuity Scheduling use cases to Cal.diy or a different path, and gives the reason each fit holds. Read each row against your own booking needs, and treat Cal.diy's self-hosting advice as a deciding factor when the scenario involves client data or compliance duties.
| Scenario | Better fit | Reason and the condition that makes it true |
|---|---|---|
| Solo practitioner with a personal booking link and no intake forms | Cal.diy | Event types, availability and calendar sync cover this need, and the MIT license carries no license fee. This holds only if you can run a Node.js and PostgreSQL service and accept self-hosting at your own risk. |
| Solo practitioner who collects intake forms before each session | Acuity Scheduling | Acuity includes intake forms, while Cal.diy's README does not present intake questionnaires as a comparable feature. Confirm current form capabilities in Cal.diy before deciding. |
| Coach who only needs a shareable booking link tied to Google or Outlook calendars | Cal.diy | Calendar connections through Google Calendar and Microsoft Graph match this use. The fit weakens if you later need payment collection or client-side packages. |
| Practice that sells session packages or gift certificates | Acuity Scheduling | Packages and gift certificates are features Acuity offers and Cal.diy does not list. Ask Acuity's sales team to confirm the plan level that includes them. |
| Practice that needs payments collected at booking | Acuity Scheduling | Acuity's hosted checkout is a built-in capability. Cal.diy would require you to confirm and configure a payment path yourself. |
| Organization with HIPAA or other compliance obligations | Neither as a default, confirm with counsel | Cal.diy is recommended for personal, non-production use, so it is a weak basis for regulated intake data. Acuity's business associate agreement terms are tied to its higher plan, so verify them before choosing. |
| Team needing shared calendars, round-robin routing or single sign-on | Cal.com hosted or Cal.com enterprise | Cal.diy removes Teams, Organizations and SSO features, and the README points commercial and enterprise users to Cal.com. Compare Cal.com pricing directly before deciding. |
Where bookings, invitee details and calendars live
Under Acuity, bookings, invitee details and calendar data sit on a vendor-hosted service that you configure but do not operate. Cal.diy moves that data onto your own servers, which shifts location, identity and safeguard decisions to your team. The cards below cover what changes and what you must check before choosing either path.
Data location under each model
Acuity stores bookings, client names, emails and intake answers in Squarespace's hosted environment, so you rely on its contracts and regional hosting for location. With self-hosted Cal.diy, the database and any uploaded files sit wherever you deploy them. Ask Acuity which data centers hold your account, and decide where your own Cal.diy instance and its backups will live before you move any invitee records.
PostgreSQL and Node.js footprint
Cal.diy is built with Next.js, tRPC, React, Tailwind CSS and Prisma, and requires Node.js 18 or later and PostgreSQL 13 or later. Your team must run the application server, the database, TLS, updates and backups, all of which Acuity handles for you today. Confirm that someone on your staff can patch Node.js and PostgreSQL on a schedule, and that restores have been tested.
Identity and SSO limits
Cal.diy removes SSO and SAML along with the other features that were Enterprise-only in Cal.com. Staff sign-in therefore relies on the local accounts that Cal.diy provides, so you own password policy, account lifecycle and offboarding. If your practice needs a central identity provider, plan a separate identity layer or confirm that the commercial Cal.com tiers meet the requirement before you commit.
Safeguards for sensitive intake data
Intake forms often capture health, financial or personal details. Under Acuity, the vendor operates much of the security stack, while under Cal.diy you own encryption at rest and in transit, access logging, backup protection and vendor-neutral audit evidence. The Cal.diy README states that self-hosting is at your own risk and requires advanced knowledge of server administration and securing sensitive data, so assess that skill set honestly.
Compliance evidence and what DeployOpen provides
Self-hosting does not give you a compliance attestation. Regulated practices must still show controls over access, change, backup and incident response to an auditor or regulator. DeployOpen can plan and implement those controls and prepare the supporting evidence, but independent auditors and certification bodies issue any audit report or attestation. Confirm the specific requirements that apply to your practice with your compliance advisor before deciding.
Production use and maintainer guidance
The Cal.diy README states that self-hosting is strictly recommended for personal, non-production use, and it directs commercial and enterprise scheduling users to Cal.com. For a practice that takes paid bookings from clients, this means you would run a version the maintainers do not recommend for that purpose. Weigh this against the ongoing maintenance you accept, and ask whether a supported Cal.com tier meets your needs.
Why Cal.diy's maintainers advise against production use
The Cal.diy README is direct about where the fork belongs. Self-hosting is at your own risk, it is strictly recommended for personal, non-production use, and it requires advanced knowledge of server administration, database management and securing sensitive data. For a solo practitioner replacing Acuity, that last point is the one that matters most. Acuity holds the client's name, contact details, appointment history and any intake answers in a vendor's managed environment. With Cal.diy, the same records sit in a PostgreSQL database on a server you are responsible for, and the patching, backups, access control and TLS certificates become your job.
Before choosing Cal.diy for client bookings, check whether your records are personal or regulated. A pilot with your own calendar and test invitees is a reasonable use of a non-production setup. Holding real client data is a different decision. Confirm who will apply security updates to the Next.js, Prisma and Node.js stack, who restores the database after a failure, and whether you can document how invitee data is stored and deleted. If you cannot name those owners, the risk is operational, not theoretical.
The README also points commercial and enterprise scheduling users toward Cal.com, and says enterprise on-premises access is handled through Cal.com sales. Treat that as a signal about support, not a judgment about your practice. If your bookings are tied to a business with several staff members, a regulated obligation or an SSO requirement, ask Cal.com directly what it offers for your setup before you commit to a self-hosted build. A short written question about support scope, hosting options and data location will tell you more than any comparison table.
What Acuity costs and what Cal.diy costs to run
Acuity bills a recurring subscription that scales with bookable calendars, while Cal.diy carries no license fee but moves hosting, database, upgrades and security onto your team or a provider. The cards below separate those components so you can compare like with like in a quote.
Acuity subscription by bookable calendar
Acuity's recurring fee is set by the number of bookable calendars and by the plan tier, and the features you need may sit on a higher tier. Before comparing, list every calendar you will publish, every intake form and payment option you rely on, and any HIPAA or API requirement, then confirm the current plan that includes each one on Acuity's own pricing page. Ask whether the cost changes with staff additions or annual billing.
Cal.diy license and vendor reference
Cal.diy is MIT licensed, so there is no license fee to pay for the software itself. Cal.com's hosted plans are a reference point only: they price per user, and they are not the cost of running Cal.diy yourself. Confirm that any feature you need is in the Cal.diy codebase, because enterprise-only features were removed from it and Cal.diy's README sends commercial users toward Cal.com.
Server hosting and database
Cal.diy runs on Node.js 18 or later with PostgreSQL 13 or later, and its Docker image is published on Docker Hub. Hosting cost depends on whether you use your own servers, a cloud account or a managed PostgreSQL service, and on backup retention and high availability needs. Ask the provider to price compute, storage, database backups and restore testing as separate lines.
Integration setup and calendar sync
Google Calendar, Microsoft Graph, Zoom, Daily.co, Webex, HubSpot, Zoho and Pipedrive connections are added from the Integrations settings page, but each one needs its own OAuth app, credentials and testing. For a solo practitioner, budget time for connecting your calendar and video provider and for checking that availability updates correctly after a change. Ask whether the quote includes these connections and a test booking for each.
Security hardening and patching
The README says self-hosting is at your own risk and requires advanced knowledge of server administration, database management and securing sensitive data. Intake answers and client contact details are sensitive, so you own TLS, access control, secrets, backups and monitoring. Ask for a written hardening baseline, a documented patch cadence and an owner for security alerts before go-live.
Upgrades, support and staff time
Cal.diy moves with its upstream repository, and the latest GitHub release of calcom/cal.com was v6.2.0, published on March 1, 2026. Each upgrade needs a test instance, a database migration check and a rollback plan. Whether you do this in-house or through a retainer decides the recurring cost, so ask for upgrade frequency, response times and who holds the admin credentials in any proposal.
What moving from Acuity to Cal.diy involves
The sequence turns an Acuity account into a self-hosted Cal.diy booking setup, with a clear record of what carries over, what must be rebuilt, and which features are gone. It also gives you a checkpoint to decide whether Cal.diy's non-production guidance is acceptable for your practice before you switch the booking link.
Decide whether the non-production limit fits
Before any build work, the practice owner reads the Cal.diy README, which says self-hosting is at your own risk, strictly recommended for personal, non-production use, and needs advanced skills in server administration, database management and securing sensitive data. If the booking flow will hold client names, contact details or intake answers in production, record that decision in writing, either accepting the risk with a named owner or reassessing the choice with a different option. The step is done when that decision is signed off and the owner knows who maintains the server.
Inventory event types and availability
Export or list every Acuity appointment type, its duration, buffer times, location, the calendar it draws from, and its weekly availability rules. Note which types are bookable by clients, which are internal, and which have minimum notice or maximum booking windows. The output is a single sheet that maps each Acuity type to the Cal.diy event type it will become, so nothing is rebuilt from memory. Confirm the details against your live Acuity settings rather than your recollection.
Rebuild event types and calendar connections in Cal.diy
Install Cal.diy on the server you control, using the Node.js and PostgreSQL versions its README lists, and create the event types from your inventory. Connect each calendar from the Settings, Integrations page, covering Google Calendar or Microsoft Graph for Office 365 and any conferencing service you use, such as Zoom. Check each connection by creating a test booking and confirming it appears on the correct calendar. The step is complete when every event type books onto the intended calendar with the right duration and availability.
Decide how intake forms, packages and gift certificates are handled
List every Acuity feature in use beyond plain booking, including intake questionnaires, packages, gift certificates and payment collection. Cal.diy does not replicate these in the way Acuity does, so for each one choose a path: keep the feature in Acuity until the booking link switches, collect the information through a separate form or document you run, or retire it and tell clients. Put the decision for each feature in writing with the person who will answer client questions. The output is a short table of features, decisions and owners.
Export or re-enter client and appointment records
Export client lists and upcoming appointments from Acuity in the formats it offers, then check which fields the export contains before importing anything. Decide which records to carry over, typically upcoming appointments and the contact details needed to reach clients, and avoid moving data you do not need for scheduling. Where a record cannot be imported cleanly, re-enter it by hand and log the count. Confirm the file contents and where the stored data will sit on your server before you load anything.
Test bookings, reminders and integrations end to end
Run test bookings for each event type from an outside browser, including a reschedule and a cancellation. Confirm that confirmation emails arrive, that the calendar entries appear on the connected calendars, that conferencing links are generated where expected, and that availability respects the rules from your inventory. Ask a colleague or a trusted client to try the flow and note any confusing text. The step is done when every test booking matches the Acuity behavior you documented, or when any gap is written down with the workaround chosen.
Switch the booking link and keep Acuity running briefly
Update the booking link on your website, email signature and any social profiles to point to the Cal.diy booking page, and remove or redirect the old Acuity links. Keep the Acuity account active for a period you set in advance so existing appointments and client messages can be handled there. Tell clients in advance where to book and what has changed. The switch is complete when the public links resolve to the new page and the team has confirmed where each upcoming appointment now lives.
Questions solo practitioners ask before switching
How much effort does a self-hosted Cal.diy setup take?
Expect a real server project, not a plug-in install. Cal.diy is built with Next.js, tRPC, React, Tailwind CSS and Prisma, requires Node.js 18 or later and PostgreSQL 13 or later, and publishes a Docker image on Docker Hub. The work breaks into four parts: provisioning a host, running the database, configuring the application and its domain, and connecting your calendars. Each part recurs as the project changes. The effort is driven mainly by whether you already run Node and PostgreSQL services and how much you want to manage yourself. Ask any implementer for the setup steps in writing before agreeing to a scope.
Can a solo practitioner run Cal.diy without a technical partner?
Only if you are comfortable with server administration, database management and securing sensitive client data. The Cal.diy README says self-hosting is at your own risk, strictly recommended for personal, non-production use, and requires that advanced knowledge. If you lack that skill, the choice is between learning it, paying someone to run it, or staying on a hosted service. Be honest about who would restore the database after a failed update at 9 p.m. on a booking day. A retained support agreement is one option, and DeployOpen offers ongoing support and upgrades as retainers, scoped in writing.
What recurring work do upgrades and backups create?
Recurring work falls into three groups: applying application releases, keeping the operating system, Node.js and PostgreSQL patched, and testing restores. Cal.diy is a fork of an actively developed codebase, and the latest release of the calcom/cal.com repository is v6.2.0, published on March 1, 2026, so plan for regular change. Backups must cover the database and any uploaded files, and a backup you have never restored is not a backup. Ask whoever runs it for the frequency of upgrades, where backups are stored and how often a restore is tested.
Can Cal.diy replace Acuity's intake forms and packages?
No, not as a like-for-like swap. Cal.diy covers event types, availability and calendar connections, and it documents integrations with Google Calendar, Microsoft Graph, Zoom and others, added from its Settings, Integrations page. Acuity's intake forms, packages and gift certificates are not part of Cal.diy's feature set, so you would need to confirm each one against the current code or build it yourself. Write down every Acuity feature your practice uses today, then mark each as native, workaround or custom work before deciding.
What does a fixed-scope implementation cover?
A fixed-scope engagement sets out in writing what gets built, configured, tested and handed over, with deliverables and timelines agreed before work starts. For a booking project, typical scope items include hosting setup, application installation and configuration, calendar and video integrations, domain and email settings, backup and restore procedures, and documentation for your team. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, but it does not publish a price list. A quote follows from the written scope, so list your required features first.
How long does a migration from Acuity to Cal.diy take?
No researched timeline is available for this migration, so treat any duration as unknown until a scope is written. The main drivers are the number of event types, how many calendars need connecting, how much client history must move, and how many Acuity features need replacement or custom work. A practice with a few event types and no intake forms will move faster than one with packages and forms. Ask any implementer for a dated plan that lists each phase, its dependencies and what you must approve.
When is Easy!Appointments a better path than Cal.diy?
Easy!Appointments fits better when your core need is appointment management for services and providers rather than a public scheduling product. It is a self-hosted appointment scheduler under GPL v3.0, runs on PHP 8.2 or later with MySQL, and suits practices that want a simpler stack. Cal.diy is strictly recommended for personal, non-production use, so if you need a durable production system, Easy!Appointments or a commercial option deserves a close look. Compare both against your Acuity feature list, not against the marketing pages.
When staying with Acuity is the right call
Staying with Acuity makes sense when the practice relies on features that Cal.diy does not provide and when nobody on the team wants to operate a server. Acuity bundles intake forms, packages and gift certificates into the booking flow, so a solo therapist, coach or instructor who sells a block of five sessions or a prepaid gift can run that whole sale from one vendor. Those features sit in the same product as the calendar, which means there is no second system to connect, test and keep current. If the revenue model depends on packages and prepaid credits, rebuilding them on a self-hosted scheduler is a product project, not a configuration task, and that effort should be priced against the subscription before anyone commits to it.
The advantage also includes the operating burden you do not take on. Cal.diy's README describes self-hosting as being at your own risk, requires advanced knowledge of server administration and database management, and recommends the fork mainly for personal, non-production use. A practice with no IT staff would own patching, backups, TLS certificates, database upgrades and the protection of client intake data. Ask whether anyone on the team can own those tasks every month, and whether an outage on a Sunday evening would cost bookings. If the answer is no, a vendor-run service is a legitimate control, not a shortcut, and the reader should record that reasoning in the decision file.
The choice changes when the requirements change. Acuity's advantage matters most when the practice needs intake and payment in one flow, a vendor to answer support tickets, and no data-hosting obligations beyond what the vendor contract already covers. It matters less when the practice must keep client records inside its own jurisdiction or under a specific hosting contract, which is a question to confirm with Acuity's current plan terms and with your compliance lead before you assume either way. Confirm the features you truly need, list the ones Cal.diy would not cover, and only then compare the subscription cost with the staff time a self-hosted setup would add.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Acuity Scheduling vs Cal.diy, we work from a written scope so you can decide whether Cal.diy fits your practice, or whether a different self-hosted option or a hosted tier of a commercial product makes more sense.
How we scope
- Inventory the event types, availability rules and calendar connections your bookings depend on today
- Define which Acuity features you need, such as intake forms, packages or gift certificates, and mark each as covered, custom or dropped
- Agree the hosting location, database and backup targets in writing before any build work starts
How we build
- Deploy Cal.diy in your cloud account or data center with PostgreSQL 13 or later and Node.js 18 or later
- Connect Google Calendar or Microsoft Graph and test availability sync against real booking scenarios
- Harden the server, secure the database and record the administrator and key-management procedures you will own
How we hand over
- Deliver runbooks for updates, restores and access reviews, written for the person who will run the instance
- Document which Acuity features were replaced, which were not, and what manual steps remain for staff
- Walk your team through booking page configuration and a tested rollback path before switching the public link
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build
- Track upstream Cal.diy releases and plan upgrades on a schedule agreed with your team
- Repeat security testing of the booking application and its APIs when your scope or hosting changes
