HivemindOS manual

Agent-Managed Bookings

Bookings lets an approved agent check availability, manage event types, and create, reschedule, or cancel appointments through the calendar path you choose. Changes that affect another person require a clear preview and confirmation.

Open Integrations to connect an existing Cal.com account. Advanced users can host Cal.diy on a fleet machine, while eligible managed accounts can use an always-on HivemindOS booking page.

Choose the path based on where you want the booking service to run:

Path Runs where Best for Authority
Connected Cal.com Cal.com’s hosted service Existing Cal.com accounts Cal.com account and API key
Local Cal.diy A user-selected HivemindOS fleet machine Personal, experimental, and user-owned self-hosting The user’s machine, Docker volumes, and API key
Managed Hivemind Bookings Official HivemindOS cloud infrastructure Always-on public booking pages for agent-run operations HivemindOS subscription and hosted booking services

Agents use the same booking capability regardless of provider, so a normal request such as “find three available times next week” does not require you to know an internal tool name. When more than one booking service is connected, choose the intended destination before approving a change.

Local Cal.diy

Open Apps & Services → Catalog → Cal.com / Cal.diy. The Cal.diy install option can target This Mac or another currently discovered, owner-authenticated HivemindOS fleet machine. Other app installers remain local-only.

The installer:

  • downloads the audited calcom/cal.diy source commit and verifies its archive SHA-256 before extraction
  • pins Node build images plus PostgreSQL and Redis runtime images by immutable digest
  • applies a versioned HivemindOS source patchset so the Alpine API image can compile native dependencies on arm64, then removes the temporary compiler toolchain
  • builds the memory-heavy web and API images sequentially at the documented memory floor
  • binds the web app to 127.0.0.1:3000 and API v2 to 127.0.0.1:3002
  • keeps PostgreSQL and Redis off host ports and preserves them in dedicated Docker volumes
  • generates service secrets into a mode-0600 env file under the HivemindOS service directory
  • disables Cal.com telemetry and unsupported hosted OAuth/organization switches in this personal stack
  • exposes backup, start, stop, publish, unpublish, configuration, and status actions through the same service card

The initial source build needs Docker Compose, a running Docker daemon, roughly 8 GB of free memory, and about 40 GB of temporary Docker storage. The measured final images are also large (about 7.3 GB for web and 9.6 GB for API in the verified arm64 build), so managed bookings is the lighter default when user-owned infrastructure is not a requirement. The source, patchset, and image versions do not float automatically; upgrading requires a new source audit and pin update.

Transactional email is disabled by default. Configure SMTP before relying on local confirmation or calendar-invitation delivery. The upstream Cal.diy success page may still show generic “email sent” copy when SMTP is absent; HivemindOS status therefore reports email readiness separately.

Cal.diy upstream describes this edition as intended for personal, non-production use. HivemindOS therefore presents it as a user-owned local option, not as the official business-hosting tier.

Make A Local Page Public

Local installation stays loopback-only. Publish requires the exact CONFIRM_CAL_DIY_PUBLISH confirmation and a signed-in Tailscale CLI with MagicDNS and HTTPS enabled. HivemindOS starts a persistent background Tailscale Funnel for port 3000, switches Cal.diy to its https://<machine>.<tailnet>.ts.net URL, and recreates the web/API services. If recreation fails, the installer turns the Funnel off and restores loopback configuration.

Unpublish turns off HTTPS Funnel port 443 and returns the service to loopback. Publishing makes the booking page internet-accessible; it does not publish the PostgreSQL or Redis ports.

For a published machine, connect the Cal.com integration with:

  • CALCOM_API_BASE_URL=https://<machine>.<tailnet>.ts.net/api/v2
  • an API key created inside that Cal.diy account as CALCOM_API_KEY

For an agent running on the host itself, http://127.0.0.1:3002/v2 is also available. HivemindOS stores the API key through the normal shared-env connection flow and never places it in the Docker Compose file.

Back Up Or Remove It

Back up runs pg_dump inside the private database container and writes a mode-0600 compressed backup under the protected Cal.diy service directory. Copy a wanted backup somewhere else before uninstalling HivemindOS.

The HivemindOS uninstaller has a separate, default-No prompt for deleting Cal.diy. Accepting it turns off the Funnel, stops the Compose project, deletes its PostgreSQL and Redis volumes, and removes source, configuration, and backups. That deletion cannot be recovered unless a backup was copied elsewhere.

Managed Hivemind Bookings

