Self-hosted shared calendars and contacts with CalDAV and CardDAV

Self-hosted shared calendars and contacts with CalDAV and CardDAV: why the standards layer decides the build

An organization leaving hosted calendars and address books needs them inside its own infrastructure, and the realistic options are CalDAV and CardDAV on Stalwart, SOGo inside mailcow, or OX App Suite. The choice depends on three things: which desktop and mobile clients your staff already use, whether free/busy lookups and resource booking must work across the organization, and whether calendars must stay separate from the mail system. Calendars and contacts often hold personal data, client names, meeting notes and executive travel details, so access controls, sharing rules and audit trails matter as much as the sync protocol. In practice, the platform is shaped more by client and identity requirements than by feature lists, which is why the first decision should be a written inventory of clients and sign-in methods.

Stalwart supports both CalDAV and CardDAV alongside IMAP, JMAP and SMTP in one server, which suits teams that want a single self-hosted component for mail, calendars and contacts. mailcow bundles SOGo webmail with CalDAV and CardDAV next to Postfix, Dovecot and Rspamd, so the groupware is tied to a mail stack that many teams already run. OX App Suite is a different class of build: the documentation describes a Kubernetes deployment delivered through Helm charts, with Istio or a basic ingress-nginx option and a MariaDB and Redis back end. Confirm with each vendor which client behaviors you need, such as free/busy visibility across domains, shared address books and delegated calendars, by testing your actual Outlook, Thunderbird, iOS and Android configurations before you commit. Ask the partner to document how sharing permissions map to your directory groups.

Which requirements shape a self-hosted calendar and contact build

This table maps each requirement for shared calendars and contacts to its source and to the build decision it forces. Read it before choosing between Stalwart, mailcow with SOGo, or OX App Suite, because client support and directory integration differ by platform and must be confirmed in a proof of concept.

Requirement	Source	Build impact
CalDAV and CardDAV support	Platform fact: Stalwart supports CalDAV and CardDAV; mailcow lists SOGo with CalDAV and CardDAV	Confirm the exact protocol behavior each platform implements, including sharing and scheduling features, before committing to a design
Native client connectivity	Client constraint: desktop and mobile calendar apps used by staff	Test each client you must support against the chosen server version; do not assume native sync for every feature
Free/busy lookup across users	Client constraint: staff need to see availability before booking meetings	Confirm free/busy works across internal users and, if needed, with external organizations; plan name resolution and domain settings accordingly
Resource booking	Client constraint: meeting rooms and equipment need controlled booking	Ask the platform for resource calendars, approval rules and conflict handling; test them with real room lists during the pilot
Directory-based authentication	Client constraint: accounts must follow the corporate identity source	Confirm LDAP or OIDC/SAML integration for the calendar and contact front end; for OX App Suite, review its OpenID Connect and SAML options
Audit of shared calendar access	45 CFR 164.312(b) audit controls, where ePHI appears in calendar entries (HIPAA)	Enable access logging for shared calendars and address books; confirm what the platform records and how long logs are kept
Transmission protection for invitations	45 CFR 164.312(e)(1), where calendar invitations carry ePHI (HIPAA)	Enforce TLS for client connections and server-to-server traffic; confirm how external invitations are protected
Backup of calendar and contact data	Client constraint: loss of appointments and contacts is an operational failure	Back up calendar and contact stores alongside mailboxes and test restores of individual items and full accounts

Which platform fits which calendar scenario

Stalwart is an all-in-one mail and collaboration server that speaks IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV from a single product. It suits organizations that want a small number of moving parts and direct control over the calendar and contact stores, and that have staff comfortable operating a standards-based server rather than a bundled groupware suite. The core is licensed under AGPL-3.0, and an optional Enterprise License is available from Stalwart Labs. The current release listed in the supplied facts is v0.16.26, published on October 11, 2026.

Protocol coverage: CalDAV and CardDAV are served by the same process that handles IMAP, JMAP and SMTP, so mail and sharing follow one configuration model.
Client support: Confirm which desktop and mobile clients you need and test free/busy lookups, shared address books and delegated calendars against them before standardizing.
Web interface: Confirm whether the bundled web access meets your user expectations for calendar sharing and resource booking, or whether you need a separate front end.
Licensing: Ask whether the Enterprise License changes features, support terms or fees you rely on, since the AGPL-3.0 core and the commercial option differ.
Operating burden: Your team owns upgrades, backups and directory integration, so plan for that work in the scope.

Before committing, ask the vendor which CalDAV and CardDAV features are in the edition you will run, and test your real calendar workloads on a staging system.

Which open-source platforms fit shared calendars and contacts, and why

