Host CcasServer on Render (deferred until post-CLI-v0 + #51)

[Sootopolis]

Placeholder for hosting CcasServer on Render so the scheduler runs continuously and remote job submission works from any device. Deferred — not near-term per roadmap discussion 2026-05-27.

Gating prereqs

Must land before any Render work begins:

• CLI v0 epic (Epic: CLI v0 (Phase 1) #40) ships — server route surface stabilises under CLI consumption first; hosting an unstable API = rework.
• Bump SCHEDULER_POLL_MINUTES before CcasServer runs continuously on Neon #59 bump SCHEDULER_POLL_MINUTES to 15+ — current 5min poll burns through Neon free-tier 192 active-hr/mo budget.
• app_setting table for DB-owned app settings (start with cache_retention_days) #57 app_setting DB table — single source of truth across consumers (CLI + hosted server) for cache_retention_days, scheduler interval, etc.
• Weekly off-Neon pg_dump backup (24h PITR is not enough) #58 weekly off-Neon pg_dump — Neon free PITR is 24h only; mandatory before continuous remote writes.
• Target audience: technical users only, or non-technical chess admins too? #51 target audience resolved — drives whole shape:
  • Technical-only → free/Starter Render web service, no UI, scheduler convenience.
  • Non-technical admins too → mandatory infra: auth + frontend + paid tier + domain. Separate epic.

Open decisions when unblocked

• Neon compute budget: continuous Render box = always-warm endpoint. Free tier exhausts in ~8 days. Options: (a) auto-suspend gaps between scheduler ticks; (b) Neon Launch ($19/mo).
• Render tier: free (sleeps after 15min idle, ~30s cold start — fine for cron-triggered jobs, not interactive) vs Starter ($7/mo always-on 512MB).
• Single-writer invariant: hosted JobScheduler + local ccas serve against same DB would race on due-job claim. Either document "don't run both" in ccas serve lifecycle (serve, serve --detach, stop) #48 lifecycle or add DB-level scheduler lock.
• Secrets: DATABASE_URL + CCAS_CONTACT_EMAIL into Render env vars. No .env in image.
• Log retention: file-tail logs (File-tail logs endpoint GET /api/jobs/{id}/logs #47) assumes local disk; Render disks ephemeral. Pipe to stdout + external sink, or accept redeploy loss.
• Health checks: existing HealthRoutes should suffice as Render health probe target.

Out of scope for this issue

Actual deploy work, auth/UI design, tier purchase. This issue only tracks "Render is on the roadmap, here's the parking lot of decisions for when it's time."

[Sootopolis]

Note: Chess.com OAuth app is gated on the host/domain decision here

Deferred applying for a Chess.com OAuth client (2026-06-01). Capturing the gotchas so we get the application right in one shot when host work begins.

Why it's blocked on this issue: the application form requires exact redirect URI(s) up front, and the prod redirect URI can't be committed until the host/domain is decided (the #51 / Render-tier branch above drives the prod hostname).

The expensive constraint — Chess.com OAuth is staff-provisioned, not self-serve:

• Apply via a Google Form → manual staff review → credentials issued by hand. No developer dashboard.
• So editing redirect URIs after issue = another manual staff round-trip, not a form edit (unlike Google/GitHub/Lichess). Approval turnaround is slow and reportedly unreliable (mid-2026 forum threads still asking if anyone got access).
• ⇒ Apply once, with the final redirect URIs already correct. Guessing a placeholder prod URI now just buys a second slow round-trip later.

Prereqs before applying:

• Callback route exists in CcasServer — none today (routes are Health/Job/Schedule/Blacklist/RecruitmentCriteria; no auth at all). Lock the path (e.g. /auth/callback) before submitting; the form value must match the wired route exactly.
• Prod hostname committed (depends on the Render-tier / domain decision above).

Redirect URIs to submit (one per line, exact match, no wildcards):

http://localhost:8080/auth/callback        # dev — localhost acceptance UNVERIFIED for Chess.com; confirm before relying on it
https://<committed-prod-host>/auth/callback # prod

Watch-outs:

• localhost may be rejected — no public doc confirms it's allowed. Verify, else dev flow needs a workaround (e.g. a tunnel/registered dev host).
• Server port is 8080 (SERVER_PORT override) — reflect actual prod port/path if the deploy fronts it differently (reverse proxy, path prefix).

Refs: OAuth application guide (forum) · OAuth/Login announcement

[Sootopolis]

Capturing a finding from the CLI work that reframes the value of OAuth for the hosted server.

Chess.com's "Getting started with OAuth 2.0 Server" doc says attaching an access token to the public /pub API bypasses the rate limit:

Using obtained access tokens for this API only makes sense for bypassing the rate limit. So for unlimited use of Public API, always send the access token through the authorization header.

So OAuth here isn't only login / club-init — for a hosted server it's rate-limit relief. The CCAS-wide background jobs (scheduler-driven membership/history/recruit/stats/ref-resolution) only read /pub, so we can run all of them under a single owner token, purely for capacity:

• one-time authorize the server as the owner account (authcode/redirect) → short-lived access token + long-lived refresh token
• store the refresh token, auto-refresh, attach Authorization: Bearer to every /pub request → bypass

This is decoupled from per-user / per-club login (members logging in) — that stays a separate, later concern. For the bypass we don't need club scopes, just an authenticated request.

Prereqs (mostly already in the note above): the staff-provisioned OAuth app, a callback route, secure refresh-token storage (secret manager, not DB plaintext), and a refresh lifecycle. The ChessComClient change itself is small — a token provider plus the Authorization header.

Side benefit: a token'd prod server isn't in the anonymous per-IP bucket, so it won't compete with a dev app run from my laptop — that largely removes the dev-vs-prod rate contention without any cross-process coordination.

Caveat: "unlimited" is their word — keep the adaptive throttle as a safety net and assume some fair-use backstop still applies.