Managed Hivemind Bookings is the official always-on path. The hosted worker owns public profiles, weekly availability, event types, conflict checks, booking records, iCalendar downloads, public rate limits, idempotency claims, and optional transactional email. A separate paid authority verifies the encrypted hosted-credit account against active HivemindOS subscription rows; request bodies cannot choose a tier, quota, entitlement, or price.

The implemented subscription policy includes managed bookings at no additional line-item price for active tiers:

Tier Public profiles Event types Bookings created per month
Plus 1 10 1,000
Pro 1 50 5,000
Max 1 250 25,000

There is no client-controlled standalone price or free managed allowance. Local Cal.diy remains the free self-hosted path. Managed Hivemind Bookings is live at book.hivemindos.app, backed by the private bookings Worker, D1 database, internal subscription authority, service bindings, and public domain. Transactional email is not currently configured, so successful pages provide an .ics calendar download and do not claim that email was sent. The downloadable app still cannot redirect or redefine this official hosted authority with local flags.

Public booking pages use rate-limited, tenant-scoped endpoints and random booking UIDs. Owner actions require the encrypted hosted-credit token. The hosted worker refreshes entitlement state daily and expires public access when the authority no longer confirms an active included subscription.

Agent Safety And Retry Behavior

Reads do not need a mutation confirmation. Every mutation needs a stable 8–200 character idempotency key plus its exact action-specific confirmation:

  • create: CONFIRM_BOOKING_CREATE
  • reschedule: CONFIRM_BOOKING_RESCHEDULE
  • cancel: CONFIRM_BOOKING_CANCEL
  • configure profile or event type: CONFIRM_BOOKING_CONFIGURATION

Cal.com/Cal.diy mutations use a protected local idempotency ledger namespaced to the connected API account. Managed mutations use an atomic hosted idempotency claim. Repeating the same key and body returns the prior response; reusing the key for different input fails with a conflict.

Agents should read slots immediately before creating or rescheduling, present the attendee, event type, time, time zone, and destination provider for review, then use the corresponding confirmation. Provider-side conflict checks remain authoritative even after a successful availability read.

Zero Human Companies

A company agent may manage bookings only when all of these are true:

  • the request includes the company ID, active Work Board task ID, assigned agent ID, and stable idempotency key
  • the task belongs to that company and is currently working
  • the caller is the task’s assigned agent and a member of the company
  • the company’s configured integration request limits allow the read-provider-api or manage-bookings operation
  • the mutation has the exact booking confirmation

This makes bookings useful for agent-run sales, onboarding, customer research, support, demos, and service businesses without turning “zero human” into permissionless calendar mutation. The operator still owns public exposure, subscription funding, integration limits, and confirmations.

Current Verification Boundary

The repository test path exercises schema validation, DST-aware slot calculation, tenant isolation, atomic idempotency, subscription authorization, profile configuration, event-type creation, owner and public booking creation, duplicate replay, conflict rejection, rescheduling, cancellation, and iCalendar output through the real Worker entry point backed by SQLite. Local installer tests verify pinning, loopback exposure, private data services, authenticated fleet routing, uninstaller symmetry, action registration, and the live MCP confirmation gate.

The real local path was verified on this Mac in a disposable 8 GiB arm64 Colima profile on 2026-08-15. The test reproduced and fixed invalid generated Compose YAML, parallel-build OOM, missing Alpine native build tools, and quote loss in ALLOWED_HOSTNAMES. The supported CLI then installed all four services, produced 105 application tables, kept data services private, returned healthy web/API status, completed administrator setup and personal onboarding in a real browser, exposed default public event pages, and created a real anonymous booking with one booking and one attendee row. Backup, gzip integrity, mode 0600, stop/start recovery, and clean refusal to publish without Tailscale also passed. The anonymous local cancellation UI was attempted but not completed before disposable-volume cleanup, so local cancellation is not claimed by this live run; the adapter contract and managed production cancellation paths remain covered. Tailscale Funnel could not be exercised because the installed CLI shim points to a missing Tailscale app. Local SMTP was absent and the upstream page still displayed generic email-sent copy.

The official managed path is deployed: health, pricing, subscription authorization, public/owner mutations, custom-domain TLS, browser calendar-link wiring, and cleanup of a synthetic production lifecycle were verified on 2026-08-15. Transactional email remains the only optional hosted component not configured; managed confirmation pages provide .ics without claiming an email was sent.

Expanded image Scroll to pan · Esc to close
100%