The three groupware options differ mainly in how much of the stack you run yourself and where the calendar and contact services live. Read each card against your mail estate, your identity layer and the clients your users already carry, because the native client matrix often settles the choice before the platform does.

Stalwart as a single mail and groupware server

Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV in one product. It fits teams that want calendars and contacts served from the same binary as mail, with fewer moving parts to patch. Check that the AGPL-3.0 license works for your distribution model, and confirm with Stalwart Labs whether the optional Enterprise License changes support or feature scope you need. Verify client compatibility for free/busy lookups and resource booking against your target clients before committing.

mailcow with SOGo for webmail groupware

mailcow bundles Postfix, Dovecot and Rspamd with SOGo webmail, and SOGo provides CalDAV and CardDAV alongside the mail services. It suits organizations that want a packaged mail stack with a proven web calendar and address book in front of it. Confirm how calendar sharing, free/busy visibility and resource calendars behave in SOGo for your users. Plan for the mailcow update cadence and check the component versions in each release before rolling it out.

OX App Suite for large scale groupware

OX App Suite v8 is delivered as Helm charts on Kubernetes and needs MariaDB, Redis 7.4.x and a distributed file system for attachments and files. It fits service providers and large organizations that need multi-tenancy, scale and a commercial support path. The tradeoffs are operational weight, including Istio or ingress-nginx, and licensing: some modules may carry separate fees set in the license agreement. Confirm the LTS version you will run and its support end date before you sign.

Client matrix narrows the choice

Before you compare platforms, list the desktop and mobile clients your users run and confirm which of them connect natively to CalDAV and CardDAV. Some clients need extra configuration, add-ons or a vendor-specific sync method, and that changes the support load. Test shared calendars, delegated access, free/busy lookups and resource booking with the exact client versions in your fleet. Where a client cannot connect natively, the platform choice becomes a workaround decision, not a standards decision.

How free/busy lookup and resource booking work across the platforms

Free/busy visibility and room or equipment booking are not features of the calendar client alone. They depend on three layers working together: the groupware server that stores each calendar and answers scheduling requests, the directory that maps people and rooms to identities, and the client that asks for availability and writes invitations. A gap in any one layer usually shows up as a calendar that looks free when it is busy, or a room that accepts two meetings at the same time. Before choosing a platform, confirm which layer handles each of these jobs in the product you are evaluating, because the answer differs between Stalwart, mailcow with SOGo, and OX App Suite.

Test free/busy and resource booking as a matrix, not as a single demo. Create test users in two or more domains, a shared room resource and an equipment resource, and recurring meetings with exceptions. Then book from each client you intend to support, including the native desktop and mobile clients, and check that another user sees the correct free or busy blocks, that a declined or cancelled invitation releases the room, and that a double booking is refused or flagged. Record which client produces which result, since scheduling behavior can vary by client even when the server is the same. Ask each vendor or partner to document how resources are defined and who can approve bookings.

Plan for the cases that break in production: external attendees whose free/busy data is not shared across the boundary, delegated calendars in which an assistant books on behalf of an executive, and resource accounts whose booking rules are set in one interface but not enforced in another. Confirm how the directory feeds calendar addresses and resource records, how lookups behave when the directory is unavailable, and how changes to room capacity or permissions are audited. Treat these checks as a written acceptance test in the scope of work, and confirm the exact behavior of your chosen platform and clients against its current documentation.

How a shared calendar migration runs in phases

The sequence moves calendars and contacts from a hosted provider to standards-based groupware in controlled stages, so each phase produces evidence that the next one depends on. Clients, identity, free/busy and data integrity are proven before any user is switched over.

