Skip to content

feat(templates): add Cal.diy self-hosted scheduling starter - #928

Open
dviejokfs wants to merge 5 commits into
gotempsh:mainfrom
dviejokfs:feat/cal-diy-scheduling-template
Open

feat(templates): add Cal.diy self-hosted scheduling starter#928
dviejokfs wants to merge 5 commits into
gotempsh:mainfrom
dviejokfs:feat/cal-diy-scheduling-template

Conversation

@dviejokfs

Copy link
Copy Markdown
Contributor

Summary

  • Adds crates/temps-core/templates/starters/cal-diy.yaml, a project-creation starter for Cal.diy (Cal.com's MIT-licensed, self-hosted community edition of Calendly-style scheduling)
  • Builds from the upstream repo via the dockerfile preset (it ships a root Dockerfile), requests a linked postgres service, and declares the real required env vars sourced from cal.diy's own .env.example (DATABASE_URL, DATABASE_DIRECT_URL, NEXTAUTH_SECRET, CALENDSO_ENCRYPTION_KEY, etc.), marking credential-shaped values secret: true
  • Placed under templates/starters/ (source-build) rather than templates/services/ (the pinned-image catalog): the services/ validator requires an immutable sha256-pinned image, and there's no verifiably published runnable image for cal.diy to pin (its GHCR listing only shows a build-cache package)

Why

Lets operators self-host scheduling/booking infrastructure (e.g. for a "book a setup call" onboarding step) on Temps instead of a SaaS like Calendly, consistent with the no-vendor-lock-in self-hosting story.

Test plan

  • cargo test --lib -p temps-core templates:: — 34 passed (bundled catalog parses and validates)
  • cargo check --lib -p temps-core — clean
  • python3 scripts/source_attribution.py check — passed
  • Pre-commit hooks (yaml check, conventional commit, DCO sign-off) passed
  • Not yet exercised end-to-end (one-click deploy from the new starter) — reviewer/maintainer call on whether that's required before merge

Cal.diy is Cal.com's MIT-licensed, self-hosted community edition.
Adds it as a project-creation starter (git+Dockerfile build, Postgres
service dependency) so operators can self-host booking/scheduling
infrastructure on Temps instead of a SaaS like Calendly.

Upstream recommends personal/non-production use only, so this ships
as a starter template rather than a version-pinned "service" catalog
entry.

Signed-off-by: David Viejo <dviejo@kfs.es>
@greptile-apps

greptile-apps Bot commented Sep 7, 2026

Copy link
Copy Markdown

Greptile Summary

The PR replaces the Cal.diy source-build starter with an immutable service template and adds architecture-specific image selection.

  • Adds separately pinned amd64 and arm64 image digests.
  • Selects the image variant using the console host architecture when templates are returned or created.
  • Extends template validation and API responses with image_arm64.

Confidence Score: 5/5

The PR appears safe to merge because the previously reported mutable-source deployment path has been replaced by immutable image deployment.

No blocking failure remains.

Important Files Changed

Filename Overview
crates/temps-core/src/templates.rs Adds the optional architecture-specific image field and enforces immutable digests for service templates.
crates/temps-core/templates/services/cal-diy.yaml Defines Cal.diy as a service template using immutable amd64 and arm64 image digests.
crates/temps-projects/src/handlers/handlers.rs Resolves architecture-specific images before serving or creating projects and adds focused selection tests.
crates/temps-projects/src/handlers/templates.rs Exposes the optional arm64 image variant in template API responses.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Load service template] --> B{Console host architecture}
    B -->|aarch64| C[Select image_arm64 digest]
    B -->|other| D[Select default image digest]
    C --> E[Return resolved template]
    D --> E
    E --> F[Create DockerImage project]
    F --> G[Persist immutable image runtime]
    G --> H[Deploy pinned image without source build]
Loading

Reviews (4): Last reviewed commit: "fix(templates): pin Cal.diy to calcom/ca..." | Re-trigger Greptile

Comment thread crates/temps-core/templates/starters/cal-diy.yaml Outdated
Moves the Cal.diy template from templates/starters/ to
templates/services/ so it appears in the "Services" gallery
alongside Keycloak and Browserless, matching the pattern of a
curated app backed by a Temps-managed PostgreSQL database.

This requires a version-pinned, sha256-digest-locked image, which
the previous starter entry avoided for lack of a verified one.
docker.io/calendso/calendso publishes real tagged releases (cal.diy's
image is still shipped under its pre-rename name) — pinned to v6.2.0,
the latest release. Postgres connectivity is wired via
managed_service_bindings (DATABASE_URL/DATABASE_DIRECT_URL <-
POSTGRES_URL) instead of manual copy-paste env vars, since bindings
are only resolved for service-kind templates.

Signed-off-by: David Viejo <dviejo@kfs.es>
…emplates

Some upstream projects don't publish a real multi-arch manifest under
one tag/digest -- amd64 and arm64 ship as separate, separately-versioned
images instead. cal-diy's v6.2.0 image (docker.io/calendso/calendso) is
one of these: it 404s pulling on arm64 hosts because the pinned digest
only ever resolves to the amd64 variant.

Adds an optional `image_arm64` field to service templates (same
pinned-digest validation as `image`), exposes it through the API, and
resolves between the two at project-creation time based on the host
architecture. This assumes a homogeneous fleet since the deploy
target's architecture isn't known until scheduling, after project
creation -- true per-node arch-aware resolution would need to move
into the deploy path, which is out of scope here.

cal-diy.yaml now pins both variants: amd64 -> v6.2.0, arm64 -> v6.2.0-arm.

Signed-off-by: David Viejo <dviejo@kfs.es>
… sees it

The create-project form always submits template.image as an explicit
runtime override, even when the user never edited it -- so the
arch-selection fallback added in resolve_image_template_runtime never
actually ran for a real UI-driven deploy: by the time the request
arrives, an untouched default is indistinguishable from a deliberate
override.

Resolves image vs image_arm64 by host architecture in the two
template-serving endpoints (list_project_templates,
get_project_template) instead, so the value the form is pre-filled
with -- and therefore submits -- is already correct.

Signed-off-by: David Viejo <dviejo@kfs.es>
…endso

Same release build, same digests (verified: identical sha256 for both
v6.2.0 and v6.2.0-arm) -- calcom/cal.com is just a better-known alias
for the same push. calcom/cal.diy, the name matching the project's own
git repo, has no tags published to it as of this writing, so it can't
be used.

Signed-off-by: David Viejo <dviejo@kfs.es>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant