Deploy to Cloudflare

Auf Cloudflare läuft Checky als Worker mit einer D1-Datenbank, zwei Durable Objects (Live-Updates pro Organisation und Rate Limiting), einem Cron Trigger jede Minute und der Web-App als statische Assets. Es ist derselbe Code wie beim gehosteten Dienst, nur im Ein-Organisations-Modus.

Wir empfehlen den Workers-Paid-Plan: Er gibt dem Passwort-Hashing bei der Anmeldung genug CPU-Zeit und hebt die D1-Limits pro Anfrage an (wichtig beim Import einer großen Organisation). Das Bundle passt aber auch in den Free-Plan.

Deploy mit einem Klick

1. Klick auf den Deploy-to-Cloudflare-Button in apps/worker/README.md im Repository (oder auf deiner Kontoseite nach dem Kauf).
2. Cloudflare forkt den Code in dein GitHub-Konto, legt die D1-Datenbank und die Durable Objects an und fragt nach zwei Secrets. Erzeug beide mit openssl rand -base64 48:
   • BETTER_AUTH_SECRET — signiert die Sitzungen.
   • APP_SECRET — signiert One-Tap-Links und Antwortadressen, verschlüsselt SSO-Secrets.
3. Workers Builds baut die Web-App, deployt den Worker und spielt die D1-Migrationen ein.

Nach dem ersten Deploy

1. Öffne https://checky.<deine-subdomain>.workers.dev und schließ die Einrichtung ab (Owner-Konto und Organisation) — oder wähle „Du ziehst von einem anderen Checky um?“, um einen Export einzuspielen.
2. Optional: Eigene Domain hinzufügen (Worker → Settings → Domains & Routes), dann die Variable BASE_URL auf die endgültige https://-URL setzen (Settings → Variables). Passkeys und OAuth-Callbacks hängen an diesem Host.
3. E-Mail einrichten (unten), optional CHECKY_LICENSE_KEY und Secrets für Google/Microsoft-Anmeldung (siehe Konfiguration).

E-Mail auf Cloudflare

Versand über das send_email-Binding des Workers:

1. Dashboard → deine Domain → Email → Email Routing: aktivieren (legt MX- und SPF-Einträge an).
2. Email Sending: die Absenderdomain bzw. -adresse aus EMAIL_FROM verifizieren (DKIM wird für dich eingetragen). Ohne Email Sending stellt das Binding nur an verifizierte Zieladressen zu — reicht für einen Test, nicht für dein Team.
3. EMAIL_TRANSPORT=cloudflare ist der Standard, wenn das Binding existiert (console loggt nur, zum Debuggen).

Antworten (Check-in per Reply auf die E-Mail beantworten):

1. Such dir eine Subdomain aus, z. B. reply.example.com, und aktiviere dafür Email Routing.
2. Routing rules → Catch-all (oder die Adresse reply+*) → Aktion Send to a Worker → dein Checky-Worker.
3. Setz EMAIL_REPLY_DOMAIN=reply.example.com. Zum Testen auf eine Erinnerung mit „ja“ antworten.

SMTP geht aus Workers heraus nicht. Wenn du SMTP brauchst, nimm Docker.

Updates

Synchronisiere deinen Fork mit dem neuen Release-Tag; Workers Builds deployt den nächsten Push automatisch (Worker plus D1-Migrationen). Aus einem lokalen Checkout:

git pull
pnpm install
pnpm --filter @checky/worker run deploy   # wrangler deploy + wrangler d1 migrations apply DB --remote

Code rollst du mit wrangler rollback zurück, Daten mit D1 Time Travel (wrangler d1 time-travel restore), siehe Backups und Updates.

Lokal ausprobieren (ohne Cloudflare-Konto)

cp apps/worker/.dev.vars.example apps/worker/.dev.vars   # Beispiel-Secrets ersetzen
pnpm --filter @checky/worker dev                         # http://localhost:8787, lokale D1
curl "http://localhost:8787/__scheduled?cron=*+*+*+*+*"  # einen Scheduler-Tick auslösen

Grenzen

• Der Deploy-Button braucht den Code in einem öffentlichen Repository (oder einer öffentlichen Kopie).
• Der Import einer sehr großen Organisation kann im Free-Plan die D1-Limits pro Anfrage sprengen — nimm dafür den Paid-Plan.