Inventory clients and calendar sources
DeployOpen works with your IT team to list every calendar and address book source in use, including desktop clients, mobile devices, shared and resource calendars, delegated access, and any third-party apps that read or write events. Each entry is recorded with its client version, sync method and owner. The output is a signed-off client matrix that states which clients connect natively over CalDAV and CardDAV, which need configuration profiles, and which will need a replacement or an exception. Confirm each client's current support with its vendor before sign-off.
Select platform and design identity
Based on the client matrix, the team confirms the target groupware, such as Stalwart with CalDAV and CardDAV, mailcow with SOGo, or OX App Suite, and records the reasons in a short decision note. The identity design covers how users authenticate, how shared and resource calendars are owned, and how access is granted and revoked. The output is an approved architecture note and an identity design that your directory team has reviewed. Licensing terms and any module fees should be confirmed in writing before the design is final.
Run a pilot with real clients and free/busy tests
A small pilot group uses the new platform with the devices and clients from the signed-off matrix, including their normal workflows. Test cases cover event creation and invitations from external organizers, recurring events with exceptions, shared calendar permissions, free/busy lookups across users, and resource booking for rooms and equipment. Each test records expected and actual results. The output is a test report with defects logged, fixed and retested, and a go or no-go recommendation for the migration phase.
Migrate calendars and contacts with verification
Calendars and contacts are copied from the source in batches using the import method chosen for each source format. After each batch, counts of events, contacts, recurrence rules, attachments and shared calendar grants are compared with the source, and a sample of records is checked by hand. Discrepancies are investigated before the next batch. The output is a migration report per batch and a reconciliation summary that your team can keep as evidence of completeness.
Cut over with a documented fallback
Users are moved in groups, with DNS, client configuration profiles and directory settings changed for each group in a planned window. Before each group moves, the rollback steps are rehearsed, and the source remains read-only for a defined period so that any group can return. Support staff watch sync errors and free/busy lookups during the first working days. The output is a cutover log for each group and a confirmed list of open issues. Agree the length of the read-only period and the support hours in the written scope.
Hand over operations with runbooks
Once all groups are live and the source tenant is retired or frozen, the platform is handed to your operations team. Deliverables include runbooks for account provisioning, shared calendar administration, backup and restore tests for calendar data, client troubleshooting, upgrades and monitoring of CalDAV and CardDAV endpoints. Your team walks through each runbook with DeployOpen and records the sessions. The output is a signed handover pack and an agreed support model, whether that is internal, a retainer or a mix.

What auditors and regulators ask for from calendar and contact systems

This table lists the evidence items an assessor usually requests for shared calendars and contacts, what each one shows, and which component produces it. Use it to plan logging, access reviews and retention before an assessment starts. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.

Evidence item	What it shows	Which component produces it
Access logs for shared calendars	Who opened, changed or shared a calendar or address book, and when, including delegated and public access	CalDAV and CardDAV service logs on Stalwart or SOGo, reverse proxy logs, and the directory or identity provider's sign-in records
Identity and role configuration	Which accounts and groups can manage calendars, share folders, or read resource calendars, and how those roles were assigned	Directory connector configuration (LDAP or OIDC), mail server admin roles, and an exported access review record
Backup and restore test records	That calendar and contact data can be recovered, with dates, scope, the person who ran the test and the outcome	Backup job reports and restore test runs on the groupware data store, including the database and file storage used for attachments
Configuration baselines	The approved settings for protocols, TLS versions, sharing defaults and client access, and any drift from them	Version-controlled configuration files for the mail and groupware stack, plus periodic configuration export reports
Retention records for calendar entries	Where regulation applies, how long calendar items and invitations are kept and whether deletion follows the approved schedule	Archiving or journaling design documents and retention policy settings; calendar retention usually depends on the archive, not on the mailbox server
Change and patch history	Who changed the platform, which versions run in production, and when security updates were applied	Change tickets, release records from the platform vendor, and deployment logs from the implementation team
Free/busy and resource booking settings	Which users and systems can see availability data and how resource calendars are approved	Groupware sharing policy, resource calendar settings, and records from the resource approval workflow

How much effort and cost does self-hosted calendar and contact work involve?

What drives the cost of self-hosted calendars and contacts?

Scope, user count, identity integration, migration volume and the licensing model drive most of the cost. Scope sets how many platforms, clients and integrations are in play. User count and mailbox size affect server sizing and storage. Identity integration with your directory adds configuration and testing work. Migration volume determines how much calendar and contact data must be moved and verified. For OX App Suite, the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so ask for that split in writing. Stalwart is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs, and mailcow is GPL-3.0, so the license decision belongs in the quote from the start.

How long does a self-hosted calendar and contact rollout take?

Ask for a written plan with milestones rather than an assumed duration, because the timeline depends on the platform, the number of clients, identity integration and how much history must migrate. A credible plan separates discovery, a pilot with a small user group, client testing across desktop and mobile devices, migration waves and a stabilization period. Each phase should name its exit criteria, such as verified free/busy lookups across domains and confirmed contact sync on the devices your users actually carry. Any date you are given should trace back to that written scope and the agreed deliverables, since most engagements are fixed-scope and agreed in writing before work starts.

What does our internal team need to provide for the project?

Your team needs to supply decisions and access more than hands-on administration. The main inputs are the domain and DNS control, a directory or identity source for user accounts, a list of clients and devices in use, the calendar and contact data sources to migrate, and named owners who approve resource calendars, sharing rules and retention settings. Someone must also own certificate issuance and the internal naming scheme. Before work starts, confirm which of these you cannot provide, because gaps in DNS, identity or device inventory are the most common reasons a schedule slips.

Can our own IT team run self-hosted calendars and contacts without a partner?

