Vercel vs Fly.io
Vercel wins · 40–18 (26 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 VercelDirect probe evidence confirms Vercel serves a live llms.txt at vercel.com/llms.txt (HTTP 200) with a machine-readable product summary, plus a full docs.md markdown mirror of documentation, both explicitly agent-oriented formats. Missing for 10: independent third-party confirmation that agents actually consume and act on these files effectively.
- [probe] “PROBE llms.txt: HTTP 200 at https://vercel.com/llms.txt # Vercel > Vercel is a cloud platform for building, deploying, and scaling web appl…”
- [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs.md --- title: index product: vercel url: /docs/index canonical_url: "https://vercel.com/d…”
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 VercelVercel ships an official CLI (vercel-docs-4/vercel-gh-1, vercel-probe-4, vercel-gh-2) that supports git push-based and CLI-driven deploys usable in CI pipelines, plus REST/OpenAPI API access (vercel-probe-3) for scripted automation, and CI-friendly features like environment variable management and rollback/promote commands (vercel-docs-23, vercel-docs-29). Missing for 10: no explicit GitHub Actions/CI recipe documentation or independent hands-on report of running the CLI fully headlessly in a third-party CI system.
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [github] “To opt into the native binary and replace existing global vercel and vc commands, install the native package explicitly”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [claimed-docs] “Revert production to a previous deployment without a rebuild when something breaks.”
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 drawnVercel's docs mention agent-facing capabilities like 'Create tools for AI agents to interact with your systems' and 'Allow AI agents to deploy a project and let a human take over,' plus agent skill/slash-command support for coding agents (Claude Code, Cursor, etc.), suggesting some official agent-integration surface. However, none of the evidence explicitly names an MCP server, MCP protocol support, or an MCP endpoint. Missing for 10: explicit documentation of an official MCP server/endpoint, MCP protocol naming, or third-party confirmation that agents connect via MCP rather than generic APIs/CLI.
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
- [claimed-docs] “Allow AI agents to deploy a project and let a human take over.”
- [claimed-docs] “Give your coding agent deployment skills, framework best practices, and slash commands. Works with Claude Code, OpenAI Codex, Grok Build, Cu…”
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 drawnVercel ships an official CLI (vercel-probe-4, vercel-gh-1, vercel-gh-2) and explicitly extends it toward AI-native agent workflows via deployment skills, framework best practices, and slash commands for coding agents like Claude Code, Cursor, and GitHub Copilot (vercel-docs-15), plus AI-agent deployment handoff features (vercel-docs-10). missing for 10: independent/hands-on verification of the CLI's agentic slash-command features beyond first-party docs.
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [github] “To opt into the native binary and replace existing global vercel and vc commands, install the native package explicitly”
- [claimed-docs] “Give your coding agent deployment skills, framework best practices, and slash commands. Works with Claude Code, OpenAI Codex, Grok Build, Cu…”
- [claimed-docs] “Allow AI agents to deploy a project and let a human take over.”
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 VercelVercel exposes a documented public OpenAPI spec (vercel-probe-3), an official CLI (vercel-probe-4, vercel-gh-2), and llms.txt/docs.md machine-readable docs (vercel-probe-1, vercel-probe-2), confirming a documented API surface AI-native users can drive programmatically. Additional docs describe AI-agent-oriented tool creation and agent deployment flows (vercel-docs-4, vercel-docs-10, vercel-docs-15). missing for 10: independent/hands-on third-party corroboration of API completeness and no explicit API versioning/rate-limit docs cited.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [probe] “PROBE llms.txt: HTTP 200 at https://vercel.com/llms.txt # Vercel > Vercel is a cloud platform for building, deploying, and scaling web appl…”
- [probe] “PROBE docs-md: HTTP 200 at https://vercel.com/docs.md --- title: index product: vercel url: /docs/index canonical_url: "https://vercel.com/d…”
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
- [claimed-docs] “Allow AI agents to deploy a project and let a human take over.”
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.ioVercel documents securing 'every internal agent, app, and deployment with your identity provider' (vercel-docs-13), implying some access-control mechanism for agents, but there is no concrete documentation of issuing scoped/least-privilege API tokens or credentials specifically for AI agents. Missing for 10: explicit scoped API token/credential creation flow for agents, granularity of permissions, and independent confirmation of least-privilege enforcement.
- [claimed-docs] “Secure every internal agent, app, and deployment with your identity provider.”
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
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 VercelVercel documents official SDKs like the AI SDK and Workflow SDK, an OpenAI-compatible endpoint, and an OpenAPI spec, giving AI-native builders concrete first-party SDK surfaces to build against. However, evidence is limited to doc summaries and a bare OpenAPI probe with no independent hands-on validation of SDK completeness or developer experience. missing for 10: independent/hands-on corroboration of SDK usage, deeper docs on SDK API surface/versioning, and confirmation of SDK stability beyond marketing copy.
- [claimed-docs] “Call hundreds of models through one endpoint with the AI SDK, any OpenAI-compatible SDK, or cURL, with budgets, fallbacks, and usage monitor…”
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
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 drawnVercelnone0/10No evidence pack item documents a webhooks subscription API or event-driven webhook feature; the closest is a Slack integration for deployment notifications, which is not a webhook mechanism for AI-native subscription. Missing for 10: any docs on a webhooks API, event types, subscription setup, or agent-facing usage of webhooks.
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 VercelVercel's Workflow SDK explicitly supports building 'durable, observable applications and AI agents' on a managed platform, and scheduled ISR regeneration ('on a schedule') shows some background automation capability, but there is no dedicated cron/scheduler product documentation or independent evidence of long-running autonomous agent automations in production. missing for 10: explicit cron/scheduled-job feature docs, evidence of persistent background agent execution beyond ISR, and independent/hands-on confirmation that Workflow SDK automations run unattended reliably.
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
- [claimed-docs] “Regenerate static pages on a schedule or on demand without rebuilding your whole site.”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
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 VercelVercel ships agent-facing 'skills' and slash commands so coding agents (Claude Code, Cursor, Copilot, etc.) can drive deployments and framework tasks via natural language, and allows AI agents to deploy projects and hand off to a human — evidence of AI-native operability rather than a full built-in NL interface. This relies on third-party coding agents/CLIs rather than a native conversational control surface for the whole platform (dashboard, env vars, domains, etc.). Missing for 10: evidence of a first-party natural-language interface covering the full product surface, and independent hands-on validation that these agent skills reliably execute complex operations.
- [claimed-docs] “Give your coding agent deployment skills, framework best practices, and slash commands. Works with Claude Code, OpenAI Codex, Grok Build, Cu…”
- [claimed-docs] “Allow AI agents to deploy a project and let a human take over.”
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
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 drawnVercelnone0/10Evidence confirms Vercel exposes a machine-readable OpenAPI spec (openapi.json) and standard docs pages, but nothing in the pack describes an interactive, in-browser API reference with runnable/try-it examples (e.g., a Swagger-style console). Missing for 10: evidence of an interactive API console, 'try it now' runnable request feature, or embedded code execution in the docs UI.
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 VercelA probe confirms Vercel publishes a machine-readable OpenAPI spec at vercel.com/openapi.json returning valid OpenAPI JSON, directly satisfying the story. Missing for 10: independent third-party corroboration or documentation describing spec versioning/coverage.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
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 Fly.ioVercel provides preview/deployment environments with separate environment variables (docs-1, docs-23, docs-27) and sandboxed ephemeral execution for untrusted/agent-generated code (docs-3, docs-17), which together support testing without touching production data. However, evidence doesn't explicitly confirm data isolation (e.g., separate databases per preview) beyond env var management, and community feedback notes friction connecting databases securely without enterprise plans (vercel-comm-11). missing for 10: explicit documentation of production-data isolation/masking in preview/sandbox environments, independent hands-on confirmation that sandbox testing never touches prod data.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Run untrusted code in secure, ephemeral execution environments.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 drawnVercelnone0/10There is an OpenAPI spec exposed (vercel-probe-3), showing an API exists, but no evidence of API versioning scheme or a documented deprecation policy anywhere in the pack. Nothing addresses version numbers, sunset timelines, or breaking-change communication practices.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
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 drawnVercelnone0/10The evidence pack describes general platform capabilities (Fluid compute for concurrency, Functions, CDN, etc.) but contains no documentation of specific rate limits, concurrency caps, or quota numbers that a developer could use for capacity planning. Community evidence also does not address this topic.
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 to Fly.ioVercelnone0/10While Vercel exposes a CLI and REST/OpenAPI API (vercel-probe-3, vercel-probe-4) that could theoretically be scripted for bulk actions, the evidence pack contains no documentation of a bulk/batch operation feature (e.g., bulk deploy, bulk env-var update, bulk domain management) that an AI-native user could invoke across many items at once.
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 VercelVercel supports several built-in event-triggered automations (deploy on git push, scheduled/on-demand ISR revalidation, middleware executing before requests, gradual/percentage rollouts, and a Workflow SDK for durable agent workflows), which are automatic actions tied to events. However, there is no evidence of a general user-configurable rules engine where an AI-native user can define arbitrary conditional 'if event X, then action Y' automations across the platform. Missing for 10: a documented rules/automation API or dashboard for custom event-trigger definitions, examples of user-defined conditional logic beyond fixed platform behaviors, and independent confirmation of such a feature working in practice.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Regenerate static pages on a schedule or on demand without rebuilding your whole site.”
- [claimed-docs] “Run code before a request completes to rewrite, redirect, or personalize responses.”
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
- [claimed-docs] “Send a new deployment to a percentage of traffic first, then promote it or roll back.”
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 VercelVercel docs mention regenerating content 'on a schedule' (ISR) and a Workflow SDK for building 'durable, observable applications and AI agents,' which together suggest some scheduled/automation capability, but neither explicitly describes a general-purpose cron/recurring-job scheduler for AI-native workflows. missing for 10: explicit dedicated cron/scheduled-jobs feature docs, examples of recurring AI workflow automation, and independent confirmation of scheduling reliability.
- [claimed-docs] “Regenerate static pages on a schedule or on demand without rebuilding your whole site.”
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
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 VercelVercel provides strong deployment-level version control, review, and rollback (git-based deploys, preview environments, comments, instant rollback, gradual rollout) and explicitly supports AI agents deploying with human takeover (vercel-docs-10), which maps well to versioning/reviewing/rolling back automations triggered by AI. However, evidence doesn't show version history, review, or rollback specifically for Workflow SDK-based agent workflows or tool-call automations themselves, only for deployments. Missing for 10: explicit versioning/rollback UI for AI agent workflows/tool executions (not just code deployments), independent corroboration of this specific AI-automation rollback flow.
- [claimed-docs] “Roll back to a previous deployment for swift recovery from production incidents.”
- [claimed-docs] “Revert production to a previous deployment without a rebuild when something breaks.”
- [claimed-docs] “Roll out new deployments in increments.”
- [claimed-docs] “Send a new deployment to a percentage of traffic first, then promote it or roll back.”
- [claimed-docs] “Let teams and invited collaborators comment on your preview and production environments.”
- [claimed-docs] “Allow AI agents to deploy a project and let a human take over.”
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
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 to Fly.ioVercel provides an official CLI (vercel deploy/vc) documented at vercel.com/docs/cli, and the GitHub README confirms users can get started via the CLI to deploy without importing through the dashboard. This directly supports CLI-based deployment as a core, well-documented workflow. Missing for 10: independent hands-on walkthrough of a full CLI deploy session and more detail on CLI command coverage beyond the docs link.
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [github] “To opt into the native binary and replace existing global vercel and vc commands, install the native package explicitly”
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 VercelThe official GitHub README explicitly describes getting started by importing a project, choosing a template, or using the Vercel CLI, then deploying with git push, and docs confirm a dedicated CLI (vercel-docs-cli) plus zero-config framework deployment (vercel-docs-14). This directly matches scaffold-and-deploy via a single CLI workflow, though the pack lacks a concrete example transcript of a single command producing a scaffolded+deployed app or independent hands-on confirmation. Missing for 10: an explicit worked example of a single CLI invocation (e.g., `vercel init` + `vercel deploy`) and independent/community verification of the scaffold step's simplicity.
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
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 drawnVercelnone0/10Evidence mentions the Vercel CLI and management of local/preview/production environments, but nothing in the pack claims a local simulator that matches the production runtime (e.g., serverless/edge function emulation). Missing for 10: explicit documentation of a local dev runtime (e.g., 'vercel dev') that mirrors production execution, and any hands-on confirmation of runtime parity.
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
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.ioVercelnone0/10Vercel's evidence focuses on Git-push deploys, framework support (Next.js/40+ frameworks), functions, and isolated 'container' sandboxes for running untrusted code—none of this describes deploying a developer-supplied Docker image/Dockerfile as the deployment artifact. There is no documentation of Docker container deployment as a supported workflow.
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 to VercelVercel's docs explicitly describe incremental rollout with percentage-based traffic splitting and promote/rollback controls (vercel-docs-6, vercel-docs-28), plus instant rollback for recovery (vercel-docs-5, vercel-docs-29), directly matching the story of reducing blast radius via incremental deploys. Missing for 10: independent/hands-on corroboration of gradual rollout behavior in practice, and no detail on automated rollout policies (e.g., canary analysis or auto-rollback thresholds).
- [claimed-docs] “Roll out new deployments in increments.”
- [claimed-docs] “Send a new deployment to a percentage of traffic first, then promote it or roll back.”
- [claimed-docs] “Roll back to a previous deployment for swift recovery from production incidents.”
- [claimed-docs] “Revert production to a previous deployment without a rebuild when something breaks.”
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 VercelVercel's core value proposition is Git-push deployment: docs explicitly state connecting GitHub/GitLab/Bitbucket triggers automatic deploys with preview URLs per branch, and the official GitHub README confirms the 'git push to deploy' workflow. This is corroborated by both first-party docs and the GitHub repo. Missing for 10: independent hands-on verification beyond vendor docs/GitHub description.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 VercelVercel's docs and GitHub repo describe connecting a Git repo (GitHub/GitLab/Bitbucket) to auto-deploy on push with preview URLs, plus zero-config deployment for Next.js and 40+ frameworks, directly matching the story. This is corroborated by both docs and the official GitHub README describing the 'git push to deploy' flow. Missing for 10: independent hands-on verification beyond vendor docs/README confirming zero manual config in practice.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 to Fly.ioVercelnone0/10No evidence pack item describes a single configuration file (e.g., vercel.json or IaC-style manifest) that defines and versions an entire architecture; docs mention environment variable management, CLI deploys, and marketplace integrations but nothing about unified architecture-as-code.
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 drawnEvidence confirms Vercel has a CLI (vercel-probe-4, vercel-gh-1) that can be used as an alternative to Git-based deploys, and preview/production URLs can be locked down via authentication or passwords (vercel-docs-26), which supports the 'private until published' part of the story. However, no evidence explicitly describes a folder-upload (no-Git) deploy flow or confirms new deployments are private-by-default. Missing for 10: explicit documentation of a drag-and-drop or CLI folder-upload deploy without any Git repo, and confirmation that such deployments default to private/unpublished state.
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [claimed-docs] “Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs.”
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 to VercelVercel's docs explicitly describe automatic preview environments for every push/branch/PR, environment variable management across preview/production, preview URL access controls, and comment/collaboration on preview environments—covering the full-stack preview workflow. Missing for 10: independent hands-on verification of preview environment fidelity/performance beyond vendor docs.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [claimed-docs] “Let teams and invited collaborators comment on your preview and production environments.”
- [claimed-docs] “Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 to VercelVercel's docs explicitly state that connecting a Git repo (GitHub, GitLab, Bitbucket) triggers automatic preview environments with a unique preview URL for every branch/push, which directly matches the PR-preview workflow story, and the GitHub repo confirms the git push-to-deploy flow. Missing for 10: independent hands-on confirmation beyond vendor docs of PR-specific (vs branch-only) preview URLs.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
Rollback recovery
developerRoll back a deployed service to any previous version in one click
weight 3 · round to VercelVercel's docs explicitly describe instant rollback to a previous deployment without rebuild for swift incident recovery, matching the one-click rollback story closely (vercel-docs-5, vercel-docs-29). This is corroborated by related gradual-rollout/promote-or-rollback functionality. missing for 10: independent hands-on confirmation of the rollback UX and any edge-case limitations (e.g., config/env var changes not covered by rollback).
- [claimed-docs] “Roll back to a previous deployment for swift recovery from production incidents.”
- [claimed-docs] “Revert production to a previous deployment without a rebuild when something breaks.”
- [claimed-docs] “Send a new deployment to a percentage of traffic first, then promote it or roll back.”
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 Vercelvercel-gh-1 confirms users can start a deployment by 'choosing a template' alongside importing a project or using the CLI, which supports one-click templates/starters, but the evidence pack lacks any documentation of a template gallery, specific starter examples, or a dedicated one-click deploy flow beyond this single mention. missing for 10: dedicated template/starter gallery docs, specific example templates, independent hands-on confirmation of one-click deploy UX.
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
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 VercelVercel's preview environments automatically spin up an isolated deployment for every git push/branch, enabling parallel work by any team member without conflict, and environment/variable management supports local, preview, production, and custom environments concurrently. This directly matches the story of unlimited isolated environments for simultaneous shipping. Missing for 10: explicit confirmation of 'unlimited' concurrency limits/pricing tiers and independent hands-on validation of scale under heavy team usage.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 drawnVercel's docs describe a consistent platform: zero-config framework deploys, Git-based push-to-deploy that works from prototype through production, and 'Fluid compute' explicitly designed to scale concurrency for demanding AI/I/O workloads without changing the deployment model (vercel-docs-14, vercel-docs-19, vercel-docs-27). However, community evidence shows real friction as usage grows — e.g. needing to 'contact sales' about 'enterprise' for basic secure database connections, and surprise large bills from traffic spikes — suggesting the platform isn't fully frictionless at scale and some capabilities require plan/negotiation changes rather than pure API continuity (vercel-comm-11, vercel-comm-12). Missing for 10: independent case studies of apps scaling from prototype to massive production traffic on unchanged APIs, and clearer evidence that enterprise-gated features don't require workflow changes.
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
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 VercelDocs confirm centralized environment variable management across local/preview/production/custom environments and identity-provider based security for internal agents/apps/deployments, which supports centralized secrets/access control. However, there is no explicit documentation of team roles/permissions (RBAC) or audit logging, and a community report notes secure DB connections beyond a password require an 'enterprise' sales conversation, suggesting some access-control features are gated. Missing for 10: dedicated team roles/permissions docs, audit-log evidence, and confirmation that secret-sharing controls are available outside enterprise tiers.
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [claimed-docs] “Secure every internal agent, app, and deployment with your identity provider.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 drawnVercel documents git-push deploys with GitHub/GitLab/Bitbucket, support for 40+ frameworks (including zero-config Next.js), and an optional CLI, which lets developers keep their existing Git and editor workflows largely intact (vercel-docs-1, vercel-docs-14, vercel-docs-27, vercel-gh-1, vercel-probe-4). However, community feedback flags real limitations: the platform is seen as effectively locked to the Node/JS/TS/Go ecosystem with 'WebAssembly gimmicks' for other languages, and some users feel it favors its own Next.js stack over full interoperability with arbitrary third-party CI systems (vercel-comm-7, vercel-comm-14). Missing for 10: explicit evidence of compatibility with external CI pipelines (Jenkins/CircleCI/etc.), broader language support beyond JS/TS/Go, and independent confirmation that non-Next.js frameworks get equally first-class treatment.
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [community] “"There is no serious reason to use Vercel, other than for those being locked into the NextJs ecosystem and demo projects."”
- [community] “"I dislike how Vercel and Netlify build up on AWS and then we only get JS/TS/Go, or WebAssembly gimmicks." — complaint about limited languag…”
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.ioVercelnone0/10The evidence pack contains no documentation of Vercel supporting standard, portable runtime/storage APIs (e.g., Web APIs, WinterCG standards) that would let code run unmodified on other edge platforms; all functions (Edge Middleware, Functions, KV/Blob storage, ISR) are described as Vercel-specific proprietary features. Community commentary even explicitly flags lock-in ('locked into the NextJs ecosystem') as a reason to avoid Vercel, reinforcing the absence of cross-platform portability. missing for 10: evidence of standard Web/Edge runtime API compliance, documentation of avoiding proprietary storage/runtime lock-in, cross-platform interoperability claims or benchmarks.
- [community] “"There is no serious reason to use Vercel, other than for those being locked into the NextJs ecosystem and demo projects."”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run code before a request completes to rewrite, redirect, or personalize responses.”
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.ioVercelnone0/10Vercel's execution environments are explicitly described as 'ephemeral' (vercel-docs-3, vercel-docs-17), the opposite of a persistent, auto-checkpointing runtime; no evidence describes state persistence or automatic checkpointing for agent workloads.
- [claimed-docs] “Run untrusted code in secure, ephemeral execution environments.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
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 VercelVercel AI Gateway lets builders call hundreds of models through one endpoint with budgets, fallbacks, and monitoring (a global, single-call inference layer), and Fluid compute scales concurrency for AI workloads without manual GPU management. However, this is a gateway/routing layer to third-party model providers rather than Vercel itself running GPU inference, and there's no evidence of Vercel-hosted GPU capacity planning being abstracted away for actual model hosting. Missing for 10: independent/hands-on verification of global latency and capacity claims, detail on GPU-backed inference infrastructure vs. pure routing, and confirmation this covers self-hosted/custom model inference, not just third-party API aggregation.
- [claimed-docs] “Access hundreds of models through one endpoint with budgets, fallbacks, and monitoring.”
- [claimed-docs] “Call hundreds of models through one endpoint with the AI SDK, any OpenAI-compatible SDK, or cURL, with budgets, fallbacks, and usage monitor…”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
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.ioVercelnone0/10The evidence pack never mentions region selection, multi-region deployment, or edge network configuration for compute; middleware/CDN mentions (vercel-docs-20, vercel-docs-22) refer to on-demand code execution and image optimization, not choosing deployment regions. Since region control is a plausible and common capability for a deployment platform, absence of evidence yields 'none' rather than 'na'.
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 Fly.ioVercelnone0/10The evidence pack shows Vercel's edge/compute features (Edge Middleware, Fluid compute, CDN, ISR) but contains no mention of automatic compute placement based on backend/data location, region-aware routing, or latency-optimizing placement near a data store — this specific edge-compute capability is unevidenced. missing for 10: any documentation of automatic region/compute placement tied to backend data location, region-selection configuration, or latency-based routing near data stores.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run code before a request completes to rewrite, redirect, or personalize responses.”
- [claimed-docs] “Resize and convert images on demand and serve them from the CDN in modern formats.”
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 Fly.ioVercelnone0/10No evidence pack item describes WebSocket support in Vercel's serverless/edge functions; the functions described (Edge Middleware, Fluid compute, sandboxes) are documented as request/response or ephemeral execution models, not persistent connections. Absence of evidence for this applicable capability yields 'none'. missing for 10: any documentation of WebSocket/persistent-connection support in serverless or edge functions, any first-party guidance on real-time connection handling.
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.ioDocs reference Fluid compute for running 'server-side code on demand' (vercel-docs-19) and 'production workloads in isolated containers' (vercel-docs-12), implying full Node.js runtime support beyond a restricted Edge subset, but no evidence explicitly confirms unmodified Node.js APIs or full npm package compatibility in edge/serverless functions. Missing for 10: explicit documentation contrasting Node.js runtime vs restricted Edge Runtime, npm package compatibility guarantees, and independent verification of unmodified Node.js execution.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
- [claimed-docs] “Run untrusted code in secure, ephemeral execution environments.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
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.ioVercelnone0/10The evidence pack contains no vendor documentation claiming edge functions can be written in Python, Go, or Rust; all edge/runtime references are JS/TS-focused. A community comment explicitly complains that Vercel (and Netlify) only offer 'JS/TS/Go, or WebAssembly gimmicks,' reinforcing that non-JS edge language support is not a real, documented capability.
- [community] “"I dislike how Vercel and Netlify build up on AWS and then we only get JS/TS/Go, or WebAssembly gimmicks." — complaint about limited languag…”
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 drawnVercel's docs explicitly describe a Sandbox feature for running untrusted or agent-generated code in isolated, ephemeral execution environments, and separately for running production workloads in isolated containers, matching the disposable/isolated sandbox story closely. Missing for 10: explicit confirmation of hardware-level isolation (e.g., microVM/VM-based tech) and independent/hands-on validation beyond first-party docs.
- [claimed-docs] “Run untrusted code in secure, ephemeral execution environments.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
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 VercelVercel's docs describe serverless/edge functions, Fluid compute for scaling concurrency, and isolated ephemeral execution environments that support rapid, elastic scaling for AI/I/O workloads, aligning with the edge-compute story's spirit. However, no evidence gives concrete sub-second boot benchmarks or explicit tens-of-thousands concurrent instance figures, and community reports of surprise $10k bills during undetected DDoS traffic (vercel-comm-12) hint at real-world scaling being uncontrolled/costly rather than a clean documented guarantee. Missing for 10: quantified cold-start/boot latency data, published large-scale load test results, and independent benchmarks validating claimed scale.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [claimed-docs] “Run code before a request completes to rewrite, redirect, or personalize responses.”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
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 VercelVercel's docs describe Fluid compute scaling concurrency for I/O-heavy workloads and isolated container-based production workloads, implying automatic capacity scaling for traffic bursts, and it offers bot/DDoS mitigation features (invisible CAPTCHA, custom firewall rules) that complement burst handling. However, there's no explicit 'autoscaling SLA' documentation, and community reports (e.g., surprise $10k bills tied to undetected DDoS traffic) suggest that while capacity does scale, cost/traffic-spike management can be unpredictable rather than a clean, bounded autoscaling guarantee. missing for 10: explicit autoscaling architecture docs/SLAs, independent load-test benchmarks, and clearer safeguards against runaway cost during bursts.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
- [claimed-docs] “Block attacks, scrapers, and unwanted traffic with custom rules, IP blocking, and managed rulesets.”
- [claimed-docs] “An invisible CAPTCHA that protects against sophisticated bots without challenges.”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
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 Fly.ioVercel's docs describe a global CDN with edge-executed middleware ('Run code before a request completes to rewrite, redirect, or personalize responses'), automatic image optimization served from the CDN, and Fluid compute scaling for I/O-heavy workloads, all consistent with edge network delivery close to end users. However, the evidence pack lacks explicit independent benchmarks or hands-on confirmation of edge latency/performance, and no community corroboration specifically addresses edge-network proximity. Missing for 10: independent latency benchmarks, explicit documentation of edge region coverage, and hands-on developer confirmation of edge execution behavior.
- [claimed-docs] “Run code before a request completes to rewrite, redirect, or personalize responses.”
- [claimed-docs] “Resize and convert images on demand and serve them from the CDN in modern formats.”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
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 VercelVercel's docs demonstrate zero-config framework deployment, git-based deploys, serverless/fluid compute, isolated execution sandboxes, and full-stack support for 40+ frameworks with automatic scaling and no server management (vercel-docs-14, vercel-docs-19, vercel-docs-12, vercel-docs-17, vercel-gh-1). This is corroborated by independent commentary describing Vercel's smooth 'code and go' onboarding as a leading serverless platform experience (vercel-comm-3). Missing for 10: deeper independent hands-on benchmarks of serverless function cold-starts/scaling limits beyond community anecdotes.
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [community] “A user predicted Vercel could become the dominant go-to platform for serverless frameworks, contrasting its smooth 'code and go' onboarding …”
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 VercelVercel documents a Workflow SDK explicitly for building 'durable, observable applications and AI agents' on a fully managed platform, directly matching the story of deploying durable workflows as code without manually wiring queues/retries, and this is complemented by Fluid compute for scaling concurrency. Missing for 10: no independent/hands-on evidence of retry semantics or durability guarantees, no detail on how queuing is abstracted, and no community corroboration of real-world reliability.
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
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 VercelVercel docs explicitly state you can 'Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs' (vercel-docs-26), directly matching the story of simple password protection without building custom auth. Missing for 10: independent/hands-on corroboration of the password-protection feature working as described and details on any plan restrictions.
- [claimed-docs] “Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs.”
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 VercelVerceldisputedcontradicted4/10Vercel's docs describe a firewall that can 'block attacks, scrapers, and unwanted traffic with custom rules, IP blocking, and managed rulesets' (vercel-docs-24) and bot-protection features (vercel-docs-11, vercel-docs-25), suggesting WAF-like capability, but these are configurable/opt-in rather than clearly stated as applied to every request 'by default'. A community report explicitly states that 'waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected' (vercel-comm-12), directly contradicting the idea that DDoS protection is reliably applied automatically. missing for 10: explicit vendor claim of automatic, zero-config DDoS mitigation on every request, independent confirmation that the firewall/bot-protection is enabled by default rather than requiring rule configuration, and resolution of the community-reported undetected-DDoS billing incidents.
- [claimed-docs] “Block attacks, scrapers, and unwanted traffic with custom rules, IP blocking, and managed rulesets.”
- [claimed-docs] “An invisible CAPTCHA that protects against sophisticated bots without challenges.”
- [claimed-docs] “Protect sensitive routes from sophisticated bots with an invisible check instead of a CAPTCHA.”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
Domains
developerAttach custom domains to my deployed services
weight 2 · round to VercelVercel docs explicitly state you can 'Add a custom domain, manage DNS records, and get SSL certificates automatically,' directly matching the story of attaching custom domains to deployed services. This is first-party documentation with no contradicting evidence. Missing for 10: independent/hands-on corroboration of the custom domain workflow beyond vendor docs.
- [claimed-docs] “Add a custom domain, manage DNS records, and get SSL certificates automatically.”
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 to VercelVercel docs mention adding custom domains with automatic DNS/SSL (vercel-docs-31) and an OpenAPI surface exists (vercel-probe-3), suggesting some programmatic domain management is possible, but there is no explicit documentation of a multi-tenant SaaS domain-provisioning API or workflow for routing customer-owned domains. Missing for 10: explicit Domains API docs for multi-tenant use cases, per-tenant provisioning examples, and independent confirmation of this workflow working at scale.
- [claimed-docs] “Add a custom domain, manage DNS records, and get SSL certificates automatically.”
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
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 to VercelVercel lets teams manage separate environment variables per environment and gate preview/production URL access via authentication, passwords, or trusted IPs, which supports some separation between non-prod and prod environments. However, there's no explicit evidence of network-level isolation preventing a preview deployment from reaching production databases/services, and a community report notes that secure database connectivity beyond a password requires an enterprise sales conversation, undercutting the case for out-of-box isolation. Missing for 10: documented network segmentation or firewall rules between environments, default prevention of preview-to-production service calls, and independent verification that isolation works without enterprise upsell.
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [claimed-docs] “Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs.”
- [claimed-docs] “Secure every internal agent, app, and deployment with your identity provider.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 VercelVercel explicitly claims 'Secure every internal agent, app, and deployment with your identity provider' and separately offers Vercel Authentication/passwords/trusted IPs to gate preview and production URLs, directly matching the devops-lead's IdP-based security story. However, the evidence is a single thin marketing line with no detail on supported IdPs (SAML/OIDC/SSO providers), no docs on configuration steps, and no independent or hands-on corroboration that this works in practice. Missing for 10: detailed IdP integration docs (specific protocols/providers), setup/configuration guidance, and third-party validation of the feature working as described.
- [claimed-docs] “Secure every internal agent, app, and deployment with your identity provider.”
- [claimed-docs] “Control who can open your preview and production URLs with Vercel Authentication, passwords, or trusted IPs.”
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.ioVercelnone0/10The evidence pack contains no documentation of private networking, VPC peering, or mechanisms to keep service-to-service traffic off the public internet; a community comment even suggests secure database connectivity beyond a password requires an undocumented 'enterprise' sales conversation rather than a built-in feature. This is a fair axis for a cloud/deployment platform, but no capability is evidenced.
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 drawnVercelnone0/10Vercel's evidence is entirely about HTTP-based serverless functions, edge middleware, static hosting, and framework deployment; there is no mention of TCP, gRPC, or WebSocket protocol support from the same deployed service. Vercel's serverless model is known to be HTTP-request/response oriented, and no evidence pack item claims multi-protocol serving without separate configuration.
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 VercelVercel's docs state that adding a custom domain automatically provides SSL certificates and DNS management, implying free, auto-renewing TLS, but the evidence never explicitly confirms wildcard domain certificate support or renewal mechanics. Missing for 10: explicit wildcard-domain TLS support, renewal automation details, and independent confirmation that certs are free/no manual step.
- [claimed-docs] “Add a custom domain, manage DNS records, and get SSL certificates automatically.”
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 to VercelVercel offers monitoring/observability (vercel-docs-30) and a Slack marketplace integration that notifies on deployment status and comments (vercel-intdir-6), plus third-party logging integrations like Better Stack (vercel-intdir-5), but there is no first-party evidence of configurable alert rules with custom conditions or native email notifications for observability thresholds. Missing for 10: documented native alert-rule/threshold configuration, email notification channel, and evidence these trigger on arbitrary monitoring conditions rather than just deployment events.
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
- [claimed-docs] “Get Slack messages for comments, deployment status, and new projects on Vercel.”
- [claimed-docs] “Better Stack - formerly Logtail”
Metrics dashboards
devops-leadBuild custom dashboards combining metrics from any service
weight 2 · round drawnVercelnone0/10Vercel's docs mention its own monitoring/observability dashboard for traffic, function performance, and errors (vercel-docs-30) and marketplace integrations with monitoring tools like Better Stack (vercel-intdir-5), but there is no evidence of a capability to build custom dashboards combining metrics from arbitrary/any external services into one view.
Reliability sla
devops-leadCheck a public status page with historical incident postmortems before committing
weight 2 · round drawnVercelnone0/10No evidence pack item references a public status page or historical incident postmortem repository; the only related material is community criticism that Vercel's 2026 security incident disclosure was vague and lacked specifics, which does not constitute a status/postmortem page.
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 drawnVercelnone0/10No evidence pack item mentions an uptime SLA, uptime percentage guarantee, or service credits for downtime; only general platform features and community commentary on a security incident are present.
devops-leadThe guaranteed support response times and escalation paths for my plan tier
weight 2 · round drawnVercelnone0/10No evidence pack item mentions support SLAs, guaranteed response times, or escalation paths for any plan tier; only product features, community sentiment, and unrelated docs are provided.
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 VercelVercel's docs describe an observability feature that monitors traffic, function performance, and errors across apps and AI workflows (vercel-docs-30), and the platform inherently surfaces deployment/build status through its Git-integrated deploy flow (vercel-docs-1, vercel-docs-27). However, no evidence explicitly confirms a single unified view combining build logs, deploy logs, and runtime logs together. missing for 10: explicit documentation of a unified log viewer spanning build, deploy, and runtime stages, and independent/hands-on confirmation of this consolidated experience.
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
- [claimed-docs] “Connect your Git repository to deploy on every push, with automatic preview environments for testing changes before production.”
- [claimed-docs] “Connect GitHub, GitLab, or Bitbucket to deploy on every push, with a preview URL for every branch.”
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 to Fly.ioVercel exposes a public REST API (openapi.json) and a CLI covering deployments, domains, env vars, etc., suggesting broad but unconfirmed parity with the UI; no documentation explicitly claims full UI/API feature parity, and features like the in-browser toolbar, comments, and CMS draft preview are described as UI-specific experiences. missing for 10: explicit parity statement, evidence that toolbar/comments/CMS-preview features are API-accessible, independent confirmation of full API coverage.
- [probe] “PROBE openapi: HTTP 200 at https://vercel.com/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
- [github] “To opt into the native binary and replace existing global vercel and vc commands, install the native package explicitly”
- [claimed-docs] “An in-browser toolbar to leave feedback, manage flags, preview drafts, and inspect performance.”
- [claimed-docs] “Let teams and invited collaborators comment on your preview and production environments.”
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 drawnVercelnone0/10No evidence pack item addresses data export, portability, or account/data deletion in open formats for Vercel; nothing about exporting project data, logs, or analytics in a standard/open format for migration. This is a reasonable axis for a PaaS holding deployment/config/data (project settings, env vars, analytics), but no such export capability is documented.
ai-native userRead the product's source under an open license
weight 2 · round to VercelThere's a public GitHub repo (vercel/vercel) referenced for getting started with the CLI, suggesting some source is publicly visible, but no evidence confirms an explicit open-source license or that the core platform (not just the CLI) is open. missing for 10: explicit license documentation, confirmation that the full product/platform source (not just CLI) is publicly available, independent verification of licensing terms.
- [github] “Get started by importing a project, choosing a template, or using the Vercel CLI. Then, git push to deploy.”
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 drawnVercelnone0/10Vercel is a proprietary managed cloud platform; there is no evidence of a self-hostable core product, on-prem package, or open-source server offering—only CLI and SDK tooling that deploy to Vercel's own infrastructure. The evidence even shows community members switching to genuinely self-hostable alternatives like Dokploy specifically to leave Vercel, underscoring the absence of a self-host option.
- [community] “"Also checkout Dokploy. Incredible to leave Vercel." — implying satisfaction after switching away from Vercel to a self-hosted alternative.”
- [probe] “official CLI documented at https://vercel.com/docs/cli”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
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 to VercelVerceldisputedcontradicted3/10Vercel only documents 'budgets' as part of its AI Gateway feature for LLM usage (vercel-docs-2, vercel-docs-16), not a platform-wide hard spending cap for compute/bandwidth costs, and community reports explicitly describe surprise five-figure bills ('Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected') indicating no effective hard limit exists for overall cloud spend. Missing for 10: dedicated hard-cap/kill-switch billing controls for general project usage, first-party docs on enforceable spend limits, and independent confirmation that such limits actually stop overage.
- [claimed-docs] “Access hundreds of models through one endpoint with budgets, fallbacks, and monitoring.”
- [claimed-docs] “Call hundreds of models through one endpoint with the AI SDK, any OpenAI-compatible SDK, or cURL, with budgets, fallbacks, and usage monitor…”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
devops-leadReceive migration credits when moving my production infrastructure to a new platform
weight 1 · round drawnVercelnone0/10No evidence in the pack mentions migration credits, competitive switching incentives, or pricing offers for moving infrastructure from another platform to Vercel; the pack covers deployment, security, and AI features only.
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 drawnVercelnone0/10No evidence pack item specifies concrete CPU or wall-clock execution time limits for functions (e.g., seconds per plan tier). Docs mention Fluid compute, sandboxes, and workflows but never state numeric duration/CPU limits a devops-lead could use to size agentic workloads. Missing for 10: explicit maxDuration/timeout numbers per plan, CPU allocation limits, and any pricing-page or docs citation stating these limits.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [claimed-docs] “Run untrusted or agent-generated code in isolated, ephemeral execution environments.”
- [claimed-docs] “Run production workloads in isolated containers on Vercel.”
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 drawnVercelnone0/10The evidence pack contains no vendor documentation of a specific overage fee schedule for bandwidth, invocations, or build minutes — only general product/feature docs unrelated to billing granularity. A community comment even suggests unexpected surprise billing ("Waking up to a 10k vercel bill is pretty common"), reinforcing that no clear overage schedule evidence exists.
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
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 drawnVercelnone0/10No evidence in the pack addresses Vercel's pricing model, seat-based billing, or minimum seat counts; all citations concern product features, integrations, or unrelated community sentiment/security incidents. This axis applies to any SaaS platform but is unaddressed here.
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 Fly.ioVercel's 'Fluid compute' feature is explicitly marketed as running server-side code 'on demand' with concurrency scaling for I/O and AI workloads, which aligns with paying only for active compute rather than idle time — a core value prop of this pricing model. However, there is no detailed documentation of the actual billing mechanics (e.g., how idle vs active CPU time is measured/charged) and community sentiment includes concerns about unpredictable large bills, suggesting real-world cost behavior isn't fully transparent. Missing for 10: detailed pricing/billing docs on active-vs-idle compute metering, third-party verification of actual cost savings vs traditional serverless, and clarification of how this applies across all function types.
- [claimed-docs] “Run server-side code on demand with Fluid compute, which scales concurrency for AI and I/O-heavy workloads.”
- [community] “"Waking up to a 10k vercel bill is pretty common, especially when a DDoS goes undetected."”
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.ioVercelnone0/10No evidence pack item mentions data residency, region selection, or storage location controls for Vercel deployments or data; the closest items are about environments, domains, and functions, not geographic data residency.
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 drawnVercelnone0/10The evidence pack contains no mention of data retention policies, deletion controls, data lifecycle management, or privacy/GDPR-style deletion tooling for Vercel. While security-adjacent topics (identity, environment variables, incident disclosure) appear, none address user-controllable data retention/deletion.
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 drawnVercelnone0/10No evidence pack item mentions telemetry, usage tracking, or an opt-out mechanism for Vercel's CLI, platform, or AI tools; nothing in the docs, GitHub, or community sources addresses this capability.
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 VercelVercel documents serving optimized images 'from the CDN' and offers ISR/edge middleware, implying CDN-backed static asset delivery, but the evidence pack lacks explicit documentation of a global edge network, cache-control/edge caching mechanics, or performance benchmarks/independent corroboration of CDN speed. Missing for 10: explicit global CDN architecture docs, edge cache configuration details, independent performance benchmarks confirming faster asset delivery.
- [claimed-docs] “Resize and convert images on demand and serve them from the CDN in modern formats.”
- [claimed-docs] “Regenerate static pages on a schedule or on demand without rebuilding your whole site.”
- [claimed-docs] “Deploy Next.js with zero configuration, or bring one of 40+ supported frameworks.”
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 VercelVercel's Marketplace lists native, first-party integrations (Neon Postgres, Pinecone, Shopify, Slack, Jira/Linear, etc.) that plug into a project with managed credentials, reducing manual SDK wiring, and Vercel documents environment/variable management across environments. However, a concrete community report states that connecting to a database with more than a password requires 'contact sales' for enterprise, indicating the native-binding security experience is limited for standard tiers, and there's no first-party technical deep-dive on how the binding/credential injection mechanism works beyond marketplace listings. Missing for 10: detailed docs on the binding mechanism itself, independent hands-on confirmation of minimal-boilerplate setup, and resolution of the enterprise-gating friction noted in community feedback.
- [claimed-docs] “A collection of first-party services you can easily add to your Vercel project.”
- [claimed-docs] “Neon is serverless Postgres built for the cloud, with autoscaling and instant branching.”
- [claimed-docs] “Access Perplexity's cutting edge LLMs”
- [claimed-docs] “Get Slack messages for comments, deployment status, and new projects on Vercel.”
- [claimed-docs] “Convert comments to Linear issues”
- [claimed-docs] “Manage local, preview, production, and custom environments and the variables each one uses.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 drawnVercelnone0/10The evidence pack lists many Vercel marketplace integrations (Neon Postgres, Shopify, Perplexity, Pinecone, etc.) but none mention a Redis-compatible key-value store, caching layer, or job-queue product like Upstash/Vercel KV. Storage/caching is a plausible axis for a deployment platform, but no evidence here demonstrates this capability.
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 drawnVercelnone0/10The evidence pack lists Vercel's marketplace integrations (Neon Postgres, Pinecone, Better Stack, etc.) and platform features (deployments, functions, image optimization) but nowhere mentions Vercel Blob or any built-in object storage product for persisting user uploads. Storage-as-a-service is a plausible axis for a hosting platform, but no documentation, marketplace listing, or community evidence confirms this capability.
- [claimed-docs] “A collection of first-party services you can easily add to your Vercel project.”
- [claimed-docs] “Neon is serverless Postgres built for the cloud, with autoscaling and instant branching.”
- [claimed-docs] “Power your AI products with Pinecone”
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 VercelVercel offers Postgres only via a third-party Marketplace partner (Neon), described as 'serverless Postgres... with autoscaling and instant branching' rather than a Vercel-native fully-managed service with explicit point-in-time recovery, replicas, or HA guarantees. Missing for 10: first-party documentation of PITR, replica configuration, and HA SLAs, and any confirmation these features are exposed through the Vercel-integrated product rather than left to Neon's own console.
- [claimed-docs] “Neon is serverless Postgres built for the cloud, with autoscaling and instant branching.”
- [claimed-docs] “A collection of first-party services you can easily add to your Vercel project.”
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 VercelVercel's marketplace lists Neon as a serverless Postgres partner offering autoscaling and instant branching, which implies serverless SQL access without manual connection pooling, but this is a third-party integration rather than a first-party Vercel database product with explicit 'no connection management' messaging. A community comment also notes friction: securely connecting Vercel to a database beyond a password reportedly requires an enterprise sales conversation, undercutting the 'no connection management' simplicity claim. Missing for 10: first-party Vercel docs describing a native serverless SQL/Postgres offering with pooling handled transparently, code examples showing zero-config querying, and independent hands-on confirmation that connection management is truly abstracted.
- [claimed-docs] “Neon is serverless Postgres built for the cloud, with autoscaling and instant branching.”
- [community] “"if you want to connect Vercel securely to a database with more than a password, you need to 'contact sales' about 'enterprise'... needing t…”
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 comparableVercelnone0/10The evidence shows Vercel exposing its own capabilities as tools for AI agents (vercel-docs-4, vercel-docs-15) and building agent infrastructure (Workflow SDK, AI Gateway), but there is no evidence that Vercel itself can act as an MCP client, ingesting external MCP servers so it can use their tools. Missing for 10: any documentation of Vercel connecting to third-party MCP servers as a client and invoking their tools.
- [claimed-docs] “Create tools for AI agents to interact with your systems.”
- [claimed-docs] “Give your coding agent deployment skills, framework best practices, and slash commands. Works with Claude Code, OpenAI Codex, Grok Build, Cu…”
- [claimed-docs] “Build durable, observable applications and AI agents with the Workflow SDK on a fully managed platform.”
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 comparableVercel's docs mention 'framework-aware insights' across apps and AI workflows for monitoring traffic, function performance, and errors (vercel-docs-30), which suggests some automated analysis of the user's own deployment/app data, but there is no clear evidence of AI-generated suggestions or recommendations (e.g., anomaly detection, actionable AI advice) surfaced inside the product. Missing for 10: explicit description of an AI/ML-driven insights engine that generates suggestions from user data, independent corroboration or screenshots of such a feature, and detail on how 'insights' differ from standard dashboards/metrics.
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableVercelnone0/10The evidence shows Vercel providing AI infrastructure (AI Gateway, AI SDK, Workflow SDK) and integration hooks for external coding agents (Claude Code, Cursor, etc.) to interact with Vercel, but no evidence of a built-in AI assistant inside the Vercel product 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 comparableVercel's docs explicitly describe an in-browser toolbar for leaving feedback, managing feature flags, previewing drafts, and inspecting performance, directly matching the story, and this is reinforced by related features like comments on preview/production environments and framework-aware performance insights. missing for 10: independent/hands-on corroboration of the toolbar beyond first-party docs.
- [claimed-docs] “An in-browser toolbar to leave feedback, manage flags, preview drafts, and inspect performance.”
- [claimed-docs] “Let teams and invited collaborators comment on your preview and production environments.”
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
developerLet teammates and collaborators comment directly on preview and production environments
weight 1 · not comparableVercel docs explicitly state teams and invited collaborators can comment on preview and production environments, corroborated by marketplace integrations that convert those comments into GitHub/Jira/Linear issues, showing the feature is real and integrated into workflows. Missing for 10: independent/hands-on user testimonials specifically about the commenting feature's usability.
- [claimed-docs] “Let teams and invited collaborators comment on your preview and production environments.”
- [claimed-docs] “An in-browser toolbar to leave feedback, manage flags, preview drafts, and inspect performance.”
- [claimed-docs] “Convert comments to GitHub issues”
- [claimed-docs] “Convert comments to Jira issues”
- [claimed-docs] “Convert comments to Linear issues”
devops-leadVisualize and edit my entire infrastructure stack on a visual canvas without writing config files
weight 2 · not comparableVerceln/aVercel is a code-first deployment/hosting platform with a CLI and config files (vercel.json, git-based deploys); there is no evidence of a visual canvas for designing or editing infrastructure without config. This story targets an IaC-visualization product category, which is a wrong axis for a deployment platform like Vercel.
ai-native builderAccess hundreds of AI models through a single unified gateway endpoint
weight 3 · not comparableVercel's AI Gateway is directly documented as accessing hundreds of models through one unified endpoint, supporting the AI SDK, OpenAI-compatible SDKs, or cURL, with budgets, fallbacks, and usage monitoring. Missing for 10: independent/hands-on corroboration of the gateway's model count and reliability claims beyond first-party docs.
- [claimed-docs] “Access hundreds of models through one endpoint with budgets, fallbacks, and monitoring.”
- [claimed-docs] “Call hundreds of models through one endpoint with the AI SDK, any OpenAI-compatible SDK, or cURL, with budgets, fallbacks, and usage monitor…”
developerProtect my app from automated bot traffic with invisible challenge-based protection
weight 1 · not comparableVercel's docs explicitly describe an invisible CAPTCHA/bot check ('An invisible CAPTCHA that protects against sophisticated bots without challenges' and 'Protect sensitive routes from sophisticated bots with an invisible check instead of a CAPTCHA'), directly matching the story. This is complemented by broader firewall/rules-based bot blocking. Missing for 10: independent/hands-on verification of the invisible challenge's effectiveness and no third-party benchmarking of bypass rates.
- [claimed-docs] “An invisible CAPTCHA that protects against sophisticated bots without challenges.”
- [claimed-docs] “Protect sensitive routes from sophisticated bots with an invisible check instead of a CAPTCHA.”
- [claimed-docs] “Block attacks, scrapers, and unwanted traffic with custom rules, IP blocking, and managed rulesets.”
devops-leadTrack site performance and visitor behavior with built-in analytics
weight 1 · not comparableVercel docs claim built-in monitoring of traffic, function performance, and errors with framework-aware insights (vercel-docs-30), which covers site performance observability; the in-browser toolbar also lets users inspect performance (vercel-docs-7). However, there's no explicit mention of visitor behavior analytics (e.g., page views, sessions, geography breakdowns) beyond generic 'traffic' monitoring, and no independent/hands-on corroboration of the analytics product's depth or dashboards. missing for 10: dedicated visitor-behavior analytics detail (e.g. Web Analytics feature specifics), independent verification of analytics accuracy/usefulness, and any devops-lead-specific alerting/dashboard evidence.
- [claimed-docs] “Monitor traffic, function performance, and errors with framework-aware insights across your apps and AI workflows.”
- [claimed-docs] “An in-browser toolbar to leave feedback, manage flags, preview drafts, and inspect performance.”
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 comparableVerceln/aVercel is a serverless/PaaS deployment platform with ephemeral functions and edge/static hosting rather than a provider of attached block storage volumes for compute instances; the evidence pack shows no concept of 'attached disks' at all, only marketplace-integrated databases (e.g., Neon) which are a separate axis. This 'auto-growing disk with per-byte billing' story is a category mismatch for Vercel's architecture.
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 comparableVercelnone0/10No evidence in the pack addresses AI training data opt-out or data usage policies for AI model training; Vercel's docs cover deployment, AI Gateway, sandboxes, and infra but never mention data-training controls.
developerResize and optimize images on demand via a built-in image CDN
weight 1 · not comparableVercel's docs explicitly describe on-demand image resizing/conversion served from the CDN in modern formats, directly matching the story's requirements. Missing for 10: independent/hands-on corroboration beyond first-party docs and detail on caching/format negotiation specifics.
- [claimed-docs] “Resize and convert images on demand and serve them from the CDN in modern formats.”