Rebase FastAPI Cloud onto main; update Vercel for Dockerfile support - #16
Conversation
FastAPI Labs' hosting platform (by the FastAPI creator's team), added to all six tables with footnoted citations and a reference section: - Public beta with open signup since June 22, 2026 (announced May 5, 2025 alongside a $4.2M Sequoia-led seed) - Hosts FastAPI apps exclusively; Python 3.10+ defaulting to latest stable; pyproject/uv or requirements.txt; `fastapi deploy` CLI, GitHub auto-deploy, local dev via `fastapi dev` - Free Hobby plan (3 apps, 0.1 shared vCPU / 512 MB, 1 custom domain); Pro $20/seat/mo (25 apps, higher unpublished limits); compute usage is not billed yet while usage-based billing is built - Caveats stated in a note under DevEx: scale-to-zero is officially "coming next" (not yet shipped), runtime limits largely unpublished, single unspecified region (EU on roadmap), no first-party data products (Neon/Supabase/Redis Cloud integrations instead) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X4AMvv1KYYvnmpkDZeW7Ra
Vercel shipped Dockerfile support on June 30, 2026: a Dockerfile.vercel (or Containerfile.vercel) at the project root is detected at deploy time, built, pushed to the new Vercel Container Registry, and served on Fluid compute with Active CPU billing. Vercel stays in Excluded, for the same reason Clever Cloud and Netlify do: Vercel builds the image during deploy and there is no documented path to point a service at a pre-built Docker Hub/GHCR image, which is this doc's inclusion bar. The entry is refreshed rather than promoted to a table row, and the stale "no long-running processes" claim is replaced with the actual constraints: - VCR is a project-scoped OCI registry at vcr.vercel.com speaking Docker Registry v2 (docker push/pull/tag, OIDC or token auth), with a vercel vcr CLI - containers are stateless and request-scoped; server must listen on $PORT (default 80) - idle instances scale down after 5 min in production / 30 s in preview, with a 30 s SIGTERM grace period - invocations capped at 300 s by default, 800 s on Pro/Enterprise, 1,800 s beta - WebSockets are native (Fluid compute required) but pinned to one invocation and closed at the duration cap - Secure Compute and Static IPs are not yet supported Sources accessed July 25, 2026; noted as such next to the doc's July 3 verification date, since only the Vercel data was re-checked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011ZoCsLVMprY2pKPDn7AS9s
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
🚨 Contributor flagged. Click here for more info: Superagent Dashboard |
Summary
Rebased this branch onto
mainand updated the Vercel entry inone-click-image-deployment.mdfor Vercel's June 30, 2026 Dockerfile launch.Base was retargeted from
claude/add-fastapi-cloud-noiap4tomain— that stale base was the sole cause of the merge conflicts, since it still carries the pre-squash history of #13. Againstmainthis branch is a clean fast-forward.The rebase
The branch previously carried three commits, two of which were already in
main, squash-merged as0d8479c(#13). Verified rather than assumed: the tree at28542d1is byte-identical to the tree at0d8479c.A plain rebase would have replayed already-merged work and conflicted, so only the genuinely new commit was replayed (
git rebase --onto main 28542d1). What remains:Add FastAPI Cloud— unchanged, now sitting on currentmainUpdate Vercel entry for Dockerfile support and the Container Registry— newThis supersedes #14, whose branch is still on the pre-squash base.
Vercel changes
Vercel now builds a
Dockerfile.vercelat deploy time, pushes it to the new Vercel Container Registry, and serves it on Fluid compute with Active CPU billing.It stays in Excluded, for the same reason Clever Cloud and Netlify do: Vercel builds the image, and there is no documented way to point a service at a pre-built Docker Hub/GHCR image — which is this doc's inclusion bar. Promoting it to a table row would contradict the doc's stated scope and leave most cells unverifiable. Heroku and Cloudflare are included despite being own-registry-only because they can take a pre-built image without a build step.
The entry was refreshed instead, replacing the stale "no long-running processes" claim with the real constraints:
vcr.vercel.comspeaking Docker Registry v2, with avercel vcrCLI$PORT(default 80)Validation
typospasses on the repo (exit 0). markdownlint introduces no new warnings — the four reported (2MD034inone-click-image-deployment.md, 2MD053inREADME.md) all pre-exist onmain.Sourcing caveat
vercel.comis blocked by this session's egress policy, so its pages could not be fetched directly. The blog post and container-images docs were supplied as primary sources; the remaining details came from search summaries of Vercel's own pages. One thing deliberately not asserted: whether a pre-built image can bedocker pushed to VCR and served without a Dockerfile build. The VCR changelog hints at it, no official doc confirms it, and if that path exists it would change the exclusion call — worth re-checking when vercel.com is reachable.🤖 Generated with Claude Code
https://claude.ai/code/session_011ZoCsLVMprY2pKPDn7AS9s