Yes, many teams run CalDAV and CardDAV services with in-house staff, provided they have the skills for mail or groupware administration, certificate management, DNS and backup. The questions to answer honestly are who handles client support, who applies security updates, who tests restores and who covers the on-call rota. Standards-based stacks reduce lock-in, but they still need operators who understand free/busy behavior, resource booking and client quirks. If those skills are thin, a partner can take over planning, implementation, hardening and documentation under a fixed-scope agreement, with ongoing support available as a retainer.

How are upgrades and recurring operations handled for OX App Suite?

Plan for recurring operations from day one, because upgrades are a standing cost rather than a one-off event. Open-Xchange states that a standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. According to the support commitment, v8.35 was the first v8 LTS and is now discontinued, and v8.47 is the current LTS. Those windows should drive your upgrade calendar, so ask any partner which release line they will maintain, how they test upgrades in staging and what happens when a release leaves support.

What recurring costs should we expect after go-live?

Recurring costs fall into four groups: infrastructure, licensing, operations labor and support. Infrastructure includes compute, storage, backups and, for OX App Suite, the Kubernetes, MariaDB, Redis and distributed file system layers that its requirements describe. Licensing may repeat annually depending on the agreement. Operations labor covers patching, monitoring, certificate renewal, restore testing and user administration. Support covers client issues and escalations. Ask for each of these as separate line items in a quote so you can see which parts scale with user count and which stay fixed.

What should a quote for calendar and contact work include?

A usable quote lists the scope in writing, the deliverables, the assumptions and the exclusions. It should name the platform and version line, the number of users and clients, the identity integration approach, the migration method and its verification steps, and the documentation handed over. Ask which costs are one-time and which recur, which licenses are included or billed separately, and what is excluded, such as end-user training or custom client development. DeployOpen does not publish a price list, so a quote follows from the written scope, and the scope is what you should compare across bidders.

What to ask an implementation partner about calendars and contacts

Start with the client matrix. Ask which desktop and mobile clients the partner tests against CalDAV and CardDAV on your chosen platform, and which versions of each. A good answer names specific clients and versions, shows the test results for create, edit, recurring events and contact sync, and states which clients need a vendor-specific setting or are not supported natively. Ask how they will test free/busy lookups and resource booking end to end: a meeting booked from one client should show the correct availability in another, a room should refuse a double booking, and a shared calendar should respect its permissions. Ask for the test script or a written list of cases so you can rerun it after an upgrade.

Ask how calendar and contact data will be migrated and reconciled. The partner should explain how they export from the current hosted service, how they handle recurring series, time zones, attachments and shared calendars that are subscribed rather than owned, and how they count and compare items after import. A good answer includes a reconciliation report per mailbox and a plan for changes made during cutover. Ask how access to shared calendars is logged, which events are captured (grants, revocations, changes to shared or resource calendars) and where those logs are stored and for how long. Confirm the retention period with your compliance lead, because the partner should not set it for you.

Ask how backups are restored and tested, not only how they are taken. Request a restore of a single user's calendar and contacts to a separate location, with the time it took and the checks used to confirm the result. For the release question, ask how the partner tracks the upstream support window for your edition. For OX App Suite, ask which LTS line they would deploy and when they would plan the move to the next one, and how they test a release in a staging environment before production. For Stalwart or mailcow, ask how they handle major version changes and rollback. Ask for the upgrade and rollback runbook in writing before work starts.

How DeployOpen scopes and delivers a self-hosted calendar and contact platform

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source groupware inside your own cloud accounts, data centers or air-gapped networks. For shared calendars and contacts, we start from which CalDAV and CardDAV clients your people use, then build and hand over a platform sized to that scope.

How we scope

Engagements are fixed-scope, with the platform choice, user count, domains and client list agreed in writing before work starts.
We record which calendar and contact clients must connect, including desktop, mobile and any clients that need manual account setup.
We define free/busy visibility rules, shared calendar ownership and resource booking mailboxes as explicit deliverables in the written scope.

How we build

We deploy Stalwart, mailcow with SOGo, or OX App Suite in the environment you specify, with CalDAV and CardDAV endpoints tested per client.
We configure directory integration, sharing permissions and resource calendars, then test free/busy lookups across internal and delegated users.
We run security testing against the calendar and contact endpoints and document the findings and remediation for your review.

How we hand over

You receive configuration records, client setup guides, runbooks for user provisioning and backup restore steps for calendar and contact data.
We document the controls that support your assessment evidence, so your auditors can review access logging and encryption settings directly.
Knowledge transfer sessions cover administration, upgrades and troubleshooting for the calendar and contact services your team will operate.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
Retainers can cover client compatibility checks when desktop or mobile clients release updates that change CalDAV or CardDAV behavior.
Before any upgrade, we confirm the release lifecycle and plan the change window with your team, using the vendor's published support terms.

Self-hosted shared calendars and contacts with CalDAV and CardDAV