OpenWikicalcom/cal.diy

Cron Jobs and App Store Seeder

Purpose and Scope

This page explains the two operational follow-up tasks that come after a source-based Cal.diy installation: scheduling background cron work and repopulating the app store after enabling integrations. The installation guide frames Cal.diy as a self-hosted scheduling system that can run on many operating systems, but it also makes clear that some features need platform-level cron setup when the instance is not managed by Cal.com. In practice, the web application can start successfully while still missing scheduled maintenance behavior or newly configured app entries, so operators should treat these steps as part of the deployment checklist rather than optional polish.

Sources: apps/docs/content/installation.mdx

The cron and seeding work belongs in the same operational area because both are environment-dependent. Cron execution depends on the host, such as Vercel or another platform that can call scheduled application routes. App-store seeding depends on credentials in environment files, especially the general environment file and the app-store-specific file mentioned during installation. A clean installation should therefore be reviewed in this order: clone and install dependencies, create the environment files, add secrets and integration credentials, build and start the application, configure scheduled route execution, and then seed or repopulate the app catalog when integrations are ready.

Sources: apps/docs/content/installation.mdx, apps/docs/content/apps/google.mdx

Relevant Source Files

  • apps/docs/content/installation.mdx — Primary installation guide covering requirements, environment files, production build commands, the cron-jobs section, and the app-store seeder flow.
  • apps/docs/content/_meta.ts — Documentation navigation metadata showing Installation, Database Migrations, Upgrading, Docker, Apps, and Deployments as the related self-hosting documentation spine.
  • apps/docs/content/apps/_meta.ts — Apps documentation navigation metadata listing supported integration pages, including Google, Microsoft, Zoom, Daily, HubSpot, Sendgrid, Stripe, Twilio, and Zoho.
  • apps/docs/content/apps/daily.mdx — Daily integration setup page showing how app credentials are added through environment variables before the integration can be used.
  • apps/docs/content/apps/google.mdx — Google Calendar setup page that explicitly instructs operators to repopulate the app store by running the database seed command after adding Google credentials.
  • apps/docs/content/apps/hubspot.mdx — HubSpot integration setup page showing the pattern of adding provider credentials and callback configuration before expecting integration behavior.

Where This Fits in Installation

The installation page first establishes prerequisites, including Node.js, yarn, Git, PostgreSQL, and Prisma-backed database maintenance. It then walks the operator through cloning the repository, installing dependencies, copying environment templates, generating a secret, filling the main environment file, and filling the app-store environment file. Cron jobs and app-store seeding should be understood as post-configuration tasks that make the deployed service complete. They are not a substitute for the production build, database upgrade, or environment setup; they rely on those earlier steps being correct.

Sources: apps/docs/content/installation.mdx

A useful way to separate responsibilities is to think of the production build as creating the runnable web application, cron setup as giving that application regular background triggers, and app-store seeding as synchronizing integration metadata with the credentials you decided to enable. The documentation navigation reinforces that these topics sit beside database migrations, upgrading, Docker, app setup, and deployments rather than inside a single command. Operators moving from a local proof of concept to a hosted instance should therefore keep a deployment runbook that names the build command, start command, database state, cron provider, and app seeding step together.

Sources: apps/docs/content/_meta.ts, apps/docs/content/installation.mdx

Cron Job Setup Flow

The installation guide states that a few features require cron job setup and that self-hosters probably need to configure cron jobs according to the hosting platform they use. This means Cal.diy does not hide scheduling behind a managed service for community self-hosting. Instead, the platform that hosts the web app must periodically call the appropriate application cron endpoint or otherwise run the documented scheduled task mechanism. On Vercel, the guide points readers toward Vercel cron documentation, but the same responsibility exists for other platforms: define a schedule, target the deployed application route, and monitor whether the job succeeds.

Sources: apps/docs/content/installation.mdx

For a practical deployment, create cron configuration only after the public application URL and authentication or network access model are stable. A cron route that points to a preview URL, an obsolete hostname, or an HTTP endpoint that later moves behind HTTPS can silently stop providing the background behavior the feature expects. The installation guide already warns Vercel preview deployments to leave certain public URL variables empty, which is a reminder that scheduled callbacks and redirect URLs are sensitive to deployment environment. Treat cron endpoints as part of the same URL review as OAuth callbacks, webhook endpoints, and reverse-proxy configuration.

Sources: apps/docs/content/installation.mdx, apps/docs/content/apps/google.mdx, apps/docs/content/apps/hubspot.mdx

App Store Seeder Flow

The app-store seeder step is most visible in the Google Calendar setup guide. After enabling Google Calendar API access, configuring consent, adding redirect URIs, downloading the OAuth client JSON, and copying credentials into both environment files, the docs instruct the operator to repopulate the app store by running the database seed command so the newly enabled Google Calendar integration appears in the Cal.diy app store. The important point is sequencing: credentials come first, then seeding. Running a seed before the relevant provider secrets exist can leave the catalog out of sync with the intended integration set.

Sources: apps/docs/content/apps/google.mdx, apps/docs/content/installation.mdx

The same mental model applies to other provider pages even when they do not repeat the seeding command. Daily asks operators to copy an API key into the environment and optionally set a scale-plan flag for recording-related functionality. HubSpot asks operators to create a developer app, copy client credentials, set an OAuth redirect URL, and choose required contact scopes. These pages show that Cal.diy app enablement is not only a UI action; it is a combination of external provider configuration, local secrets, callback URLs, and repository-provided app metadata that must be made available to the running instance.

Sources: apps/docs/content/apps/daily.mdx, apps/docs/content/apps/hubspot.mdx, apps/docs/content/apps/_meta.ts

Operator Checklist

Use this checklist after completing the normal installation steps and before handing the instance to end users. First, confirm that the main environment file contains the application secret and URL values expected for the chosen deployment. Second, confirm that the app-store environment file contains provider credentials for the integrations you plan to expose. Third, build and start the web application using the production build flow from the installation guide. Fourth, configure cron scheduling in the hosting platform so required background features receive regular triggers. Fifth, run the app-store seed or repopulation command after adding provider credentials, then verify the enabled apps are visible in the app store UI.

Sources: apps/docs/content/installation.mdx, apps/docs/content/apps/google.mdx

A simple example is enabling Google Calendar on a newly deployed instance. The operator should create Google OAuth credentials, add the two documented redirect URIs for the deployed Cal.diy URL, paste the downloaded JSON into the documented Google credentials key in both environment files, and set Google login behavior as needed. Only after those changes should the app store be repopulated. If the app does not appear, review the environment files and rerun the seeding step before debugging the UI. If OAuth fails after the app appears, review redirect URLs and public web app URL configuration first.

Sources: apps/docs/content/apps/google.mdx, apps/docs/content/installation.mdx

After this page, read the installation and production-build material to confirm the instance baseline, then read the app-specific integration guide for each provider you plan to enable. The apps navigation file is a compact index of available provider setup pages, while the top-level docs navigation shows adjacent operational topics such as database migrations, upgrading, Docker, and deployments. For production-like self-hosting, cron jobs, database migrations, URL configuration, and app-store seeding should be reviewed together because each one affects whether scheduled work, OAuth redirects, and integration discovery behave correctly after the application is already running.

Sources: apps/docs/content/_meta.ts, apps/docs/content/apps/_meta.ts

Ask a question...