Cloudflare Workers vs Fly.io
Cloudflare Workers wins · 41–18 (25 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to Cloudflare WorkersA direct probe confirms Cloudflare serves a live llms.txt at developers.cloudflare.com/llms.txt returning HTTP 200 with structured agent-oriented documentation content, which is exactly the capability the story asks for. Missing for 10: no independent third-party confirmation of agents actually consuming/using this file successfully in the wild.
- [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
A direct probe confirms Fly.io serves a working llms.txt file at https://fly.io/llms.txt (HTTP 200) with structured documentation content, and Fly.io's docs also explicitly cater to agent-oriented workflows (e.g. Sprites, MCP server hosting). Missing for 10: no evidence of docs.md fallback or broader agent-oriented docs discoverability beyond the single llms.txt file, and no independent confirmation of agents actually consuming it successfully.
- [probe] “PROBE llms.txt: HTTP 200 at https://fly.io/llms.txt # Fly.io Documentation > Fly.io is a global public cloud for running full-stack and AI …”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to Cloudflare WorkersWrangler is a first-party CLI (cloudflare-gh-2, cloudflare-docs-11/20, cloudflare-probe-3) explicitly designed for scripted/headless deploy, dev, and management commands, and Cloudflare explicitly advertises fitting into existing CI workflows like Git and GitHub Actions (cloudflare-docs-17) with no proprietary tooling lock-in. Missing for 10: a dedicated GitHub Actions/CI recipe or worked example, and independent hands-on confirmation of CI automation specifically (community evidence is about DX/runtime limits, not CI usage).
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
Fly.io ships a scriptable CLI (flyctl) with single-line commands like `fly launch`, `fly machine run`, and `fly scale`, plus a full REST API for Machines that can provision and manage apps programmatically — both of which are usable headlessly in automation/CI pipelines. However, the evidence pack never explicitly documents CI integration (e.g., GitHub Actions, deploy tokens for automated pipelines) or shows a CI-specific workflow example. Missing for 10: explicit CI/CD integration docs (GitHub Actions, deploy tokens), independent hands-on confirmation of running flyctl in CI, and any automation-specific guide beyond general CLI/API docs.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
ai-native userConnect an agent via an official MCP server
weight 3 · round to Cloudflare WorkersCloudflare's official docs explicitly state you can build and deploy MCP servers on Cloudflare Workers, directly supporting agent connectivity via an official MCP server. Missing for 10: independent/hands-on corroboration of MCP server deployment, and more detail on the connection/auth workflow for agents.
- [claimed-docs] “You can build and deploy Model Context Protocol (MCP) servers on Cloudflare.”
Fly.io ships an official, first-party MCP server via `flyctl mcp` that lets agents connect to Fly's platform, but the docs explicitly flag it as experimental with no independent corroboration of stability or broader agent-integration support. Missing for 10: evidence of production-readiness, hands-on validation from third parties, and details on capabilities/tools exposed beyond the experimental flag.
- [claimed-docs] “[experimental] Start a flyctl MCP server”
- [claimed-docs] “Fly Machines are tightly isolated VMs that are perfect for running MCP servers.”
ai-native userUse an official CLI
weight 2 · round drawnWrangler is Cloudflare's official, well-documented CLI for creating, developing, deploying, and rolling back Workers, with dedicated docs, command references, and a GitHub repo, making it fully usable by AI-native/agentic tooling that shells out to CLIs. Missing for 10: explicit evidence of AI-agent-specific CLI ergonomics (e.g., machine-readable output modes, agent SDK wrappers) or independent hands-on confirmation of AI-native usage of Wrangler specifically.
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
Fly.io ships flyctl, a fully documented official CLI (fly launch, fly machine run, fly scale, fly doctor, etc.) that is AI-native aware — it even has an experimental built-in MCP server mode (flyctl mcp) and the whole platform markets itself around agent workflows (Sprites for Claude/Codex harnesses). missing for 10: no independent/hands-on corroboration of the CLI's AI-native workflows specifically, and the MCP server mode is explicitly labeled experimental rather than GA.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “Run diagnostics: `fly doctor` — checks WireGuard, IPs, and Docker.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “[experimental] Start a flyctl MCP server”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
ai-native userDrive the product through a documented public API
weight 3 · round to Cloudflare WorkersCloudflare publishes a documented, OpenAPI-spec'd public API (confirmed live at openapi.json), token-scoped API auth docs, and Wrangler CLI/SDK tooling that wraps the API for programmatic management of Workers — all fair for AI-native/agentic driving of the platform. Missing for 10: independent hands-on verification of API completeness/reliability from third parties beyond the probe confirmation.
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [claimed-docs] “Select which resources the token is authorized to access.”
- [claimed-docs] “granting Zone DNS Read access to a zone example.com will allow the token to read DNS records only for that specific zone”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
Fly.io documents a public REST API ("Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes" and "fast-launching VMs with a simple REST API"), giving AI-native users a genuine programmatic interface beyond the CLI. However, probes show no discoverable OpenAPI/swagger spec at standard locations, and the primary documented interface for automation is flyctl (CLI) with only an experimental MCP wrapper, not a fully machine-consumable API spec. missing for 10: a published OpenAPI/swagger schema, independent developer corroboration of API robustness, and clarity on API versioning/stability guarantees.
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “Fly Machines are tightly isolated VMs that are perfect for running MCP servers.”
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
- [claimed-docs] “[experimental] Start a flyctl MCP server”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to Fly.ioCloudflare's API token system lets users create scoped, least-privilege credentials (selecting specific resources/zones and permissions like 'Zone DNS Read' for a single zone), which an AI agent could use. However, this is a general platform credential feature not specifically tailored or documented for AI-agent use cases, and there's no evidence of agent-specific scoping guidance, short-lived/ephemeral agent tokens, or dedicated tooling for provisioning credentials to autonomous agents. Missing for 10: agent-specific credential issuance workflows, dynamic/ephemeral token minting for agents, and independent corroboration of this being used for AI-native agent scenarios.
- [claimed-docs] “Select which resources the token is authorized to access.”
- [claimed-docs] “granting Zone DNS Read access to a zone example.com will allow the token to read DNS records only for that specific zone”
Fly.io docs describe least-privilege credential scoping for agent sandboxes ('Sprites'): grant access by Sprite name, label, or single endpoint so an agent 'can post messages and never touch admin,' plus per-Sprite rotation/revocation without affecting others, and secrets encrypted in a vault. This directly matches issuing scoped, revocable credentials to an agent. Missing for 10: independent/hands-on corroboration of this scoping in practice, and no detail on underlying token/macaroon API mechanics.
- [claimed-docs] “Connect a service once for your whole org, and every Sprite can reach it. Nobody pastes a token.”
- [claimed-docs] “Grant access on purpose: by Sprite name, by label, or down to a single endpoint, so a Slack bot can post messages and never touch admin.”
- [claimed-docs] “Rotate once and every Sprite has the new credential. Cut off a single Sprite and the rest never notice.”
- [claimed-docs] “Secrets allow sensitive values, such as credentials, to be passed securely to your Fly App. The secret is encrypted and stored in a vault.”
ai-native userBuild against official SDKs
weight 2 · round to Cloudflare WorkersCloudflare ships official SDK/tooling (workers-sdk GitHub repo, Wrangler CLI) plus AI-specific building blocks (Workers AI, agents, MCP servers) and machine-readable docs (llms.txt, openapi.json) that support AI-native development. However, community feedback flags gaps in language coverage (no full Python/Node runtime) and vendor lock-in concerns around bindings, tempering full delivery. Missing for 10: mature first-class SDKs in multiple languages (e.g. Python), independent validation that AI-agent workloads run smoothly without CPU/time limits, and confirmation the MCP/agent tooling is broadly adopted rather than experimental.
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
- [claimed-docs] “You can build and deploy Model Context Protocol (MCP) servers on Cloudflare.”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [probe] “PROBE llms.txt: HTTP 200 at https://developers.cloudflare.com/llms.txt # Cloudflare Developer Documentation Explore guides and tutorials to…”
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
- [community] “I've used CF Pages for static sites with great results and am intrigued by all their open-source-LLM-as-a-service offerings. Main issue prev…”
Fly.ionone0/10Evidence shows Fly.io provides a CLI (flyctl), a REST API (Fly Machines API), and an experimental MCP server, but no official language SDKs (e.g., Python/JS/Go client libraries) are mentioned anywhere in the evidence pack; probes for openapi/SDK-related pages also failed (404s).
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnCloudflare Workersnone0/10While Cloudflare Workers is a general HTTP-handling serverless platform (and could technically host webhook receivers), the evidence pack contains no documentation, examples, or community reports about subscribing to or receiving webhooks, or any built-in event-subscription mechanism for AI agents.
Fly.ionone0/10No evidence Fly.io offers a webhook subscription/event system for its own platform events (deploys, machine state changes, etc.); the only webhook-related item describes Fly.io as a place to receive/ingest incoming webhooks, not a source of subscribable events.
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted5/10Cloudflare Workers docs advertise cron triggers, durable Workflows, and Queues for scheduling background automation (cloudflare-docs-9), which could support autonomous agent-like tasks. However, community evidence specifically counters this for long-running autonomous agent workloads: the 30s CPU limit on free tier and 15min cap even on paid plans 'don't work for long-running agent tasks,' pushing people to self-host instead (cloudflare-comm-9). missing for 10: evidence that Workflows/Durable Objects can sustain truly long-running autonomous agent loops without hitting CPU/time caps, and independent confirmation of successful production AI-agent automations on Workers.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.io markets 'Sprites' that sleep until needed, checkpoint themselves, and wake up remembering state, plus Machine restart policies that keep processes running autonomously — a reasonable base for background agent automation (fly-io-docs-4, fly-io-docs-5, fly-io-docs-26). However, community feedback explicitly flags that Fly lacks a built-in scheduler: 'the missing bit in Fly is scheduled tasks... basic cron-like scheduling should be part of the platform' (fly-io-comm-20), meaning real automation triggers require external glue rather than a native mechanism. Missing for 10: native cron/scheduled-trigger support, and independent hands-on evidence that long-running agent automations are reliable in production (reliability complaints exist elsewhere in the evidence pack, though not specific to automation).
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
- [claimed-docs] “The Machine restart policy defines whether and how flyd restarts a Machine after its main process exits.”
- [community] “For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but b…”
ai-native userOperate the product with natural-language commands
weight 2 · round to Fly.ioCloudflare Workersnone0/10Evidence shows Wrangler CLI and dashboard-based operation (docs-11, docs-20, probe-3) plus AI-inference/MCP-building capabilities for apps built on Workers (docs-3, docs-12), but nothing indicates Cloudflare Workers itself can be operated via natural-language commands (e.g., a chat-based deploy/manage interface). Missing for 10: any documented natural-language control plane, chatbot/agent for managing deployments, or NL-to-CLI translation feature.
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
- [claimed-docs] “You can build and deploy Model Context Protocol (MCP) servers on Cloudflare.”
Fly.io exposes an experimental flyctl MCP server (docs-29) that lets AI agents/assistants issue natural-language-driven commands against the platform, and the broader Sprites/agent-hosting narrative (docs-4–13, docs-28) shows agent-first design. However, the primary interface remains the traditional flyctl CLI and fly.toml config (docs-1, docs-16, docs-27), with no dedicated natural-language command layer for end users themselves. Missing for 10: a first-party natural-language chat/command interface for operating Fly.io (not just an experimental MCP passthrough), and independent corroboration that the MCP server reliably interprets NL commands.
- [claimed-docs] “[experimental] Start a flyctl MCP server”
- [claimed-docs] “Give your agent a real computer and get back to building.”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to Cloudflare WorkersThere is a machine-readable OpenAPI spec (openapi.json) confirming a formal API reference exists, and an llms.txt endpoint signaling AI-friendly doc structuring, but no evidence pack item describes an interactive explorer or runnable code examples within the docs. missing for 10: explicit interactive API reference UI, runnable/executable code samples in docs, hands-on confirmation of 'try it' functionality.
Fly.ionone0/10No evidence of an interactive API reference or runnable examples; the openapi probe returned 404s across all candidate paths and docs only describe REST API resources in prose form.
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to Cloudflare WorkersA probe confirms Cloudflare publishes a machine-readable OpenAPI spec at developers.cloudflare.com/openapi.json (HTTP 200, contains "openapi" key), plus an llms.txt for AI-native discovery. Missing for 10: independent third-party corroboration of spec completeness/usage beyond the probe.
Fly.ionone0/10Fly.io documents a REST API for Machines (fly-io-docs-31) but explicit probes for OpenAPI/swagger spec files at standard locations all return 404 (fly-io-probe-3), and no downloadable machine-readable spec is referenced anywhere in the docs.
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to Cloudflare WorkersCloudflare provides Miniflare/workerd-based local simulator and `wrangler dev` for developing and testing Workers locally without touching production, as documented in the workers-sdk repo descriptions and Wrangler CLI docs. This directly supports testing in an isolated sandbox before deployment. Missing for 10: explicit first-party documentation framing this as a 'staging/sandbox environment' separate from prod data, and independent hands-on confirmation that local simulation fully mirrors production behavior (e.g., bindings to real data stores).
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by [workerd](https://github.com/cloudflare/workerd)”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
Fly.io explicitly offers hardware-isolated, disposable VMs/Sprites with 'a clean baseline per request, so no two users ever share state,' plus checkpoint/rollback features that support spinning up isolated test environments without affecting production (fly-io-docs-7, fly-io-docs-9, fly-io-docs-4/5). However, this is all first-party marketing language with no independent or hands-on evidence confirming a documented staging/production separation workflow, and community threads focus on unrelated reliability complaints rather than sandbox isolation. Missing for 10: independent corroboration of sandbox isolation in practice, explicit staging-vs-production workflow documentation.
- [claimed-docs] “Run it in a hardware-isolated VM. A clean baseline per request, so no two users ever share state. Egress-locked and disposable.”
- [claimed-docs] “Roll back to any checkpoint in seconds”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnCloudflare Workersnone0/10Evidence shows Wrangler/API tooling, an OpenAPI spec, and Worker version rollback, but nothing documents a formal API versioning scheme or deprecation policy for Cloudflare's APIs. Missing for 10: explicit versioned API endpoints, a documented deprecation/sunset policy, and any changelog or migration guidance referenced in the evidence pack.
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
Fly.ionone0/10No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and no docs mention versioning/deprecation commitments.
developerThe documented rate limits and concurrency caps for APIs and functions so I can plan for scale
weight 3 · round to Cloudflare WorkersOnly indirect evidence exists: a community comment (comm-9) mentions concrete CPU-time limits (30s free tier, 15min paid) that could inform scaling decisions, but this is not from first-party docs and doesn't cover rate limits or concurrency caps generally. Missing for 10: official documentation pages on request-per-second rate limits, concurrent execution caps, subrequest limits, or a dedicated 'Limits' reference page.
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round drawnWorkers documentation mentions Queues, cron jobs, and durable Workflows (cloudflare-docs-9), which are building blocks that could be used to orchestrate bulk/batch processing across many items, but the evidence pack contains no explicit documentation of a bulk-operations API, batch endpoint, or example of processing many items in a single call. Missing for 10: dedicated bulk API/CLI feature (e.g., bulk KV writes, batch job examples), first-party guide on batch processing patterns, and independent confirmation of bulk workflows at scale.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
Fly.io exposes a REST API for provisioning/managing many Fly Apps, Machines, and Volumes (fly-io-docs-31) and CLI primitives like `fly machine run`/`fly scale` (fly-io-docs-27, fly-io-docs-24), which could be scripted for bulk actions, but there is no documented bulk/batch operation feature (e.g., a single command or endpoint acting on many resources at once) demonstrated in the evidence. missing for 10: explicit bulk/batch API endpoints or CLI flags for multi-resource operations, examples of scripted bulk workflows, independent confirmation of bulk automation use.
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round to Cloudflare WorkersWorkers documentation confirms event-driven automation primitives — cron triggers, durable Workflows, and Queues integration — which let developers define actions that fire automatically on schedule or on message/event arrival, and Wrangler/dashboard tooling supports managing these. However there's no deeper documentation of a full conditional 'rules engine' (e.g., branching logic across multiple event types) and no independent/hands-on corroboration specifically validating this automation depth. missing for 10: detailed docs on complex rule/condition chaining across event types, independent hands-on validation of automated trigger reliability, and examples beyond cron/queues/workflows.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
Fly.ionone0/10Fly.io's evidence only shows infrastructure-level triggers like Machine restart policies (restart on process exit) — not a general-purpose rules/automation engine for reacting to arbitrary events. Community feedback explicitly notes the platform lacks built-in scheduled/cron-like automation, requiring users to build their own scheduler apps, indicating no native event-rule automation capability exists.
- [claimed-docs] “The Machine restart policy defines whether and how flyd restarts a Machine after its main process exits.”
- [community] “For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but b…”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to Cloudflare WorkersCloudflare Workers explicitly supports cron triggers, durable Workflows, and Queues for scheduling recurring jobs (cloudflare-docs-9), which directly satisfies the automation-depth story. However, community feedback notes CPU-time limits (30s free / 15min paid) make it unsuitable for long-running AI agent workloads, a significant caveat for AI-native recurring automation (cloudflare-comm-9). Missing for 10: independent hands-on validation of cron/Workflows specifically for AI agent scheduling, and no evidence addressing the long-running-task limitation being resolved.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.ionone0/10No documentation evidence shows native recurring job/cron scheduling on Fly.io; a community comment explicitly states scheduled tasks are missing from the platform and must be built manually.
- [community] “For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but b…”
ai-native userVersion, review, and roll back my automations
weight 1 · round to Cloudflare WorkersCloudflare docs explicitly document version tracking and rollback of Worker deployments via Wrangler or dashboard, and note Git/GitHub Actions integration for standard workflows, which covers versioning and rollback for automations built on Workers. Missing for 10: explicit review/approval workflow tooling (e.g., staged review before promoting a version) and independent hands-on confirmation of rollback reliability.
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
Fly.io documents checkpoint-based rollback for its Sprite/agent runtime ('Roll back to any checkpoint in seconds', 'A Sprite checkpoints itself while the agent works'), which covers rollback of agent state, but there is no evidence of version history, diffing, or a review workflow for automations themselves. missing for 10: version history/diff view, review workflow before rollback, independent hands-on confirmation of checkpoint rollback working reliably
- [claimed-docs] “Roll back to any checkpoint in seconds”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
Deploy workflow — the commit-to-production path — builds, previews, rollbacksDeploy workflow
The commit-to-production path — builds, previews, rollbacks
Cli tooling
developerDeploy my project directly from the command line without using a web dashboard
weight 2 · round drawnWrangler CLI is documented with commands for creating, developing, and deploying Workers directly from the command line, including rollback support, and community comments corroborate CLI-based workflows (e.g., 'API running in production' via CLI-based workflow). Missing for 10: no direct hands-on transcript showing a full `wrangler deploy` session output.
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
Fly.io's core deploy workflow is CLI-first via flyctl: `fly launch` creates, configures, and deploys apps directly from the project directory, with additional CLI commands (`fly machine run`, `fly scale`, `fly doctor`) covering the full deploy lifecycle without needing a dashboard. Missing for 10: independent hands-on confirmation that dashboard is never required for any step (community evidence focuses on reliability, not on CLI-vs-dashboard workflow).
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
developerScaffold and deploy a new project with a single CLI command
weight 2 · round to Cloudflare WorkersCloudflare documents `npm create cloudflare@latest my-app` for scaffolding and Wrangler CLI for deployment, with dedicated commands docs and rollback support; community feedback corroborates fast, easy setup and deployment (e.g. API running in production within an hour). Missing for 10: independent hands-on verification of the exact one-command scaffold-to-deploy flow and any noted friction points beyond generic praise.
- [claimed-docs] “npm create cloudflare@latest my-app”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
First-party docs explicitly describe `fly launch` as a single command run from the project directory that creates, configures, and deploys a new app, matching the story precisely (fly-io-docs-16, fly-io-docs-1). However, there is no independent/hands-on confirmation of this specific scaffold-and-deploy flow, and several community reports describe general deploy flakiness on the platform (fly-io-comm-5, fly-io-comm-19) that add some uncertainty to the smoothness of the workflow. missing for 10: independent hands-on verification of `fly launch` succeeding cleanly, and resolution of community reports of deploy failures.
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
developerDevelop and test my app locally using a simulator that matches the production runtime
weight 2 · round to Cloudflare WorkersCloudflare Workers ships Wrangler with a bundled local simulator (Miniflare) explicitly described as 'powered by workerd' — the same runtime that runs Workers in production — enabling local dev/test that mirrors production behavior, backed by dedicated Wrangler CLI docs and commands. Missing for 10: independent/hands-on confirmation that local and production behavior stay perfectly in sync, and documentation of known simulator-vs-production edge-case gaps.
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by [workerd](https://github.com/cloudflare/workerd)”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
Fly.ionone0/10The evidence pack covers flyctl launch/deploy workflow, Fly Machines, Sprites, and MCP server support, but nowhere mentions a local simulator or emulator that replicates the production runtime for local development/testing. This is a reasonable capability to expect from a deploy platform, but no such tool (e.g., local Machines emulator) is documented.
Deployment strategies
developerDeploy applications packaged as Docker containers
weight 2 · round to Fly.ioCloudflare Workersnone0/10Cloudflare Workers is a V8-isolate serverless runtime; the evidence pack never mentions Docker or container-based deployment, and community feedback (comm-13) notes the lack of a full Node runtime, undermining any container-workflow support. This is a fair question for a deploy-workflow platform, but no evidence shows Workers supports deploying Docker-packaged apps.
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
Fly.iodisputedcontradicted5/10Fly.io's core docs clearly describe Docker-based deployment (fly launch/fly deploy converting Docker images into VMs, fly machine run, fly doctor checking Docker) [fly-io-docs-1, fly-io-docs-16, fly-io-docs-27, fly-io-docs-32, fly-io-docs-22], but hands-on community reports describe container deploys failing at high rates with unclear errors and stuck/unreachable instances, directly contradicting a smooth deploy workflow [fly-io-comm-5, fly-io-comm-19]. missing for 10: independent verification that Docker deploys work reliably at scale, and resolution of documented deploy failure reports.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
- [claimed-docs] “Run diagnostics: `fly doctor` — checks WireGuard, IPs, and Docker.”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
devops-leadRoll out new deployments incrementally to reduce blast radius
weight 2 · round drawnCloudflare Workersnone0/10The evidence pack shows Workers supports versioning and rollback to a previous deployment (cloudflare-docs-23) but contains no mention of percentage-based, canary, or gradual rollout mechanisms that would let a devops-lead incrementally shift traffic to a new deployment to limit blast radius.
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
Fly.ionone0/10The evidence pack shows generic deploy commands (`fly launch`, `fly machine run`, `fly scale`) and rollback/checkpoint features for Sprites, but nothing documents incremental rollout mechanisms like canary, rolling, or blue-green deployment strategies for reducing blast radius. Deployment platforms commonly support this, so absence of evidence means the axis is unmet rather than inapplicable.
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [claimed-docs] “The Machine restart policy defines whether and how flyd restarts a Machine after its main process exits.”
Git integration
developerAutomatically deploy my app on every Git push
weight 3 · round to Cloudflare WorkersDocs confirm Workers fits into Git/GitHub Actions workflows and supports CLI-based deploys plus rollbacks, implying CI/CD integration for git-push deploys, but there's no explicit first-party doc or hands-on account describing an automatic 'deploy on every git push' pipeline (e.g., Workers Builds) in this pack. Missing for 10: dedicated documentation/example of a git-integrated CI pipeline auto-triggering deploys, and independent user confirmation of this exact workflow.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
Fly.ionone0/10Fly.io's docs describe CLI-based deploys (`fly launch`, `fly deploy`, `fly machine run`) but nothing in the evidence pack mentions Git integration, GitHub Actions, or any automatic deploy-on-push workflow. This is a fair axis for a PaaS like Fly.io, but the evidence shows only manual/CLI-driven deploys, missing for 10: any mention of Git-triggered CI/CD, GitHub App integration, or auto-deploy hooks.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
developerDeploy my app by simply connecting my repo without manual build configuration
weight 3 · round to Cloudflare WorkersDocs mention that Workers 'fits into your existing workflows: Git, GitHub Actions' implying repo-based CI/CD, and support for many frameworks out of the box, but the evidence pack lacks explicit description of a zero-config 'connect repo and deploy' flow (e.g., automatic framework/build detection like Pages does) or hands-on confirmation that no manual build setup is needed. missing for 10: explicit docs on automatic build configuration detection, dashboard 'connect GitHub repo' walkthrough, and independent confirmation of a truly no-config deploy experience.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “Build full-stack apps with your framework of choice, including React, Vue, Svelte, Next, Astro, React Router, and more”
- [claimed-docs] “npm create cloudflare@latest my-app”
Fly.io's `fly launch` auto-detects app type and generates config/deploys with minimal manual setup (fly-io-docs-1, fly-io-docs-16), but this is a CLI-driven flow from a local project directory, not a GitHub-repo-connect auto-deploy UX like Vercel/Heroku. No evidence of a 'connect your repo and we build/deploy automatically' web integration. Community reports also cite frequent build/deploy failures undermining the 'no manual configuration' promise (fly-io-comm-5, fly-io-comm-19). Missing for 10: native repo-connect (GitHub App/webhook) auto-deploy flow, evidence of zero manual config across frameworks, and independent confirmation deploys succeed reliably without intervention.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
Infra as code
devops-leadDefine, deploy, and version my entire architecture with a single configuration file
weight 2 · round drawnWrangler's config (wrangler.toml/jsonc) plus CLI covers defining bindings/resources (docs-10), deploying (docs-11,20), and rolling back to prior versions (docs-23), which together approximate 'define, deploy, version' via one workflow. However, the evidence never explicitly shows the wrangler.toml file itself, multi-environment/staging config, or how complex multi-service architectures (Queues, Durable Objects, D1, R2) are all declared in a single file rather than via dashboard clicks or multiple bindings setup steps. Missing for 10: explicit wrangler.toml example, multi-environment config docs, and independent confirmation that full architecture (not just a single Worker) can be captured in one file.
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
Fly.io's `fly launch` workflow creates, configures, and deploys an app from a single project directory (fly-io-docs-16, fly-io-docs-1), and `fly machine run` further shows one-line create+deploy semantics (fly-io-docs-27), implying a single fly.toml-style config drives the whole architecture. However the evidence never explicitly names or documents the fly.toml config schema, nor shows how that file is versioned/rolled back (the 'roll back to any checkpoint' claim, fly-io-docs-9, refers to Sprite/agent checkpoints, not app config versioning), and 'fly scale' (fly-io-docs-24) is a separate CLI action rather than config-driven scaling. Missing for 10: explicit fly.toml schema/documentation, config-file-based versioning or rollback, multi-service/region architecture defined in one file, independent hands-on confirmation.
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [claimed-docs] “Roll back to any checkpoint in seconds”
- [claimed-docs] “The Machine restart policy defines whether and how flyd restarts a Machine after its main process exits.”
Manual deploy
developerDeploy a project by uploading a folder of files directly, with no Git repo required and the new deployment kept private until I choose to publish it
weight 2 · round to Fly.ioCloudflare Workersnone0/10The evidence describes CLI-based deployment via Wrangler (npm create cloudflare, wrangler commands, rollbacks) but nothing about a no-Git folder-upload flow with a private, unpublished draft state before publishing.
Fly.io's flyctl/fly launch and fly deploy explicitly work from a local project directory without requiring a Git repository (fly-io-docs-1, fly-io-docs-16), satisfying the 'no Git repo required, folder upload' part of the story. However, there is no evidence of a staging/private mode where a new deployment is kept private until the developer chooses to publish it — Fly apps get a live URL immediately upon deploy. Missing for 10: documentation of a private/draft deployment state, a publish/promote step, or preview-URL gating before public exposure.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
Preview envs
developerGet ephemeral full-stack preview environments for every pull request
weight 2 · round drawnCloudflare Workersnone0/10The evidence pack describes Workers' general deployment, versioning, and rollback capabilities, but nowhere mentions automatic ephemeral preview environments tied to pull requests (a feature associated with Cloudflare Pages, not documented here for Workers). Missing for 10: any documentation of per-PR preview URLs, ephemeral environment provisioning, or GitHub PR integration producing full-stack previews.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
Fly.ionone0/10Evidence shows Fly.io provides general app deployment (fly launch, Machines, scaling) but no dedicated feature or integration for automatic ephemeral preview environments tied to pull requests (e.g., GitHub PR bot, per-PR subdomains, auto-teardown). Missing for 10: PR-triggered environment creation, GitHub Actions/PR integration, automatic teardown on merge/close, full-stack (app+DB) preview provisioning per PR.
developerGet an automatic preview URL for every pull request
weight 3 · round drawnCloudflare Workersnone0/10No evidence in the pack mentions Cloudflare Workers automatically generating preview URLs for pull requests (e.g., via Workers Builds or Pages-style git integration); only generic deployment, Wrangler CLI, and rollback docs are cited. This is a fair and applicable axis for a serverless deploy platform, but the pack lacks any confirmation of automatic PR preview URLs.
Rollback recovery
developerRoll back a deployed service to any previous version in one click
weight 3 · round to Cloudflare WorkersCloudflare docs explicitly confirm rollback to any previously deployed version of a Worker via Wrangler CLI or the dashboard, directly matching the story. Missing for 10: no independent/hands-on confirmation of the one-click UX or edge cases (e.g. rollback with bindings/config changes).
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
Fly.io's marketing copy claims 'Roll back to any checkpoint in seconds' (fly-io-docs-9), which suggests rollback capability, but this appears tied to Sprites (AI-agent sandboxes) checkpointing rather than a documented one-click rollback for standard deployed services/releases. No CLI docs (e.g., 'fly releases rollback') or hands-on/community confirmation of this exact deploy-workflow capability are present. Missing for 10: explicit docs on rolling back a deployed app/service version via CLI or dashboard, a one-click UI flow, and independent verification that it works as described for standard services.
- [claimed-docs] “Roll back to any checkpoint in seconds”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
Templates
developerDeploy one-click templates and starters for common use cases
weight 1 · round to Cloudflare WorkersCloudflare's `npm create cloudflare@latest` CLI (cloudflare-docs-2) and framework support for React, Vue, Svelte, Next, Astro etc. (cloudflare-docs-6) indicate scaffolding from starter templates, and Wrangler docs (cloudflare-docs-11, -20) cover creating/deploying projects. However, the pack lacks explicit evidence of a curated one-click template gallery or 'deploy to Cloudflare' button flow comparable to competitors, and one community note (cloudflare-gh) even flags a showcase project (Wildebeest) being abandoned shortly after launch. Missing for 10: an explicit template/starter gallery page, one-click deploy button UX, and independent hands-on confirmation of ease of using such templates.
- [claimed-docs] “npm create cloudflare@latest my-app”
- [claimed-docs] “Build full-stack apps with your framework of choice, including React, Vue, Svelte, Next, Astro, React Router, and more”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [community] “Wildebeest (Fediverse on Cloudflare Workers) ceased maintenance one month after its announcement blog post, later archived with a note it wa…”
Fly.ionone0/10Evidence shows `fly launch` scaffolding/deploying from an existing source directory and generic tech-specific docs, but there is no evidence of a curated one-click template/starter gallery for common use cases (e.g., a marketplace of pre-built app templates).
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Check out the docs specific to your tech so you can move faster.”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
Dev experience — day-to-day developer experience — setup friction, docs, debugging, iteration speedDev experience
Day-to-day developer experience — setup friction, docs, debugging, iteration speed
Environments
developerSpin up unlimited isolated environments so my whole team can ship simultaneously
weight 1 · round to Fly.ioWorkers' architecture (isolate-based execution, Miniflare local simulator, quick project scaffolding via `npm create cloudflare`, and Wrangler CLI for deploy/rollback) supports fast, isolated dev setups, and Workers fit into existing Git/CI workflows implying branch-based deploys. However, there is no explicit documentation of per-branch/preview environments, environment-scoping features, or team-scale 'unlimited environments' guarantees in the evidence pack. Missing for 10: explicit preview/staging environment docs, team-scale environment provisioning evidence, and independent confirmation of simultaneous multi-developer isolated environments.
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [claimed-docs] “npm create cloudflare@latest my-app”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
Fly.io's Machines/Sprites provide fast-launching, hardware-isolated VMs that can scale out to thousands of instances, and features like per-agent Sprites (docs-4/5/6) and fast `fly machine run`/`fly launch` (docs-16/27) support spinning up many isolated environments for parallel work. However, there's no explicit 'unlimited' guarantee, and multiple independent hands-on reports describe reliability problems (stuck/unreachable machines, flaky deploys, outages affecting staging/production) that would undermine a team's ability to reliably ship simultaneously at scale. Missing for 10: an explicit 'unlimited' or team-collaboration framing, and stronger independent corroboration that concurrent environment creation is reliable at scale.
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
- [claimed-docs] “Run it in a hardware-isolated VM. A clean baseline per request, so no two users ever share state. Egress-locked and disposable.”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “The `fly machine run` command is a tool to configure, build, and start a new Machine in one line.”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
Scaling continuity
developerRely on the same core APIs and primitives from prototype through massive scale, without rearchitecting or migrating platforms as usage grows
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted5/10Cloudflare docs promote a unified model—Workers plus bindings to KV/D1/Queues/Workflows—that in principle lets code scale from prototype to production without changing runtime primitives, and per-request (not wall-time) billing plus Smart Placement are pitched as scale-friendly (cloudflare-docs-9, cloudflare-docs-10, cloudflare-docs-15, cloudflare-docs-16). However, hands-on community reports concretely contradict frictionless scaling: CPU-time caps (30s free/15min paid) are reported as unworkable for long-running agent workloads, forcing self-hosting (cloudflare-comm-9), and developers report needing to rearchitect away from Workers entirely due to lack of full Node runtime and platform lock-in around KV/D1 (cloudflare-comm-13, cloudflare-comm-10). missing for 10: evidence that identical code/bindings scale to heavy long-running or compute-intensive workloads without hitting execution limits, and independent case studies confirming zero-rearchitecture scale-up.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [claimed-docs] “Smart Placement moves your Worker closer to your data for optimized end-to-end latency.”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
- [community] “Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. ... being able to run the same code on your own …”
Fly.io explicitly claims consistent primitives across scale ("Keep the same primitives at every scale... The API you start with is the API you keep") and backs this with Fly Machines' fast-boot VM API, `fly scale`, and a unified REST API for Apps/Machines/Volumes usable from prototype to production. However, this is a first-party marketing claim with no independent case study or benchmark showing a real app scaling from prototype to 'massive scale' on the same primitives without changes. Missing for 10: independent verification of large-scale deployments retaining the original API/architecture, and case studies documenting zero-rearchitecture growth.
- [claimed-docs] “Keep the same primitives at every scale: no rearchitecting when you grow, and no platform migration when you get big. The API you start with…”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
Secrets management
devops-leadManage team-level access, secrets, and environment variables centrally
weight 2 · round to Fly.ioEvidence only shows Cloudflare API tokens can be scoped to specific resources (e.g., Zone DNS read access), which supports granular access control, but there is no documentation of team-level role management, centralized secrets storage, or environment-variable management for a devops-lead. missing for 10: team/organization RBAC docs, secrets management (e.g., Secrets Store) evidence, environment variable management across environments, and any hands-on confirmation of these features.
- [claimed-docs] “Select which resources the token is authorized to access.”
- [claimed-docs] “granting Zone DNS Read access to a zone example.com will allow the token to read DNS records only for that specific zone”
Fly.io docs show centralized secrets management (encrypted vault) and org-wide connection/credential rotation with granular access grants by Sprite/label, which covers secrets and env-var centralization. However there is no evidence of team-member role management, invites, or permission tiers for a devops-lead to administer team access explicitly. Missing for 10: team/user role management (RBAC), member invite/permission workflows, and independent corroboration of the org-wide credential features actually working at scale.
- [claimed-docs] “Secrets allow sensitive values, such as credentials, to be passed securely to your Fly App. The secret is encrypted and stored in a vault.”
- [claimed-docs] “Connect a service once for your whole org, and every Sprite can reach it. Nobody pastes a token.”
- [claimed-docs] “Grant access on purpose: by Sprite name, by label, or down to a single endpoint, so a Slack bot can post messages and never touch admin.”
- [claimed-docs] “Rotate once and every Sprite has the new credential. Cut off a single Sprite and the rest never notice.”
Tool continuity
developerKeep using my existing Git, CI, editor, and framework workflows without adopting proprietary tooling
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted6/10Cloudflare explicitly claims Workers 'fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework... No proprietary tools or vendor lock-in' and backs this with framework/language choice, Wrangler CLI, and a local dev simulator (workerd) that integrates with standard editor/CI tooling. However, hands-on community reports directly contradict the 'no lock-in' claim: developers note KV/D1 storage APIs and lack of a full Node runtime make it hard to port apps to/from Vercel/Netlify or self-hosted setups without rewrites, undermining the 'use your existing workflow freely' promise. missing for 10: independent verification that CI/editor integration is friction-free in practice, and resolution of the documented runtime/storage lock-in concerns.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [claimed-docs] “Build full-stack apps with your framework of choice, including React, Vue, Svelte, Next, Astro, React Router, and more”
- [claimed-docs] “Use your preferred language, including JavaScript, TypeScript, Python, Rust, and more”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [community] “Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. ... being able to run the same code on your own …”
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
Fly.io explicitly supports deploying arbitrary Docker images and offers framework-specific guides, implying existing frameworks and build tooling continue to work rather than requiring a proprietary runtime (fly-io-docs-32, fly-io-docs-2, fly-io-docs-25). However, developers must still adopt the flyctl CLI and fly.toml config to deploy (fly-io-docs-1, fly-io-docs-16), and there is no evidence of native Git-push deploy, first-class CI/CD templates, or editor integrations. missing for 10: explicit CI/CD pipeline integration evidence, git-based deploy workflow, editor/IDE integration, confirmation that no Fly-specific code changes are needed for common frameworks.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Check out the docs specific to your tech so you can move faster.”
- [claimed-docs] “Run `fly launch` from inside your project source directory to create, configure, and (for most apps) deploy a new application.”
- [claimed-docs] “Fly.io makes it easier to run an Elixir cluster on multiple servers around the world and deploy to those regions with a single command.”
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
developerWrite code against standard runtime APIs so it runs unmodified across multiple edge platforms instead of being locked into proprietary storage/runtime APIs
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted5/10Cloudflare markets Workers as fitting 'existing workflows... no proprietary tools or vendor lock-in' (cloudflare-docs-17) and Workers do use some standard Web APIs (fetch/Request/Response), but hands-on community reports directly contradict the portability claim for storage/runtime: developers cite KV, D1, and other bindings as proprietary lock-in that 'always made it hard to switch,' explicitly wanting to 'run the same code on your own stuff or a small VPS without changing the storage' (cloudflare-comm-10), and others note the lack of a full Node runtime prevents switching between Vercel/Netlify/Cloudflare (cloudflare-comm-13), and Python support gaps limit portability further (cloudflare-comm-14). missing for 10: evidence of actual standards-based (e.g. WinterCG-compliant) runtime API parity independent of proprietary bindings, and confirmation that storage APIs are swappable/standard rather than Cloudflare-specific.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [community] “Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. ... being able to run the same code on your own …”
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
- [community] “I've used CF Pages for static sites with great results and am intrigued by all their open-source-LLM-as-a-service offerings. Main issue prev…”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
Fly.io runs standard Docker images and VMs rather than a proprietary edge-runtime API, and docs explicitly state 'the API you start with is the API you keep' with no rearchitecting or migration needed, plus standard Postgres rather than proprietary storage APIs. Missing for 10: independent third-party confirmation that code written for Fly ports unmodified to other platforms, and explicit contrast with proprietary edge-runtime APIs (e.g. Workers/Deno) rather than just general platform-migration claims.
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
- [claimed-docs] “Keep the same primitives at every scale: no rearchitecting when you grow, and no platform migration when you get big. The API you start with…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
Edge compute — running code at the edge — regions, cold starts, runtime limitsEdge compute
Running code at the edge — regions, cold starts, runtime limits
Agent runtime
ai-native builderGive my coding agent a persistent runtime environment that checkpoints its state automatically while working
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted5/10Cloudflare docs reference 'durable Workflows' and agent-oriented billing that doesn't charge for idle/hibernating time (cloudflare-docs-9, cloudflare-docs-15), suggesting some support for persistent, checkpointed agent runtimes, but there's no explicit documentation of Durable Objects or automatic state checkpointing for coding agents. Community evidence directly contradicts the practical viability for long-running agent tasks, noting CPU time limits (30s free / 15min paid) make Workers unsuitable for long-running agent workloads, pushing developers to self-host instead (cloudflare-comm-9). missing for 10: explicit Durable Objects/state-checkpointing documentation for agents, confirmation that long-running agent tasks work without hitting CPU/time limits, first-party agent-specific persistence guide.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.io's docs explicitly describe 'Sprites' as persistent agent runtimes that checkpoint themselves automatically and can be rolled back to any checkpoint, directly matching the story (fly-io-docs-4, fly-io-docs-5, fly-io-docs-9, fly-io-docs-28). This is a first-party marketing description with no independent hands-on verification of the Sprite checkpointing mechanism specifically, and general community reliability complaints (unrelated to Sprites) raise some doubt about production robustness. Missing for 10: independent/hands-on corroboration of Sprite checkpoint/restore behavior, and detail on failure modes or reliability of the checkpointing feature itself.
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
- [claimed-docs] “Roll back to any checkpoint in seconds”
- [claimed-docs] “Give your agent a real computer and get back to building.”
Ai inference
ai-native builderRun AI model inference globally with a single call without managing GPUs or capacity planning
weight 3 · round to Cloudflare WorkersCloudflare's docs explicitly state Workers AI lets you 'run AI inference globally with one API call... no GPUs to manage, no capacity planning' (cloudflare-docs-3), directly matching the story, and the broader Workers platform (global edge network, no server/cold-start management) supports this claim (cloudflare-docs-1, cloudflare-docs-19). However, evidence is entirely first-party marketing/docs with no independent hands-on benchmarks or user reports specifically validating Workers AI inference performance or global reach, and general community skepticism exists about doc accuracy on newer Cloudflare AI products (cloudflare-comm-6). Missing for 10: independent/hands-on validation of Workers AI inference specifically, details on model catalog/latency benchmarks, and confirmation from third-party users running production AI inference on Workers.
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [community] “Not the first time Cloudflare has done this. Click around some of the docs for Realtime SFU, it's all AI slop. Hard to tell if anything is h…”
Fly.ionone0/10The evidence pack documents Fly Machines/Sprites as general-purpose global compute VMs, agent sandboxes, and Postgres, but contains no mention of a managed AI inference/model-serving API, GPU provisioning, or 'single call' inference capability abstracting away GPU/capacity management. Absence of evidence for this applicable capability yields none.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
Placement latency
devops-leadDeploy my application to specific regions closer to my users
weight 2 · round to Fly.ioWorkers deploy automatically across Cloudflare's global edge network, meaning code runs close to users worldwide by default (cloudflare-docs-1, cloudflare-docs-19), and Smart Placement further optimizes Worker placement relative to backend data for latency (cloudflare-docs-16, cloudflare-docs-8). However, this is an automatic proximity model rather than explicit region selection/pinning that a devops-lead could target — there's no evidence of manual region choice, data-residency controls, or region-restricted deployment commands. Missing for 10: explicit region-selection/pinning API or dashboard control, data residency guarantees, and independent verification that global auto-placement matches manual region targeting needs.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [claimed-docs] “Smart Placement moves your Worker closer to your data for optimized end-to-end latency.”
- [claimed-docs] “Build APIs and connect to data stores with Smart Placement to optimize latency”
Fly.io explicitly documents deploying apps to specific regions worldwide via its global Anycast network so users connect to the nearest server, and other docs reference region-based multi-server deployment with a single command. missing for 10: independent/hands-on corroboration specifically validating regional deployment behavior (community evidence focuses on outages/reliability, not region selection).
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly.io makes it easier to run an Elixir cluster on multiple servers around the world and deploy to those regions with a single command.”
devops-leadRely on automatic compute placement near backend data to optimize latency
weight 2 · round to Cloudflare WorkersCloudflare documents Smart Placement, a feature explicitly designed to automatically move Worker execution closer to backend data sources to optimize end-to-end latency, directly matching the story. This is first-party documented and reinforced across multiple docs pages, though there is no independent/hands-on benchmark confirming real-world latency gains. Missing for 10: independent performance validation or case study demonstrating measured latency improvement from Smart Placement.
- [claimed-docs] “Build APIs and connect to data stores with Smart Placement to optimize latency”
- [claimed-docs] “Smart Placement moves your Worker closer to your data for optimized end-to-end latency.”
Fly.io documents global region deployment and Anycast routing so user traffic reaches the nearest server (fly-io-docs-20), and offers a managed Postgres service (fly-io-docs-19), but region placement is manual (fly launch/region flags) rather than an automatic system that senses backend-data location and relocates compute accordingly. Missing for 10: explicit automatic/backend-data-aware placement logic, documentation of latency-optimizing scheduling relative to a database's region, and independent verification that this placement actually reduces latency in production.
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
Realtime connections
developerHandle persistent WebSocket connections from within edge/serverless functions for real-time apps
weight 2 · round to Cloudflare WorkersCloudflare docs reference billing for 'hibernating WebSockets' during long-running workflows, implying built-in support for persistent WebSocket connections (likely via Durable Objects), but the evidence pack lacks dedicated documentation of the WebSocket API, hibernation API, or Durable Objects mechanics. An older community comment notes WebSockets support was still 'in beta' at one point, adding some uncertainty about maturity, though this isn't a concrete current-state failure. missing for 10: explicit docs on WebSocket/Durable Objects APIs, hands-on developer confirmation of stable persistent connections, clarity on beta status resolution.
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [community] “I've been watching Workers with interest basically since the beginning. Now they just need to bring WebSockets support out of beta.”
Fly Machines are persistent, hardware-isolated VMs (not typical ephemeral serverless functions) that boot fast and run close to users globally, which architecturally supports long-lived connections like WebSockets, but no evidence explicitly documents WebSocket handling or real-time connection APIs. missing for 10: explicit WebSocket/real-time API documentation, hands-on example of persistent socket handling in a Fly app, confirmation of behavior under Fly's edge/global routing for stateful connections.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
Runtime compatibility
developerRun unmodified Node.js code and npm packages in edge/serverless functions instead of a restricted runtime subset
weight 3 · round to Fly.ioCloudflare Workersnone0/10Evidence shows Workers support JS/TS/Rust/Python via a V8-isolate runtime, but nothing claims unmodified Node.js/npm compatibility, and community feedback explicitly states the opposite ('Can we just get full node runtime?... without a full node runtime... can't switch from Vercel/Netlify').
- [claimed-docs] “Use your preferred language, including JavaScript, TypeScript, Python, Rust, and more”
- [community] “Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from…”
Fly.io's architecture (Fly Machines are hardware-isolated VMs running arbitrary Docker images, not a restricted sandboxed runtime) implies full support for running unmodified Node.js/npm code rather than a limited edge-function subset, and docs mention converting Docker images to fast-booting global VMs. However, the evidence pack never explicitly confirms Node.js/npm support, unmodified code compatibility, or names it as an edge-function alternative. Missing for 10: explicit Node.js/npm runtime documentation, confirmation that npm native modules/unsupported APIs work unmodified, and independent developer reports of running standard Node apps without modification.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
developerWrite edge functions in languages other than JavaScript such as Python, Go, or Rust
weight 2 · round to Fly.ioCloudflare Workersdisputedcontradicted5/10Cloudflare's own docs explicitly claim Workers support 'JavaScript, TypeScript, Python, Rust, and more' (cloudflare-docs-7), and Wrangler/workers-sdk tooling supports multi-language builds. However, a hands-on community report explicitly cites 'lack of Python support' as a blocker to building more on Cloudflare (cloudflare-comm-14), and no evidence in the pack shows working Go support or first-class (non-WASM) language support beyond JS/TS. missing for 10: independent confirmation of Python/Rust/Go working smoothly in production, clarification of Python's beta/Pyodide limitations, and any mention of Go support at all.
- [claimed-docs] “Use your preferred language, including JavaScript, TypeScript, Python, Rust, and more”
- [community] “I've used CF Pages for static sites with great results and am intrigued by all their open-source-LLM-as-a-service offerings. Main issue prev…”
Fly.io runs any Docker container as a Fly Machine deployed globally close to users, which inherently supports any language (Python, Go, Rust, etc.) rather than restricting to JavaScript, and docs highlight global regional deployment via Anycast for low-latency edge-like compute. However, there is no explicit 'edge functions' framework or per-language quickstart tutorials cited, so this is inferred from the general VM/container model rather than dedicated edge-function tooling. Missing for 10: explicit per-language edge-function guides/examples for Python, Go, Rust, and independent corroboration of using Fly for edge-function-style workloads.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Fly.io converts Docker images to fast-booting VMs and runs them globally. This is great or ingesting incoming data!”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
Sandboxing
developerRun untrusted code in hardware-isolated, disposable sandboxes
weight 2 · round to Fly.ioCloudflare Workersnone0/10The evidence pack describes Workers as a general serverless/edge compute platform (deployment, bindings, frameworks, Wrangler CLI) but never mentions the underlying isolate/sandbox security model, hardware isolation guarantees, or a use case of running untrusted third-party code (e.g. Workers for Platforms, V8 isolate security boundaries). No citation addresses sandboxing untrusted code specifically. Missing for 10: any mention of V8 isolate/hardware isolation architecture, security boundary guarantees for untrusted code, or a multi-tenant 'Workers for Platforms' style product, and any independent security audit/hands-on evidence of sandbox isolation.
Fly.io explicitly documents hardware-isolated, disposable Fly Machines/Sprites with 'clean baseline per request', egress-locked, no shared state, and per-agent isolated Linux boxes for untrusted/agent workloads (fly-io-docs-7, fly-io-docs-14, fly-io-docs-4, fly-io-docs-6, fly-io-docs-17). This directly matches the sandboxed untrusted-code execution story. Missing for 10: independent/hands-on verification of the isolation guarantees and no third-party security audit evidence is present.
- [claimed-docs] “Run it in a hardware-isolated VM. A clean baseline per request, so no two users ever share state. Egress-locked and disposable.”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
- [claimed-docs] “Fly Machines are tightly isolated VMs that are perfect for running MCP servers.”
Scaling
devops-leadDeploy instances that boot in under a second and scale to tens of thousands under load
weight 2 · round to Cloudflare WorkersCloudflare explicitly markets Workers as having 'no cold starts' running on isolates across its global network, and community reports corroborate very fast startup and easy scaling for production APIs (docs-1, comm-2, comm-3, comm-11). However, the pack lacks independent load-test data proving 'tens of thousands' concurrent scale, and some users note CPU-time limits complicating long-running workloads. missing for 10: independent benchmark/load-test evidence of concurrency at scale, third-party boot-time measurements beyond vendor claims.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [community] “Amazed by what OP and the Workers team have done over the years. Took a while for us to get used to the Workers paradigm. But once we did, f…”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
- [community] “I've played with JS workers on a Cloudflare-fronted site and found them to be easy to use and very quick. Would love to port the whole Djang…”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.iodisputedcontradicted5/10Fly.io's own docs explicitly claim Machines 'boot in under a second... and scale out to tens of thousands when the traffic arrives' (fly-io-docs-14), backed by fast-launch API and scale commands (fly-io-docs-18, fly-io-docs-24). However, multiple independent community reports describe real production reliability problems under load — frequent machine failures, stuck/unreachable instances, flaky deploys (70-80% failure rate), and multi-machine outages with no status-page acknowledgment (fly-io-comm-1, fly-io-comm-5, fly-io-comm-7, fly-io-comm-19) — directly undercutting the claim of dependable scaling at volume. missing for 10: independent benchmark data on actual boot latency and large-scale load tests, and resolution/acknowledgment of the reliability complaints.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [community] “This is the second time I've had this kind of issue with Fly, where my service just goes down, Fly reports everything healthy, and there's l…”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “I really want to love Fly.io... but to be honest I don't think anyone should be building mission critical applications on their service. I e…”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
devops-leadRely on load-based autoscaling to absorb large traffic bursts automatically
weight 2 · round to Cloudflare WorkersWorkers' serverless, global-network architecture ('no servers to manage', 'no cold starts or region complexity') implies automatic scaling to traffic without ops intervention, and community posts corroborate quick, hands-off scaling in production use. However, there is no explicit documentation of autoscaling mechanics, burst-handling guarantees, or SLAs, and community evidence flags CPU-time limits (30s free/15min paid) as a real constraint for sustained high-load workloads. Missing for 10: explicit autoscaling/burst-capacity documentation, quantified traffic-spike case studies, and confirmation that limits don't throttle under load.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.io markets that 'Fly Machines ... scale out to tens of thousands when the traffic arrives' and offers a 'fly scale' command for horizontal/vertical scaling, suggesting scaling capability exists, but the evidence never documents concrete load-based autoscaling policies (e.g., CPU/request-triggered auto-scale-up/down) — 'fly scale' reads as a manual operator command rather than automatic burst absorption. Community reports also describe outages and unreliable behavior under production load, undercutting confidence that bursts are absorbed smoothly. Missing for 10: documented automatic autoscaling triggers/policies, hands-on evidence of successful burst handling, and resolution of the reliability complaints during high load.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “the `fly scale` command for quick horizontal and vertical scaling”
- [community] “We had four machines (app + Postgres for staging and production) running yesterday, and three of the four (including both databases) are sti…”
- [community] “I really want to love Fly.io... but to be honest I don't think anyone should be building mission critical applications on their service. I e…”
- [community] “Fly response: 'We had a single host in the syd region go down, hard, with multiple issues... Ultimately it required a significant amount of …”
Serverless runtime
developerRun my code on a global edge network close to end users
weight 3 · round to Cloudflare WorkersCloudflare Workers is explicitly documented and independently corroborated as a global edge compute platform, with docs on deployment to Cloudflare's global network, Smart Placement for latency optimization, and multiple hands-on community reports confirming fast, easy deployment across regions. Missing for 10: no independent latency benchmarks quantifying edge proximity to end users.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Smart Placement moves your Worker closer to your data for optimized end-to-end latency.”
- [claimed-docs] “Build APIs and connect to data stores with Smart Placement to optimize latency”
- [community] “Amazed by what OP and the Workers team have done over the years. Took a while for us to get used to the Workers paradigm. But once we did, f…”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
- [community] “I've played with JS workers on a Cloudflare-fronted site and found them to be easy to use and very quick. Would love to port the whole Djang…”
Fly.io explicitly documents deploying apps to multiple regions worldwide via a global Anycast network so users connect to the nearest server, backed by fast-booting, hardware-isolated Fly Machines that scale globally (fly-io-docs-14, fly-io-docs-20, fly-io-docs-18). This directly matches the edge-compute story. Missing for 10: independent latency benchmarks confirming real-world edge performance, and community reports of intermittent outages/reliability issues (fly-io-comm-1, fly-io-comm-7, fly-io-comm-19) temper confidence in production robustness even though they don't contradict the core global-deployment capability.
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
developerDeploy serverless functions and full-stack apps with no servers to manage
weight 3 · round to Cloudflare WorkersCloudflare Workers is extensively documented as a no-server-management serverless platform supporting full-stack frameworks, multiple languages, bindings to data stores, CLI (Wrangler) deployment, and rollback, corroborated by independent developer testimonials describing production use with no server management. Missing for 10: fully independent (non-vendor) benchmark of 'no cold starts' claims and some community friction around limits for long-running tasks (community notes on CPU time limits and lock-in), which slightly tempers a perfect score.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build full-stack apps with your framework of choice, including React, Vue, Svelte, Next, Astro, React Router, and more”
- [claimed-docs] “Use your preferred language, including JavaScript, TypeScript, Python, Rust, and more”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [community] “Amazed by what OP and the Workers team have done over the years. Took a while for us to get used to the Workers paradigm. But once we did, f…”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
- [community] “I've played with JS workers on a Cloudflare-fronted site and found them to be easy to use and very quick. Would love to port the whole Djang…”
- [probe] “official CLI documented at https://developers.cloudflare.com/workers/wrangler/”
Fly.iodisputedcontradicted5/10Fly.io's docs describe a workflow (`fly launch`, Fly Machines that boot in under a second and scale to zero, Managed Postgres, global regions, pay-as-you-go pricing) that strongly emphasizes not needing to provision or manage servers for full-stack apps [fly-io-docs-1][fly-io-docs-14][fly-io-docs-19][fly-io-docs-20][fly-io-docs-21]. However, multiple independent hands-on reports describe machines/Postgres going down with no self-healing, requiring manual recovery work, and Fly's own support response recommending users 'run multiple instances to mitigate the impact of single-host failures' — directly undercutting the 'no servers to manage' promise [fly-io-comm-2][fly-io-comm-4][fly-io-comm-9][fly-io-comm-15][fly-io-comm-19]. Missing for 10: true FaaS/serverless-functions primitive (Fly is VM/container-based, not function-as-a-service), and resolution of the reliability complaints that contradict hands-off operation.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Unlike Heroku's dyno-based tiers, Fly.io uses pay-as-you-go pricing - you only pay for the compute, storage, and bandwidth you actually use.”
- [community] “We had four machines (app + Postgres for staging and production) running yesterday, and three of the four (including both databases) are sti…”
- [community] “Don't get me started with Fly — especially postgres machines. In my experience, a really nice idea with poor support and unreliable infrastr…”
- [community] “Fly response: 'We had a single host in the syd region go down, hard, with multiple issues... Ultimately it required a significant amount of …”
- [community] “I was an early adopter of Fly.io. It is not production-ready. They should fix their basic features before adding new ones.”
- [community] “Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deplo…”
Workflows
developerDeploy durable, long-running workflows as code without manually wiring queues and retries
weight 2 · round to Cloudflare WorkersCloudflare explicitly advertises 'durable Workflows' as a built-in Workers feature integrated with Queues and cron scheduling, and its pricing model is designed to support long-running workflows without extra wall-time cost, which matches the story's intent. However, the evidence pack gives only a single sentence describing this feature with no detail on step/retry semantics, and a community comment raises concerns that Workers' CPU-time limits are unsuited to long-running agent-style workloads, adding a real caveat. missing for 10: detailed documentation of Workflows API (steps, automatic retries, state persistence), independent hands-on validation of durability guarantees, and resolution of the CPU-time-limit concern for long-running tasks.
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
Fly.ionone0/10Fly.io evidence covers VM provisioning, restart policies, and infrastructure primitives (Machines, checkpoints, Postgres) but nothing about a durable workflow-as-code abstraction, built-in queueing, or automatic retry orchestration for long-running business workflows. The restart policy docs (fly-io-docs-26) only cover process-level VM restarts, not workflow state/retry semantics.
- [claimed-docs] “The Machine restart policy defines whether and how flyd restarts a Machine after its main process exits.”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [community] “For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but b…”
Networking security — network controls and isolation — private access, firewalls, encryptionNetworking security
Network controls and isolation — private access, firewalls, encryption
Access control
developerPut simple password protection on a deployed site without standing up a custom auth system
weight 2 · round to Cloudflare WorkersCloudflare's docs mention that 'Zero Trust controls are built into the network and run on every request from day one' (docs-18), which hints at Access-based authentication gating that could be used for password protection, but there's no direct documentation, tutorial, or example showing a simple password-gate on a Worker/site without building custom auth. missing for 10: explicit Cloudflare Access/password-protection walkthrough, developer confirmation it works as a lightweight auth layer, and any hands-on corroboration of ease-of-use for this specific use case.
- [claimed-docs] “DDoS protection, WAF, bot management, and Zero Trust controls are built into the network and run on every request from day one.”
Fly.ionone0/10The evidence pack contains no mention of any built-in basic-auth/password-protection feature for deployed apps (e.g., no proxy-level HTTP auth, no dashboard toggle). While secrets management is documented (fly-io-docs-23), that only covers passing credentials to the app, not adding password gating without custom auth code — this axis is plausible for a deployment platform but unevidenced here.
- [claimed-docs] “Secrets allow sensitive values, such as credentials, to be passed securely to your Fly App. The secret is encrypted and stored in a vault.”
Ddos waf
devops-leadHave DDoS protection and a web application firewall applied to every request by default
weight 3 · round to Cloudflare WorkersCloudflare docs explicitly state that DDoS protection, WAF, bot management, and Zero Trust controls are built into the network and run on every request from day one, directly matching the story for Workers deployed on that network. Missing for 10: independent/hands-on verification or granular configuration details showing default-on behavior in practice (e.g., WAF rule specifics for Workers routes).
- [claimed-docs] “DDoS protection, WAF, bot management, and Zero Trust controls are built into the network and run on every request from day one.”
Domains
developerAttach custom domains to my deployed services
weight 2 · round drawnCloudflare Workersnone0/10The evidence pack lacks any explicit documentation or community mention of attaching custom domains specifically to deployed Workers services (e.g., Workers Custom Domains or Routes feature); the closest evidence (cloudflare-docs-13) only describes SSL certificate issuance for domains added to Cloudflare generally, not domain-to-Worker binding. missing for 10: explicit docs on Workers Custom Domains/Routes setup, CLI/dashboard steps to bind a domain to a Worker, and any independent confirmation of this workflow.
- [claimed-docs] “Cloudflare issues — and renews — free, unshared, publicly trusted SSL certificates to all domains added to and activated on Cloudflare.”
Fly.ionone0/10The evidence pack contains no mention of custom domain attachment, certificate management, or DNS configuration (e.g., no reference to `fly certs add` or similar). While Fly.io is a PaaS where this axis clearly applies, no documentation or community evidence in the pack demonstrates this capability.
developerProgrammatically provision and route custom domains for my own multi-tenant SaaS customers
weight 2 · round drawnCloudflare Workersnone0/10The evidence pack shows general Workers platform capabilities (deployment, bindings, API tokens, SSL certs) but contains no mention of Cloudflare for SaaS, custom hostnames API, or Workers for Platforms — the specific mechanisms for programmatically provisioning and routing custom domains on behalf of multi-tenant SaaS customers.
Fly.ionone0/10The evidence pack contains no mention of Fly.io's certificate/custom-domain APIs (e.g. `fly certs add`, automated TLS issuance, per-app domain routing) needed for multi-tenant SaaS customer domains — only general Machines/Apps provisioning and networking primitives are described. Missing for 10: any documentation of programmatic custom-domain/cert provisioning, per-tenant routing, or multi-tenant domain API, and any independent confirmation it works reliably.
Env isolation
devops-leadIsolate non-production environments from accessing production services
weight 1 · round drawnCloudflare Workersnone0/10Evidence covers general Workers features (deployment, bindings, Wrangler, API token scoping to specific zones) but nothing addresses environment-level isolation (e.g., separate staging vs production networks, service bindings restricted by environment, or network policies preventing non-prod from reaching prod services). No documentation or community evidence describes this capability.
Fly.ionone0/10The evidence covers Fly Machines, Sprites (AI-agent sandboxes with egress policies), and general platform features, but nothing addresses network segmentation or access control between staging/non-production and production environments for a devops team. Docs-11/12/13 describe org-wide service connectivity and per-Sprite access grants for agent workloads, not environment isolation for prod vs non-prod apps.
Identity
devops-leadSecure internal apps, deployments, and agents using my organization's identity provider
weight 2 · round to Cloudflare WorkersThe evidence only vaguely mentions that 'Zero Trust controls are built into the network' (docs-18), with no detail on integrating with an external IdP (SAML/OIDC), configuring SSO for internal apps, or securing deployed agents specifically. Missing for 10: explicit IdP/SSO integration docs, Access policy examples tied to identity providers, and evidence of securing agent/deployment pipelines with org identity.
- [claimed-docs] “DDoS protection, WAF, bot management, and Zero Trust controls are built into the network and run on every request from day one.”
Fly.ionone0/10No evidence of SSO/SAML/OIDC integration with an external identity provider for securing Fly apps, deployments, or agents. The pack mentions secrets vaults, WireGuard networking, and service-to-service credential rotation, but nothing about enterprise IdP-based authentication or access control.
Private networking
devops-leadKeep internal service-to-service traffic off the public internet without VPC complexity
weight 2 · round to Fly.ioCloudflare Workersnone0/10The evidence pack covers Bindings for connecting to external databases/APIs (docs-10) and generic Zero Trust/WAF network security (docs-18), but nothing documents a specific mechanism (e.g., private Worker-to-Worker service bindings or a documented private-network route) for keeping internal service-to-service calls off the public internet without VPC setup. No first-party or community evidence directly addresses this specific networking pattern.
Evidence hints at private networking (WireGuard checks via `fly doctor`, org-wide service connectivity and egress policies for Sprites) but never explicitly documents a general internal DNS/private network (e.g. 6PN/.internal) mechanism for ordinary Fly Apps talking to each other off the public internet. Missing for 10: explicit docs on private networking/internal DNS for app-to-app traffic, VPC-less peering details, and independent confirmation it works reliably at scale.
- [claimed-docs] “Run diagnostics: `fly doctor` — checks WireGuard, IPs, and Docker.”
- [claimed-docs] “Connect a service once for your whole org, and every Sprite can reach it. Nobody pastes a token.”
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
- [claimed-docs] “Run it in a hardware-isolated VM. A clean baseline per request, so no two users ever share state. Egress-locked and disposable.”
Protocols
developerServe HTTP, TCP, gRPC, and WebSocket traffic from the same deployed service without separate protocol configuration
weight 1 · round to Cloudflare WorkersEvidence confirms Workers serve HTTP (implicit in all docs) and WebSockets (docs-15 mentions hibernating WebSockets; comm-4 references WebSocket support), but there is no evidence of TCP or gRPC serving capability, nor any claim that all four protocols run from a single deployed service without separate configuration. missing for 10: TCP support, gRPC support, unified same-service multi-protocol configuration documentation.
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [community] “I've been watching Workers with interest basically since the beginning. Now they just need to bring WebSockets support out of beta.”
Fly.ionone0/10The evidence pack contains no documentation or community discussion describing Fly.io's ability to serve HTTP, TCP, gRPC, and WebSocket traffic from a single deployed service without separate protocol configuration; docs cover deployment, scaling, secrets, and Machines but not multi-protocol service configuration.
Tls certs
devops-leadGet free, automatically renewing TLS certificates for every domain including wildcards
weight 3 · round to Cloudflare WorkersCloudflare's docs confirm free, auto-issued and auto-renewed publicly trusted SSL certificates for all domains added to Cloudflare (Universal SSL), which would cover custom domains used with Workers. However, the evidence never explicitly confirms wildcard certificate coverage or independent/hands-on verification of renewal behavior. missing for 10: explicit wildcard-domain certificate confirmation, independent/hands-on corroboration of auto-renewal in practice.
- [claimed-docs] “Cloudflare issues — and renews — free, unshared, publicly trusted SSL certificates to all domains added to and activated on Cloudflare.”
Observability — seeing what the system is doing — logs, metrics, traces, alertsObservability
Seeing what the system is doing — logs, metrics, traces, alerts
Alerting
devops-leadSet up alerts that notify me via chat or email when specific conditions are met
weight 2 · round drawnCloudflare Workersnone0/10The pack shows Cloudflare Workers has 'built-in observability' (cloudflare-docs-22) but no evidence of configurable alerting rules that notify via chat/email when specific conditions are met. Missing for 10: alert rule configuration, notification channel integrations (Slack/email/PagerDuty), and any docs or community confirmation that such alerting exists for Workers.
- [claimed-docs] “Gain deep visibility and insight with built-in observability”
Metrics dashboards
devops-leadBuild custom dashboards combining metrics from any service
weight 2 · round to Cloudflare WorkersCloudflare only vaguely claims 'built-in observability' for Workers, but there is no evidence of a dashboarding capability that lets a devops-lead combine metrics from arbitrary/external services into custom views. Missing for 10: documented Analytics/GraphQL API for pulling metrics into external dashboards, named integrations with Grafana/Datadog/other observability tools, and any UI for building custom multi-service dashboards.
- [claimed-docs] “Gain deep visibility and insight with built-in observability”
Reliability sla
devops-leadCheck a public status page with historical incident postmortems before committing
weight 2 · round drawnCloudflare Workersnone0/10No evidence in the pack references a public status page, uptime history, or incident postmortems for Cloudflare Workers; the pack only covers product features, docs, and community opinions.
Fly.ionone0/10The evidence pack contains no vendor/docs-tier claim of a public status page with historical incident postmortems, and the only related mentions are community complaints that Fly's status page shows 'no incidents'/green even during real outages (fly-io-comm-3, fly-io-comm-6, fly-io-comm-9), which undercuts rather than confirms the existence of a trustworthy postmortem history. Since disputed requires a documented vendor claim contradicted by hands-on evidence from a distinct tier, and no such first-party claim is present here, this falls to 'none' rather than 'disputed'.
- [community] “As an aside, it's kind of a kick in the teeth to see the status page for our organization reporting no incidents - the same page that lists …”
- [community] “The worst thing about Fly is, when something goes wrong, it's not just one thing, there's bunch of things broken at the same time and their …”
- [community] “Fly response: 'We had a single host in the syd region go down, hard, with multiple issues... Ultimately it required a significant amount of …”
devops-leadReview a published uptime SLA with defined credits for downtime
weight 3 · round drawnCloudflare Workersnone0/10No evidence pack item references an SLA document, uptime guarantee, or service credit terms for Workers; documentation covers features, tooling, and pricing model but not a formal SLA.
devops-leadThe guaranteed support response times and escalation paths for my plan tier
weight 2 · round drawnCloudflare Workersnone0/10No evidence in the pack mentions SLA response times, support tiers, or escalation paths for Cloudflare Workers; the docs focus on product features, deployment, and dev workflows rather than support commitments.
Fly.ionone0/10No evidence of documented support-tier SLAs, guaranteed response times, or escalation paths for different plan tiers; docs only vaguely claim support is 'run by Fly.io engineers,' with no timing commitments. Community reports (fly-io-comm-4, -5, -7, -14) even describe unresponsive or non-existent support, but since no vendor claim of guaranteed SLAs exists to contradict, this is an unmet axis rather than a dispute.
- [claimed-docs] “Run by Fly.io engineers, not chat bots”
- [community] “Don't get me started with Fly — especially postgres machines. In my experience, a really nice idea with poor support and unreliable infrastr…”
- [community] “We tried to migrate all our staging environments to Fly last year but it was the flakiest experience I've experienced on any PaaS. Pushing s…”
- [community] “I really want to love Fly.io... but to be honest I don't think anyone should be building mission critical applications on their service. I e…”
- [community] “Does it have basic functioning other stuff? I am shocked at how our production usage of Fly has gone. Even basic stuff as support not being …”
Unified logging
developerView all my build, deploy, and runtime logs in one place
weight 3 · round to Cloudflare WorkersDocs mention built-in observability ("Gain deep visibility and insight with built-in observability") and rollback tracking of deployments, implying some runtime and deploy visibility, but there is no explicit evidence of a unified dashboard combining build logs, deploy logs, and runtime logs in one place. Missing for 10: explicit documentation of a consolidated logs view spanning build, deploy, and runtime stages, and independent confirmation of this unified experience.
- [claimed-docs] “Gain deep visibility and insight with built-in observability”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
Fly.ionone0/10The evidence pack contains no documentation or mention of a unified logging view for build, deploy, and runtime logs (e.g., no reference to `fly logs`, log streaming, or a logs dashboard). Community evidence even suggests logging/observability gaps ('Fly reports everything healthy, and there's literally no information'), but this doesn't confirm or deny a unified log feature — it's simply absent from the pack.
- [community] “This is the second time I've had this kind of issue with Fly, where my service just goes down, Fly reports everything healthy, and there's l…”
- [community] “The worst thing about Fly is, when something goes wrong, it's not just one thing, there's bunch of things broken at the same time and their …”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnCloudflare exposes a full REST API (confirmed via live openapi.json spec) and a CLI (Wrangler) that mirrors dashboard actions like deploying, rolling back, and managing Workers, plus fine-grained API token scoping — all pointing to strong API/UI parity. However, no evidence explicitly confirms 100% feature parity between the dashboard and API/CLI, and some community comments note friction with certain platform features (e.g., runtime limits) that could imply UI-only nuances. Missing for 10: explicit parity documentation or changelog confirming every dashboard feature has an API equivalent, and independent verification of parity gaps.
- [probe] “PROBE openapi: HTTP 200 at https://developers.cloudflare.com/openapi.json — contains "openapi" key”
- [claimed-docs] “Wrangler offers a number of commands to manage your Cloudflare Workers.”
- [claimed-docs] “The core Wrangler commands for creating, developing, and deploying Workers are on the Workers commands page.”
- [claimed-docs] “You can roll back to a previously deployed version of your Worker using Wrangler or the Cloudflare dashboard.”
- [claimed-docs] “Select which resources the token is authorized to access.”
- [claimed-docs] “granting Zone DNS Read access to a zone example.com will allow the token to read DNS records only for that specific zone”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
Fly.io documents a Machines REST API that can provision and manage Apps, Machines, and Volumes (fly-io-docs-31, fly-io-docs-18), and flyctl itself is built atop this API, suggesting broad API/CLI-UI parity typical of Fly's API-first design. However, no evidence explicitly confirms full feature parity with the web dashboard, and a probe found no discoverable OpenAPI spec (fly-io-probe-3), making it hard to verify completeness. Missing for 10: explicit parity claim/doc mapping UI features to API endpoints, published OpenAPI/swagger spec, and confirmation that dashboard-only features (billing UI, status page, etc.) are also API-accessible.
- [claimed-docs] “The Fly Machines REST API provides resources to provision and manage Fly Apps, Fly Machines, and Fly Volumes.”
- [claimed-docs] “Fly Machines are fast-launching VMs with a simple REST API.”
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
- [probe] “official CLI documented at https://fly.io/docs/flyctl/”
ai-native userExport all of my data in open formats and leave
weight 3 · round to Cloudflare WorkersCloudflare Workersdisputedcontradicted3/10Cloudflare claims workflows are open and free of vendor lock-in ('No proprietary tools or vendor lock-in' - cloudflare-docs-17), but hands-on community feedback specifically contradicts this for data services, calling out that KV, D1, etc. are 'locked-in things' that make it hard to switch or run the same code elsewhere (cloudflare-comm-10). There is no documented data-export tool, open-format export command, or migration guide for leaving the platform with your data. Missing for 10: any first-party data-export/migration documentation for D1/KV/R2, evidence of open-format export capability, and resolution of the lock-in complaint.
- [claimed-docs] “Fits into your existing workflows: Git, GitHub Actions, VS Code, and any framework. No proprietary tools or vendor lock-in.”
- [community] “Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. ... being able to run the same code on your own …”
ai-native userRead the product's source under an open license
weight 2 · round to Cloudflare WorkersCloudflare open-sources parts of its developer tooling (workers-sdk CLI, and references to the workerd runtime) on GitHub, but the evidence never states a license or confirms the entire Workers platform/runtime is open-source — the core edge service remains closed. Missing for 10: explicit license text, confirmation that the full production runtime (not just CLI/simulator) is open, and independent confirmation of open-source status beyond repo existence.
- [github] “A simulator for developing and testing Cloudflare Workers, powered by workerd”
- [github] “A command line tool for building [Cloudflare Workers](https://workers.cloudflare.com/).”
- [github] “A simulator for developing and testing Cloudflare Workers, powered by [workerd](https://github.com/cloudflare/workerd)”
Fly.ionone0/10Fly.io is a proprietary cloud platform; the evidence pack contains no mention of an open-source license or public source repository for the core platform (flyctl is open source per outside knowledge, but no evidence here confirms this), and no docs claim open-source availability of the product's source.
ai-native userSelf-host the core product
weight 3 · round drawnCloudflare Workersnone0/10Cloudflare Workers is presented throughout the evidence as a proprietary hosted platform running on Cloudflare's global network (docs-1, docs-19); there is no evidence of an official self-hosted distribution of the full Workers platform. Community comments explicitly note lock-in and desire to 'run the same code on your own stuff or a small VPS' as an unmet want (cloudflare-comm-10, cloudflare-comm-9), confirming self-hosting the core product is not currently offered.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
- [community] “Cloudflare's cool, but those locked-in things (KV, D1, etc.) always made it hard to switch. ... being able to run the same code on your own …”
Fly.ionone0/10Fly.io is presented purely as a managed public cloud (flyctl + fly launch, hosted Sprites/Machines, hosted secrets, hosted networking) with no evidence anywhere of an open-source or self-hostable core product; all docs and probes describe a proprietary hosted service.
- [claimed-docs] “**Step 1:** Install `flyctl` ... **Step 2:** Run `fly launch`”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
- [probe] “PROBE llms.txt: HTTP 200 at https://fly.io/llms.txt # Fly.io Documentation > Fly.io is a global public cloud for running full-stack and AI …”
- [probe] “PROBE openapi: all candidate paths 404 (https://fly.io/openapi.json, https://fly.io/swagger.json, https://fly.io/api/openapi.json, https://f…”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Cost controls
devops-leadSet hard spending limits to control my cloud costs
weight 2 · round drawnCloudflare Workersnone0/10No evidence pack item describes hard spending limits or budget caps for Workers usage; the only pricing-related note explains billing model (compute-only charges) but not spend-limiting controls.
devops-leadReceive migration credits when moving my production infrastructure to a new platform
weight 1 · round drawnCloudflare Workersnone0/10No evidence anywhere in the pack mentions migration credits, competitive-switch incentives, or financial credits for moving workloads to Cloudflare Workers; pricing/lock-in discussion is limited to community complaints about vendor lock-in and CPU-time limits.
Execution limits
devops-leadThe CPU and wall-clock execution time limits for functions so I can tell whether long-running or agentic workloads will fit
weight 3 · round to Cloudflare WorkersCloudflare Workersdisputedcontradicted6/10Community evidence gives concrete numbers (30s CPU on free tier, 15min on paid plans) and explicitly states these limits 'don't work for long-running agent tasks' (cloudflare-comm-9), directly contradicting Cloudflare's own marketing that Workers can 'build agents' and run 'long agent workflows' (cloudflare-docs-3, cloudflare-docs-15). The evidence pack itself never surfaces official documented CPU/wall-clock limit tables, so a devops-lead must rely on secondhand community reports rather than clear first-party limit docs. missing for 10: first-party docs page enumerating exact CPU-time/wall-clock limits per plan, and independent benchmarking confirming or refuting the 30s/15min figures for real agentic workloads.
- [community] “Self-hosted workers are becoming critical infrastructure for AI agent workloads... The 30s CPU time on the free tier and even the 15min on p…”
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
Fly.ionone0/10Fly.io's evidence pack markets Machines/Sprites explicitly for long-running and agentic workloads (e.g., fly-io-docs-4, fly-io-docs-5, fly-io-docs-28) but never states any CPU or wall-clock execution time limit — Fly Machines are persistent VMs, not time-boxed functions, and no documentation here quantifies compute/runtime ceilings a devops-lead could compare against. Missing for 10: any documented CPU quota, timeout, or wall-clock limit per Machine/Sprite invocation, and any comparison table or pricing-limits doc addressing execution duration.
- [claimed-docs] “Every agent gets its own Linux box. A Sprite checkpoints itself while the agent works, so harnesses like Claude and Codex find everything wh…”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
- [claimed-docs] “Give your agent a real computer and get back to building.”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
Overage fees
devops-leadThe exact overage fee schedule for exceeding plan usage limits (bandwidth, invocations, build minutes) before I get billed
weight 3 · round drawnCloudflare Workersnone0/10No evidence pack item documents overage fee schedules for exceeding bandwidth, invocations, or build-minute limits; only general pricing philosophy ('charges only for compute') is mentioned without any fee schedule detail.
Fly.ionone0/10Evidence shows only generic pay-as-you-go pricing claims (compute/storage/bandwidth billed by usage) but no documented overage fee schedule, no specifics on invocation or build-minute overage costs, and no billing rate table. There is also community commentary calling billing UI 'cobbled together' but nothing detailing exact overage fees.
- [claimed-docs] “Unlike Heroku's dyno-based tiers, Fly.io uses pay-as-you-go pricing - you only pay for the compute, storage, and bandwidth you actually use.”
- [community] “My experience with Fly.io has not been a good one... Following their guide you get postgres not spinning up and linking to your app correctl…”
devops-leadWhether pricing is per-seat with minimum seat counts that increase cost as my team grows
weight 2 · round drawnCloudflare Workersnone0/10Evidence shows Cloudflare Workers pricing is usage/compute-based ('Cloudflare charges only for compute, not wall time') rather than per-seat, and no documentation or community evidence mentions seat-based pricing tiers or per-seat minimums that scale with team size. Missing for 10: any pricing page, seat-count minimums, or per-user cost documentation.
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
Fly.ionone0/10Fly.io's pricing is explicitly usage-based (pay-as-you-go for compute/storage/bandwidth), not per-seat, and no evidence mentions seat counts or minimums; missing for 10: any pricing page or docs referencing seat-based billing or per-user minimums since the model is consumption-based, not applicable in the seat-pricing sense the story asks about.
- [claimed-docs] “Unlike Heroku's dyno-based tiers, Fly.io uses pay-as-you-go pricing - you only pay for the compute, storage, and bandwidth you actually use.”
Usage billing
devops-leadPay only for active compute time rather than idle wall-clock time
weight 2 · round to Cloudflare WorkersCloudflare explicitly documents billing only for active CPU/compute time rather than wall-clock time, even for long-running agent workflows or hibernating WebSockets, aligning directly with the devops-lead pricing story. missing for 10: independent third-party billing analysis or hands-on cost comparison corroborating the claim beyond vendor docs.
- [claimed-docs] “Cloudflare charges only for compute, not wall time, even during long agent workflows or hibernating WebSockets.”
Fly.io's docs describe pay-as-you-go pricing tied to actual compute/storage/bandwidth usage rather than fixed dyno-tier billing, plus machines that sleep/suspend when idle and only bill for active compute (e.g., 'Pay only for the tool calls you use', disk billed only for bytes used, Sprites that 'sleep until needed'). This directly matches the devops-lead story of paying for active time, not idle wall-clock. missing for 10: explicit per-second billing granularity documentation, and independent/third-party confirmation that idle machines are not billed.
- [claimed-docs] “Unlike Heroku's dyno-based tiers, Fly.io uses pay-as-you-go pricing - you only pay for the compute, storage, and bandwidth you actually use.”
- [claimed-docs] “Your disk grows as you write it, up to 100 GB per Sprite, and you're only billed for the bytes you actually put there.”
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
- [claimed-docs] “Give it a Sprite that sleeps until it's needed and wakes up remembering everything.”
- [claimed-docs] “Fly Machines are hardware-isolated VMs that boot in under a second, run close to your users, and scale out to tens of thousands when the tra…”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to Fly.ioCloudflare Workersnone0/10The evidence pack covers Workers' global deployment, latency optimization (Smart Placement), and general platform features, but contains no mention of data residency, regional storage selection, or jurisdictional controls for where data is stored. Missing for 10: any documentation of region-pinning, data localization suite, or jurisdiction restrictions for storage products (D1, KV, R2).
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Smart Placement moves your Worker closer to your data for optimized end-to-end latency.”
Fly.io documents global region deployment allowing users to place apps/data near specific regions (e.g. Tokyo, São Paulo, Amsterdam) via its Anycast network, which supports choosing where compute/data runs. However, there's no explicit documentation of data residency guarantees, compliance certifications, or region-locking specifically for data storage/backups (e.g. Postgres/volumes pinned to a region for residency purposes) rather than just latency-driven deployment. Missing for 10: explicit data residency/compliance documentation, volume/database region-pinning guarantees, independent verification of residency enforcement.
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [claimed-docs] “Fly.io makes it easier to run an Elixir cluster on multiple servers around the world and deploy to those regions with a single command.”
ai-native userControl data retention and deletion
weight 2 · round drawnCloudflare Workersnone0/10No evidence in the pack addresses data retention policies, deletion controls, or privacy/data lifecycle management for data stored via Workers, KV, D1, R2, or related services; evidence covers deployment, tooling, pricing, and general dev experience but nothing about retention/deletion controls.
Fly.ionone0/10The evidence pack contains no documentation of data retention policies, deletion tooling, or export/erasure controls for Fly.io's platform. The only relevant community evidence (fly-io-comm-8) describes a user whose account-deletion request was ignored, further indicating no working deletion mechanism was demonstrated.
- [community] “They had my account on some sort of shadow ban with no communication whatsoever after asking them to delete my account from their systems. I…”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnCloudflare Workersnone0/10No evidence in the pack addresses telemetry opt-out or usage-tracking controls for Cloudflare Workers or Wrangler CLI; this is a plausible axis for a developer platform/CLI but no documentation or community report confirms such a setting exists.
Storage data — storing and moving data — persistence, formats, durabilityStorage data
Storing and moving data — persistence, formats, durability
Cdn assets
developerServe static assets faster using a global CDN with edge caching
weight 2 · round to Cloudflare WorkersEvidence confirms Workers run on Cloudflare's global edge network and one community comment notes using 'CF Pages for static sites with great results,' implying edge-hosted static content, but the pack has no first-party documentation of Workers' static-assets feature, cache API, or edge-caching configuration specifics for static files. Missing for 10: explicit docs on Workers Static Assets/Cache API, cache-control/edge-caching configuration details, and performance benchmarks for static asset delivery via Workers.
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage. No cold starts or region com…”
- [claimed-docs] “Build and deploy serverless functions and full-stack apps on Cloudflare's global network. No servers to manage.”
- [community] “I've used CF Pages for static sites with great results and am intrigued by all their open-source-LLM-as-a-service offerings. Main issue prev…”
Fly.ionone0/10Evidence shows Fly.io provides global compute deployment across regions via Anycast (fly-io-docs-20) and fast-booting VMs, but there is no mention of a CDN, edge caching, or static asset acceleration feature anywhere in the pack.
- [claimed-docs] “You can deploy apps in regions worldwide, so your users in Tokyo, São Paulo, or Amsterdam connect to the nearest server through our global A…”
Integrations
developerConnect my code to external services like databases, APIs, and storage through native bindings with minimal boilerplate instead of hand-wiring SDKs and credentials
weight 2 · round to Cloudflare WorkersCloudflare's own docs explicitly describe Bindings as the mechanism to 'connect to external services like databases, APIs, and storage... with just a few lines of code,' directly matching the story, and this is reinforced by docs on D1/KV requiring 'no connection management.' Community reports (HN) corroborate ease of connecting to KV/D1 storage from Workers in production with minimal setup. Missing for 10: deeper technical documentation of the full range of binding types (R2, Queues, Durable Objects, Vectorize) and more independent hands-on reviews specifically praising the boilerplate reduction versus manual SDK wiring.
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [claimed-docs] “Serverless SQL, globally distributed key-value, and global database acceleration — query directly from Workers with no connection management…”
- [claimed-docs] “Build APIs and connect to data stores with Smart Placement to optimize latency”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
- [community] “I've played with JS workers on a Cloudflare-fronted site and found them to be easy to use and very quick. Would love to port the whole Djang…”
Fly.io offers secrets management (fly-io-docs-23), org-wide service connections without manual token-pasting (fly-io-docs-11, fly-io-docs-12, fly-io-docs-13), and its own Managed Postgres (fly-io-docs-19), which reduce some credential-wiring boilerplate. However, these are infrastructure-level networking/secrets primitives rather than native code-level bindings/SDKs for external databases, third-party APIs, or storage services akin to Workers-style bindings. Missing for 10: explicit SDK/binding integrations for common third-party services (e.g., S3, Stripe, external APIs), documentation showing reduced application code boilerplate, and independent corroboration that this actually simplifies service wiring in practice.
- [claimed-docs] “Connect a service once for your whole org, and every Sprite can reach it. Nobody pastes a token.”
- [claimed-docs] “Grant access on purpose: by Sprite name, by label, or down to a single endpoint, so a Slack bot can post messages and never touch admin.”
- [claimed-docs] “Rotate once and every Sprite has the new credential. Cut off a single Sprite and the rest never notice.”
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [claimed-docs] “Secrets allow sensitive values, such as credentials, to be passed securely to your Fly App. The secret is encrypted and stored in a vault.”
Kv cache
developerUse a Redis-compatible key-value store for low-latency caching and job queues
weight 2 · round drawnCloudflare Workersnone0/10Evidence confirms Cloudflare offers a 'globally distributed key-value' store (cloudflare-docs-4) and a separate Queues service (cloudflare-docs-9), and community mentions 'KV storage' (cloudflare-comm-3), but nothing indicates Workers KV is Redis-protocol-compatible or usable as a Redis substitute for caching/job-queue patterns. Missing for 10: any claim or documentation of Redis API/protocol compatibility, benchmarks showing low-latency Redis-like semantics, or job-queue patterns built directly on the KV store.
- [claimed-docs] “Serverless SQL, globally distributed key-value, and global database acceleration — query directly from Workers with no connection management…”
- [claimed-docs] “Schedule cron jobs, run durable Workflows, and integrate with Queues”
- [community] “Workers are so damn good and easy… I am originally from the PHP/Laravel world... decided to give CF workers & KV storage a try. In an hour t…”
Fly.ionone0/10The evidence pack contains no mention of Redis, Upstash, or any managed key-value/caching service offered by Fly.io; only generic Machines, Postgres, and Sprite-related docs are present. Missing for 10: any documentation or claim of a Redis-compatible store, caching service, or job-queue integration.
Object storage
developerPersist user-generated uploads using built-in object storage
weight 2 · round to Cloudflare WorkersThe pack shows Cloudflare Images as a first-party service for storing/delivering media (cloudflare-docs-5) and generic 'storage' bindings (cloudflare-docs-10), suggesting Workers can persist uploads via a built-in storage binding, but there is no explicit mention of a general object-storage product (e.g. R2), upload APIs, size limits, or hands-on developer confirmation of using it for arbitrary user uploads. Missing for 10: explicit object-storage product docs (R2 or equivalent), upload flow/API examples, and independent/community confirmation of real-world use for user-generated uploads.
- [claimed-docs] “Cloudflare Images helps teams build scalable, reliable media pipelines to store, optimize, and deliver images.”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
Fly.ionone0/10Evidence shows Fly.io offers persistent disks/volumes per Machine (fly-io-docs-10) but no built-in object storage service; a community report explicitly states Fly lacks an S3-equivalent and users had to leave Fly to store user assets (fly-io-comm-13), confirming absence of this capability.
- [claimed-docs] “Your disk grows as you write it, up to 100 GB per Sprite, and you're only billed for the bytes you actually put there.”
- [community] “About Fly but not about the GPU announcement, I wish they had a S3 replacement, they suggest a GNU Affero project that is a dealbreaker for …”
Relational db
developerProvision a fully-managed Postgres database with point-in-time recovery, replicas, and high availability
weight 3 · round to Fly.ioCloudflare Workersnone0/10Evidence shows Cloudflare's data offerings are serverless SQL (D1, SQLite-based), KV, and Hyperdrive for accelerating connections to external databases, not a fully-managed Postgres service with point-in-time recovery, replicas, and HA. No citation mentions Postgres provisioning, PITR, replication, or HA guarantees. missing for 10: any mention of a managed Postgres offering, PITR support, read replicas, or HA configuration.
- [claimed-docs] “Serverless SQL, globally distributed key-value, and global database acceleration — query directly from Workers with no connection management…”
Fly.iodisputedcontradicted3/10Fly.io docs mention a 'fully-managed Postgres' service (Managed Postgres) but provide no detail on point-in-time recovery, replica configuration, or HA topology in the evidence pack. Community reports concretely contradict reliability of Postgres on Fly, including databases going down with no info (fly-io-comm-2), explicit complaints about 'postgres machines' unreliability (fly-io-comm-4), and Postgres failing to spin up/link during setup (fly-io-comm-18). missing for 10: explicit documentation of PITR, replica setup, HA failover mechanics, and independent confirmation these work as advertised.
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
- [community] “We had four machines (app + Postgres for staging and production) running yesterday, and three of the four (including both databases) are sti…”
- [community] “Don't get me started with Fly — especially postgres machines. In my experience, a really nice idea with poor support and unreliable infrastr…”
- [community] “My experience with Fly.io has not been a good one... Following their guide you get postgres not spinning up and linking to your app correctl…”
developerQuery a serverless SQL database directly from my code with no connection management
weight 2 · round to Cloudflare WorkersCloudflare docs explicitly state D1 (serverless SQL) can be queried directly from Workers with no connection management, backed by bindings that eliminate manual pooling/connection setup, and community evidence corroborates developers using D1 in production Workers apps. missing for 10: independent hands-on benchmarking of connection behavior at scale and more detail on D1 driver/ORM specifics beyond marketing docs.
- [claimed-docs] “Serverless SQL, globally distributed key-value, and global database acceleration — query directly from Workers with no connection management…”
- [claimed-docs] “Connect to external services like databases, APIs, and storage via Bindings, enabling functionality with just a few lines of code”
- [community] “I've played with JS workers on a Cloudflare-fronted site and found them to be easy to use and very quick. Would love to port the whole Djang…”
Fly.ionone0/10Fly.io offers Managed Postgres, a fully-managed traditional PostgreSQL service (fly-io-docs-19), but there's no evidence of a serverless SQL query interface with no connection management (e.g., HTTP-based query API like Neon's serverless driver); Postgres still requires standard connection handling.
- [claimed-docs] “Fly.io's Managed Postgres is our fully-managed database service that handles all aspects of running production PostgreSQL databases”
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableCloudflare Workersn/aCloudflare Workers is a serverless compute/deployment platform, not an AI agent or assistant that itself consumes external tools; the evidence only shows it lets developers build and deploy MCP *servers* (cloudflare-docs-12), which is the opposite role (server, not client). There's no product-level 'agent' inside Workers that plugs in MCP servers to use their tools, so this client-consumption story is a category mismatch for this kind of product.
- [claimed-docs] “You can build and deploy Model Context Protocol (MCP) servers on Cloudflare.”
Fly.ion/aFly.io is a cloud infrastructure/hosting platform, not an AI agent or assistant that itself consumes tools; the evidence shows Fly.io as infrastructure for *running* MCP servers (docs-6, docs-17) or *exposing* an MCP server via flyctl (docs-29), not as a client that plugs in MCP servers to gain tool-use capabilities. This story's axis (product acting as an MCP client) doesn't apply to a compute/hosting platform.
- [claimed-docs] “Run every MCP server in its own Sprite, with persistent disk, and egress policy. Pay only for the tool calls you use.”
- [claimed-docs] “Fly Machines are tightly isolated VMs that are perfect for running MCP servers.”
- [claimed-docs] “[experimental] Start a flyctl MCP server”
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableCloudflare Workersnone0/10Cloudflare Workers offers Workers AI for building AI agents/inference into apps (cloudflare-docs-3) and built-in observability (cloudflare-docs-22), but there is no evidence of the platform itself surfacing AI-generated insights or suggestions from a user's own data within a Cloudflare product interface (e.g., analytics dashboard insights).
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
- [claimed-docs] “Gain deep visibility and insight with built-in observability”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableCloudflare Workersnone0/10Cloudflare Workers documentation describes building AI inference/agents as capabilities you can deploy (cloudflare-docs-3, cloudflare-docs-12), but there is no evidence of a built-in AI assistant embedded in the Workers product/dashboard itself that a user can delegate tasks to.
Fly.ion/aFly.io is an infrastructure/PaaS platform for hosting apps and agent sandboxes (Sprites, Machines); it has no built-in AI assistant that end-users delegate tasks to inside the product itself. This axis is a category error for a cloud infra provider, not a gap in an AI-product feature set.
developerUse an in-browser toolbar to leave feedback, manage feature flags, and inspect performance directly on my live site
weight 1 · not comparableCloudflare Workersn/aAn in-browser toolbar for feedback, feature flags, and live performance inspection is a specific product feature (like Vercel Toolbar) unrelated to Cloudflare Workers' role as a serverless compute platform; this axis is a category error for this product type.
developerLet teammates and collaborators comment directly on preview and production environments
weight 1 · not comparableCloudflare Workersn/aCloudflare Workers is a serverless compute/edge platform; collaborative commenting on preview/production deployments is a category error for this kind of infrastructure product, not a capability buyers evaluating Workers would expect.
devops-leadVisualize and edit my entire infrastructure stack on a visual canvas without writing config files
weight 2 · not comparableCloudflare Workersn/aCloudflare Workers is a code-first serverless platform (Wrangler CLI, JS/TS/Python/Rust runtimes) with no visual canvas or no-code infrastructure editor evidenced anywhere in the pack; this axis is a category mismatch for this product type.
ai-native builderAccess hundreds of AI models through a single unified gateway endpoint
weight 3 · not comparableCloudflare docs mention running AI inference 'globally with one API call' (Workers AI), but there is no evidence naming an AI Gateway product, a unified endpoint spec, or support for 'hundreds' of models from multiple providers. Missing for 10: explicit AI Gateway/unified endpoint documentation, list of supported model providers/count, and independent confirmation of breadth of model access.
- [claimed-docs] “Run AI inference globally with one API call, build agents, and search across your data — no GPUs to manage, no capacity planning.”
developerProtect my app from automated bot traffic with invisible challenge-based protection
weight 1 · not comparableCloudflare's platform docs state that bot management and WAF are 'built into the network and run on every request from day one,' implying Workers apps inherit these protections, but there is no detail on invisible challenge mechanics (e.g., Turnstile) or Workers-specific configuration, and no independent corroboration in the evidence pack. missing for 10: specifics on invisible/challenge-based bot protection mechanics, Workers-specific setup docs, and hands-on/independent verification.
- [claimed-docs] “DDoS protection, WAF, bot management, and Zero Trust controls are built into the network and run on every request from day one.”
devops-leadTrack site performance and visitor behavior with built-in analytics
weight 1 · not comparableDocs mention Cloudflare Workers ships with 'built-in observability' for deep visibility and insight, which touches the observability theme, but there is no evidence of visitor-behavior tracking, traffic/analytics dashboards, or performance metrics presented to a devops-lead. Missing for 10: dedicated analytics/dashboard evidence, visitor behavior metrics (page views, referrers, geo), and independent confirmation of the observability feature's depth.
- [claimed-docs] “Gain deep visibility and insight with built-in observability”
devops-leadAttached disk/storage auto-grows with usage and I'm billed only for bytes actually written rather than pre-provisioned capacity
weight 2 · not comparableCloudflare Workersn/aWorkers is a serverless compute platform with no attached-disk concept; storage needs are met via separate bound services (R2, D1, KV) rather than a growing disk volume, so this pricing axis doesn't map onto Workers itself.
Fly.io's own docs explicitly state disk auto-grows with usage up to 100GB per Sprite and billing is only for bytes actually written, matching the story precisely, and general pay-as-you-go storage pricing is reiterated elsewhere. Missing for 10: independent/hands-on verification of this billing behavior, clarity on whether it applies to standard Fly Volumes beyond the newer 'Sprites' product, and confirmation of no minimum/rounding charges.
- [claimed-docs] “Your disk grows as you write it, up to 100 GB per Sprite, and you're only billed for the bytes you actually put there.”
- [claimed-docs] “Unlike Heroku's dyno-based tiers, Fly.io uses pay-as-you-go pricing - you only pay for the compute, storage, and bandwidth you actually use.”
ai-native userPrevent my data from being used to train AI models
weight 3 · not comparableCloudflare Workersn/aCloudflare Workers is a compute/serverless platform, not an AI model provider or data-training controller; there is no evidence about training-data opt-out policies since this is not the relevant axis for a serverless execution platform.
developerResize and optimize images on demand via a built-in image CDN
weight 1 · not comparableCloudflare Images is documented as a product for storing, optimizing, and delivering images, which could be integrated with Workers, but the evidence pack gives only a one-line description with no detail on on-demand resize/transform APIs, integration specifics with Workers, or hands-on confirmation. Missing for 10: detailed docs on image transformation/resize parameters, explicit Workers integration examples, and independent/community corroboration of the image CDN working as claimed.
- [claimed-docs] “Cloudflare Images helps teams build scalable, reliable media pipelines to store, optimize, and deliver images.”