Fly.io vs Render

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Render
   Fly.io✓fullprobed8/10

   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.”

   proof ↗⚑ flag

   Render✓fullprobed9/10

   Render hosts a live, working llms.txt (HTTP 200) and Markdown-formatted docs (docs.md) confirmed via direct probes, plus per-page .md docs (e.g. mcp-server.md, cli.md) an agent could fetch directly. Missing for 10: no independent/community corroboration that agents are actually being pointed at these files successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://render.com/llms.txt # Render Render (https://render.com) is a cloud application platform for deploying,…”
   • [probe] “PROBE docs-md: HTTP 200 at https://render.com/docs.md # Render Render (https://render.com) is a cloud application platform for deploying, s…”
   • [claimed-docs] “Render's Model Context Protocol (MCP) server enables you to manage your Render infrastructure directly from compatible AI apps, such as Clau…”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Render
   Fly.io~partialprobed6/10

   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/”

   proof ↗⚑ flag

   Render✓fullprobed8/10

   Render provides an official CLI for scripting/managing deploys and datastores from a terminal, a documented REST API and OpenAPI spec, and blueprint YAML (render.yaml) with CLI validation for defining/deploying architecture as code—together these enable headless automation and CI-driven workflows. Missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions integration) and independent hands-on confirmation of CI usage.

   • [claimed-docs] “Render CLI”
   • [claimed-docs] “REST API”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “Validating `render.yaml` files for Render Blueprints”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Render
   Fly.io~partialclaimed5/10

   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.”

   proof ↗⚑ flag

   Render✓fullclaimed9/10

   Render ships an official MCP server enabling AI apps/agents like Claude Code, Claude Desktop, Codex CLI/Desktop, and Cursor to manage Render infrastructure, with documented tools (e.g., trigger_deploy) and OAuth-based authentication support. Since Render is a cloud platform (not itself an agent), this axis clearly applies and is well-documented with first-party docs and changelog evidence. Missing for 10: independent/hands-on third-party corroboration of the MCP server working in practice.

   • [claimed-docs] “Render's Model Context Protocol (MCP) server enables you to manage your Render infrastructure directly from compatible AI apps, such as Clau…”
   • [claimed-docs] “The Render MCP server now includes a `trigger_deploy` tool that enables you (and your agents) to kick off a new deploy of an existing servic…”
   • [claimed-docs] “The Render MCP server now supports OAuth-based authentication for Claude Code, Codex, and Cursor”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Fly.io✓fullprobed8/10

   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…”

   proof ↗⚑ flag

   Render✓fullprobed8/10

   Render documents an official CLI for managing services, datastores, and blueprints directly from the terminal, with validation for render.yaml files, corroborated by a dedicated docs page and probe confirmation. missing for 10: independent/hands-on community verification of the CLI itself (community evidence only covers general platform sentiment, not CLI usage) and deeper detail on AI-native-specific CLI workflows beyond blueprint validation.

   • [claimed-docs] “Render CLI”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “Validating `render.yaml` files for Render Blueprints”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Render
   Fly.io~partialprobed6/10

   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”

   proof ↗⚑ flag

   Render✓fullprobed9/10

   Render publishes a documented REST API with a live OpenAPI spec (render-docs-15, render-probe-3), plus a CLI (render-docs-14/27) and SDKs for TypeScript/Python (render-docs-22/23), giving AI-native users multiple documented programmatic entry points. Missing for 10: independent third-party corroboration of API robustness/completeness beyond Render's own docs.

   • [claimed-docs] “REST API”
   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Render CLI”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “The Render SDK for TypeScript provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other TypeScript co…”
   • [claimed-docs] “The Render SDK for Python provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other Python code”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Fly.io
   Fly.io✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

   Render~partialclaimed5/10

   Render documents OAuth-based authentication for its MCP server (used by agent tools like Claude Code/Codex/Cursor) and managed OIDC that issues short-lived, auto-rotated identity tokens instead of long-lived API keys, both of which support least-privilege, ephemeral credentialing for agent-driven workflows. However, there is no explicit documentation of fine-grained, scoped API-key permissions (e.g., read-only vs. deploy-only tokens) specifically for AI agents beyond OAuth/OIDC. Missing for 10: explicit scoped/permissioned API key creation UI or docs, granular role-based token scopes, and independent verification of least-privilege enforcement in practice.

   • [claimed-docs] “Render's Model Context Protocol (MCP) server enables you to manage your Render infrastructure directly from compatible AI apps, such as Clau…”
   • [claimed-docs] “The Render MCP server now supports OAuth-based authentication for Claude Code, Codex, and Cursor”
   • [claimed-docs] “Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens fo…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Render
   Fly.io—none0/10

   Evidence 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/”

   proof ↗⚑ flag

   Render✓fullprobed8/10

   Render ships official SDKs for TypeScript and Python workflow tasks (render-docs-22, render-docs-23), plus a REST API with a documented OpenAPI spec (render-docs-15, render-probe-3) and an official CLI (render-docs-14, render-probe-4), all of which AI-native developers can build against programmatically. Missing for 10: independent/hands-on developer corroboration of SDK usage quality and broader language SDK coverage beyond TypeScript/Python.

   • [claimed-docs] “The Render SDK for TypeScript provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other TypeScript co…”
   • [claimed-docs] “The Render SDK for Python provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other Python code”
   • [claimed-docs] “REST API”
   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Render CLI”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Render
   Fly.io—none0/10

   No 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!”

   proof ↗⚑ flag

   Render✓fullclaimed8/10

   Render's docs explicitly describe workspace webhooks that notify external systems on service events like deploys or scaling, matching the story of subscribing to events via webhooks. Missing for 10: no independent/hands-on corroboration of webhook reliability or delivery guarantees, and no detail on payload/signature verification depth.

   • [claimed-docs] “You can configure *webhooks* for your Render workspace to notify other systems when specific service events occur (such as a deploy starting…”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Render
   Fly.io~partialcommunity5/10

   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…”

   proof ↗⚑ flag

   Render✓fullclaimed8/10

   Render explicitly supports deploying background workers/agents and processes 'at scale, without wiring up queues, workers, and retry logic,' and its Workflows SDKs (TypeScript/Python) let users define and trigger long-running background tasks autonomously. This directly matches the story of setting up autonomous background automations on the platform. Missing for 10: explicit documentation of scheduled/cron-based triggers and independent hands-on validation of long-running autonomous jobs.

   • [claimed-docs] “Deploy reliable agents and background processes at scale, without wiring up queues, workers, and retry logic.”
   • [claimed-docs] “The Render SDK for TypeScript provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other TypeScript co…”
   • [claimed-docs] “The Render SDK for Python provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other Python code”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Render
   Fly.io~partialclaimed4/10

   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`”

   proof ↗⚑ flag

   Render~partialclaimed6/10

   Render ships an MCP server enabling natural-language control from AI apps (Claude Code, Cursor, Codex) with tools like trigger_deploy, plus 20+ official skills for coding agents, indicating agentic/NL operation is supported. However, this operates through third-party AI clients rather than a native NL interface within Render itself, and there's no independent hands-on evidence of reliability. missing for 10: first-party natural-language interface within Render's own UI/CLI, independent/community validation of MCP-driven workflows, evidence of broader command coverage beyond deploy/inspect/scale.

   • [claimed-docs] “Render's Model Context Protocol (MCP) server enables you to manage your Render infrastructure directly from compatible AI apps, such as Clau…”
   • [claimed-docs] “The Render MCP server now includes a `trigger_deploy` tool that enables you (and your agents) to kick off a new deploy of an existing servic…”
   • [claimed-docs] “The Render MCP server now supports OAuth-based authentication for Claude Code, Codex, and Cursor”
   • [claimed-docs] “You can start a short-lived instance of your service to inspect its runtime or run one-off commands without connecting to production.”
   • [claimed-docs] “Update service plans. An agent can inspect CPU and memory metrics, recommend a different compute plan, and apply the change after you approv…”
   • [claimed-docs] “Render now offers more than 20 official skills for Claude Code, Cursor, and Codex. They give coding agents Render-specific guidance for depl…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Fly.io—none0/10

   No 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…”

   proof ↗⚑ flag

   Render—none0/10

   Evidence confirms Render has a REST API and a machine-readable OpenAPI spec (render-docs-15, render-probe-3), but there is no mention of an interactive API reference UI or runnable/try-it-now examples anywhere in the docs or community evidence.

   • [claimed-docs] “REST API”
   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Render
   Fly.io—none0/10

   Fly.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.”

   proof ↗⚑ flag

   Render✓fullprobed9/10

   Render exposes a machine-readable OpenAPI spec at a public, well-known endpoint confirmed to contain the 'openapi' key, alongside a documented REST API in first-party docs. Missing for 10: no independent/community corroboration of the OpenAPI file's completeness or version stability.

   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “REST API”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Render
   Fly.io~partialclaimed7/10

   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.”

   proof ↗⚑ flag

   Render✓fullclaimed8/10

   Render explicitly ships ephemeral preview environments for full application architectures per change, documents a mechanism to prevent non-production environments from accessing production services, and supports spinning up short-lived instances to inspect runtime or run one-off commands without touching production. Together these give AI-native users a documented, isolated sandbox path distinct from production data. Missing for 10: independent/hands-on verification that preview environments fully isolate data, and explicit guidance on seeding sandbox data for AI agent testing.

   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”
   • [claimed-docs] “Prevent non-production environments from accessing production services.”
   • [claimed-docs] “You can start a short-lived instance of your service to inspect its runtime or run one-off commands without connecting to production.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Fly.io—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and no docs mention versioning/deprecation commitments.

   • [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] “PROBE docs-md: HTTP 404 at https://fly.io/docs.md”

   proof ↗⚑ flag

   Render—none0/10

   There is evidence of a REST API and an OpenAPI spec, but nothing in the pack documents API versioning scheme or a deprecation policy for that API. missing for 10: documented API version numbers/paths, a published deprecation/sunset policy, changelog commitments around breaking changes.

   ⚑ flag

5. developerThe documented rate limits and concurrency caps for APIs and functions so I can plan for scale

   weight 3 · round drawn
   Fly.io—none0/10

   No evidence pack items document specific rate limits, concurrency caps, or throughput quotas for Fly.io's APIs, Machines, or MCP/Sprite offerings; docs focus on scaling primitives and pricing model, not documented numeric limits/caps for planning capacity.

   ⚑ flag

   Render—none0/10

   No evidence pack items document specific rate limits or concurrency caps for Render's APIs, functions, or REST API/MCP server; autoscaling is mentioned generically but no numeric limits or quotas are given. Missing for 10: documented API rate limits, function concurrency caps, or any quantified throttling/quota policy.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Render
   Fly.io~partialclaimed3/10

   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”

   proof ↗⚑ flag

   Render~partialclaimed4/10

   Render's Blueprints (render.yaml) let you define, deploy, and version an entire multi-service architecture from a single file (render-docs-9, render-docs-29), and the REST API/CLI provide programmatic control (render-docs-14, render-docs-15, render-docs-27) that could be scripted for bulk actions. However, there is no explicit documentation of a bulk/batch operation feature (e.g., bulk delete, bulk env-var update, batch service management) beyond blueprint-based multi-service deploys. Missing for 10: explicit bulk/batch API or CLI commands acting across many items, independent confirmation of bulk workflows in practice.

   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [claimed-docs] “Render CLI”
   • [claimed-docs] “REST API”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Render
   Fly.io—none0/10

   Fly.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…”

   proof ↗⚑ flag

   Render~partialclaimed5/10

   Render supports several event-driven automations — auto-deploy on push (render-docs-1), load-based autoscaling (render-docs-11), and configurable webhooks that notify external systems on service events like deploy start or scale-down (render-docs-31) — which together approximate rule-based triggers. However, there's no first-class 'rules engine' UI for defining custom conditional automations beyond these built-in triggers and webhook notifications. Missing for 10: a dedicated rules/automation builder, support for custom conditional logic (not just fixed event types), and independent evidence of users building automation workflows on these triggers.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”
   • [claimed-docs] “You can configure *webhooks* for your Render workspace to notify other systems when specific service events occur (such as a deploy starting…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Fly.io—none0/10

   No 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…”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack shows Render's Workflows SDK for defining and triggering workflow tasks and background/agent processes, but nothing explicitly describes scheduling or recurring/cron-based job execution. Missing for 10: explicit cron/scheduled job feature, recurring-trigger documentation, or interval-based automation evidence.

   ⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Render
   Fly.io~partialclaimed4/10

   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.”

   proof ↗⚑ flag

   Render~partialclaimed6/10

   Render supports git-based deploys with rollbacks (render-docs-1, render-docs-12), infrastructure-as-code versioning via render.yaml blueprints (render-docs-9, render-docs-29), and ephemeral preview environments for reviewing changes before merge (render-docs-8), plus a Workflows SDK for defining/triggering automation tasks (render-docs-22, render-docs-23). However these features target service/infra deploys rather than a dedicated 'automation' review/approval pipeline, and there's no evidence of versioning or rollback specifically for Workflow SDK tasks or agent-driven automations. Missing for 10: explicit version history/rollback UI for Workflows SDK tasks, an approval/review workflow for automations distinct from git PR review, and independent confirmation of rollback reliability.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Rollbacks”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”
   • [claimed-docs] “The Render SDK for TypeScript provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other TypeScript co…”
   • [claimed-docs] “The Render SDK for Python provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other Python code”

   proof ↗⚑ flag

Cli tooling

1. developerDeploy my project directly from the command line without using a web dashboard

   weight 2 · round to Fly.io
   Fly.io✓fullprobed9/10

   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/”

   proof ↗⚑ flag

   Render✓fullprobed8/10

   Render documents an official CLI to manage services and datastores directly from the terminal, including validating and deploying via render.yaml blueprints, which covers CLI-based deployment without the dashboard. Missing for 10: independent hands-on confirmation of full deploy parity with the dashboard and detailed CLI deploy command examples in the evidence pack.

   • [claimed-docs] “Render CLI”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “Validating `render.yaml` files for Render Blueprints”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

2. developerScaffold and deploy a new project with a single CLI command

   weight 2 · round to Fly.io
   Fly.io✓fullcommunity7/10

   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…”

   proof ↗⚑ flag

   Render~partialprobed6/10

   Render provides a documented CLI ([render-docs-14],[render-docs-27]) and blueprint YAML for defining/deploying full architectures ([render-docs-9],[render-docs-29]) plus render.yaml validation via CLI ([render-docs-28]), suggesting a scaffold-and-deploy workflow is possible, but no evidence shows a single CLI command that scaffolds a new project from scratch (e.g., a 'create' or 'init' command generating boilerplate) — CLI docs focus on managing existing services/datastores rather than project scaffolding. missing for 10: explicit CLI scaffold/init command for new projects, end-to-end single-command example, independent hands-on confirmation of scaffold+deploy in one step.

   • [claimed-docs] “Render CLI”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [claimed-docs] “Validating `render.yaml` files for Render Blueprints”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

3. developerDevelop and test my app locally using a simulator that matches the production runtime

   weight 2 · round drawn
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render—none0/10

   Render's evidence covers cloud deploys, ephemeral previews, and Docker support, but there is no mention of a local simulator or emulator that replicates the production runtime for local development/testing. Missing for 10: a documented local dev/simulator tool, parity guarantees between local and production runtime, and any independent confirmation of local testing workflows.

   ⚑ flag

Deployment strategies

1. developerDeploy applications packaged as Docker containers

   weight 2 · round to Render
   Fly.io!disputedcontradicted5/10

   Fly.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…”

   proof ↗⚑ flag

   Render✓fullcommunity8/10

   Render explicitly documents Docker support as a first-class deployment method, corroborated by independent community reports of 'great docker support.' Missing for 10: hands-on walkthrough of a full Docker deploy workflow and more detailed docs on Dockerfile-based build configuration.

   • [claimed-docs] “Docker support”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”

   proof ↗⚑ flag

2. devops-leadRoll out new deployments incrementally to reduce blast radius

   weight 2 · round drawn
   Fly.io—none0/10

   The 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.”

   proof ↗⚑ flag

   Render—none0/10

   Evidence covers deploys, rollbacks, autoscaling, and previews, but nothing describes staged/canary/incremental rollout mechanisms (e.g., percentage-based traffic shifting, blue-green, or gradual rollout to limit blast radius) — only full rollbacks after the fact are mentioned.

   • [claimed-docs] “Rollbacks”
   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”

   proof ↗⚑ flag

Git integration

1. developerAutomatically deploy my app on every Git push

   weight 3 · round to Render
   Fly.io—none0/10

   Fly.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.”

   proof ↗⚑ flag

   Render✓fullcommunity8/10

   Render's docs explicitly state 'Connect your repo and ship with every push' and support rollbacks, environment variables, and Blueprint YAML deploys, and community feedback corroborates ease of git-based deployment vs. competitors like Heroku. missing for 10: no hands-on trace of the auto-deploy pipeline (e.g. build logs, webhook triggers) beyond the marketing/docs claim, and no independent verification of push-to-deploy latency or reliability.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Rollbacks”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”
   • [community] “One of the biggest appeals to me is their simplified, docker-compose like approach to infrastructure as code... I still like to have it as c…”

   proof ↗⚑ flag

2. developerDeploy my app by simply connecting my repo without manual build configuration

   weight 3 · round to Render
   Fly.io~partialcommunity4/10

   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…”

   proof ↗⚑ flag

   Render✓fullcommunity8/10

   Render's docs explicitly advertise connecting a repo and shipping on every push, with Docker support, auto-detected builds, custom domains, TLS, and rollbacks, and community feedback corroborates the ease of setup compared to alternatives like Heroku/Fly.io. Missing for 10: no hands-on step-by-step account of zero-config build detection succeeding for varied stacks, and one community note mentions past outages unrelated to build config but slightly tempering overall reliability confidence.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Docker support”
   • [claimed-docs] “Custom domains”
   • [claimed-docs] “Rollbacks”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”
   • [community] “Render had some pretty bad outages (10+ hours) and couple shorter ones just couple months ago, so it's not perfect either. But anyways I hav…”

   proof ↗⚑ flag

Infra as code

1. devops-leadDefine, deploy, and version my entire architecture with a single configuration file

   weight 2 · round to Render
   Fly.io~partialclaimed6/10

   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.”

   proof ↗⚑ flag

   Render✓fullcommunity8/10

   Render explicitly documents Blueprints via a single render.yaml file to define, deploy, and version an entire multi-service architecture, with CLI validation support and community corroboration of its docker-compose-like IaC approach. missing for 10: independent hands-on validation of complex multi-service blueprint deployments and versioning workflows at scale, and more detail on drift detection/rollback of the YAML config itself.

   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [claimed-docs] “Validating `render.yaml` files for Render Blueprints”
   • [community] “One of the biggest appeals to me is their simplified, docker-compose like approach to infrastructure as code... I still like to have it as c…”

   proof ↗⚑ flag

Manual deploy

1. developerDeploy a project by uploading a folder of files directly, with no Git repo required and the new deployment kept private until I choose to publish it

   weight 2 · round to Fly.io
   Fly.io~partialclaimed4/10

   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.”

   proof ↗⚑ flag

   Render—none0/10

   Evidence emphasizes Git-connected deploys ('Connect your repo and ship with every push') and Docker/CLI/YAML workflows, but nothing in the pack describes uploading a folder of files without a Git repo or a private-until-published deployment flow. missing for 10: any mention of folder/file upload deploy method, no-Git deploy path, or private-draft-then-publish deployment state.

   • [claimed-docs] “Connect your repo and ship with every push.”

   proof ↗⚑ flag

Preview envs

1. developerGet ephemeral full-stack preview environments for every pull request

   weight 2 · round to Render
   Fly.io—none0/10

   Evidence 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.

   ⚑ flag

   Render~partialclaimed6/10

   Render explicitly advertises 'ephemeral previews of your entire application architecture for every change' tied to blueprint/YAML-defined multi-service architectures, directly matching PR preview environments. However, evidence lacks detail on automatic PR-linking mechanics, teardown behavior, or independent/hands-on confirmation of the feature working end-to-end. missing for 10: hands-on/independent verification of PR-triggered preview creation and teardown, details on preview environment lifecycle and limitations, confirmation of full-stack (DB+services) parity in previews.

   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”

   proof ↗⚑ flag

2. developerGet an automatic preview URL for every pull request

   weight 3 · round to Render
   Fly.io—none0/10

   No evidence pack mentions PR-preview environments, GitHub integration, or automatic preview URLs for pull requests; only deployment via flyctl/fly launch is documented.

   ⚑ flag

   Render~partialclaimed5/10

   Render docs mention 'ephemeral previews of your entire application architecture for every change' (render-docs-8), which implies PR preview environments, but there is no explicit mention of automatic PR-linked preview URLs, GitHub PR integration, or hands-on confirmation of this workflow. missing for 10: explicit PR-preview-URL documentation, GitHub/GitLab PR status-check integration details, independent/hands-on confirmation of preview links appearing on pull requests.

   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”

   proof ↗⚑ flag

Rollback recovery

1. developerRoll back a deployed service to any previous version in one click

   weight 3 · round to Render
   Fly.io~partialprobed4/10

   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/”

   proof ↗⚑ flag

   Render~partialclaimed5/10

   Render's docs explicitly list 'Rollbacks' as a feature, confirming the capability exists, but the evidence pack gives only a title reference with no detail on the one-click UX, scope (any previous version vs. just last), or independent/hands-on confirmation. Missing for 10: detailed docs on rollback flow/UI, confirmation of 'any previous version' vs limited history, and community/hands-on verification that rollback works as described.

   • [claimed-docs] “Rollbacks”

   proof ↗⚑ flag

Templates

1. developerDeploy one-click templates and starters for common use cases

   weight 1 · round drawn
   Fly.io—none0/10

   Evidence 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.”

   proof ↗⚑ flag

   Render—none0/10

   Evidence covers Blueprints (render.yaml) for defining architecture, but there is no mention of a one-click template gallery or pre-built starters for common use cases (e.g., a 'Deploy to Render' button library or template marketplace).

   ⚑ flag

Environments

1. developerSpin up unlimited isolated environments so my whole team can ship simultaneously

   weight 1 · round drawn
   Fly.io~partialcommunity6/10

   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…”

   proof ↗⚑ flag

   Render~partialclaimed6/10

   Render documents ephemeral preview environments of the entire application architecture for every change (render-docs-8) and blueprint-based multi-service definitions (render-docs-9, render-docs-29), which supports spinning up isolated environments for teams. However, there's no explicit claim of 'unlimited' environments, no discussion of per-developer/team concurrency limits or plan-based caps, and no independent evidence validating scale under real team usage. Missing for 10: explicit unlimited-environment guarantees, team-scale concurrency evidence, independent/hands-on confirmation of simultaneous multi-team usage.

   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [claimed-docs] “Prevent non-production environments from accessing production services.”

   proof ↗⚑ flag

Scaling continuity

1. developerRely on the same core APIs and primitives from prototype through massive scale, without rearchitecting or migrating platforms as usage grows

   weight 2 · round drawn
   Fly.io~partialclaimed6/10

   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.”

   proof ↗⚑ flag

   Render~partialcommunity6/10

   Render offers consistent primitives (Blueprint YAML, autoscaling to 100x bursts, managed databases, CLI/API) that in principle span prototype to scale without platform migration, and community comments praise its Docker/IaC simplicity versus Heroku. However, evidence lacks concrete case studies of a single app scaling from prototype to massive production scale on unchanged APIs, and community notes cite significant outages, which raises reliability concerns at scale. missing for 10: a documented large-scale production case study showing zero re-architecture, independent verification of scaling claims beyond marketing copy, and resolution of the outage concerns raised by users.

   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”
   • [community] “One of the biggest appeals to me is their simplified, docker-compose like approach to infrastructure as code... I still like to have it as c…”
   • [community] “Render had some pretty bad outages (10+ hours) and couple shorter ones just couple months ago, so it's not perfect either. But anyways I hav…”

   proof ↗⚑ flag

Secrets management

1. devops-leadManage team-level access, secrets, and environment variables centrally

   weight 2 · round drawn
   Fly.io~partialclaimed5/10

   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.”

   proof ↗⚑ flag

   Render~partialclaimed5/10

   Render documents environment variables, environment-group isolation between production and non-production, and OIDC-based short-lived credentials in place of long-lived API keys, which supports centralized secrets/config management. However, there is no evidence of team-level role-based access control, member invitation/permission management, or a dedicated secrets manager UI, so the 'team-level access' part of the story is unproven. Missing for 10: team/RBAC management docs, explicit secrets-vault feature, multi-user permission controls.

   • [claimed-docs] “Environment variables”
   • [claimed-docs] “Prevent non-production environments from accessing production services.”
   • [claimed-docs] “Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens fo…”

   proof ↗⚑ flag

Tool continuity

1. developerKeep using my existing Git, CI, editor, and framework workflows without adopting proprietary tooling

   weight 2 · round drawn
   Fly.io~partialclaimed6/10

   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!”

   proof ↗⚑ flag

   Render~partialprobed6/10

   Render supports connecting existing Git repos, Docker images, and standard CI-triggered deploys (render-docs-1, render-docs-2), plus a CLI and REST API for scripting into existing workflows (render-docs-14, render-docs-15, render-probe-4). However, it also pushes proprietary IaC (render.yaml blueprints) as the primary way to define infrastructure (render-docs-9), which is an additional tool developers must adopt rather than pure compatibility with existing Terraform/Pulumi-style workflows; community notes confirm this is a distinct 'infra-as-code' approach rather than a no-lock-in passthrough (render-comm-2). No specific evidence about editor integrations or framework-agnostic guarantees beyond generic build support. Missing for 10: evidence on editor/IDE integration, confirmation that framework choices are unconstrained, and independent confirmation that CI systems (e.g., GitHub Actions, CircleCI) integrate natively without Render-specific config.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Docker support”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Render CLI”
   • [claimed-docs] “REST API”
   • [community] “One of the biggest appeals to me is their simplified, docker-compose like approach to infrastructure as code... I still like to have it as c…”
   • [probe] “official CLI documented at https://render.com/docs/cli”

   proof ↗⚑ flag

Agent runtime

1. ai-native builderGive my coding agent a persistent runtime environment that checkpoints its state automatically while working

   weight 2 · round to Fly.io
   Fly.io✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

   Render—none0/10

   Render offers persistent disks, private services, and coding-agent integrations (MCP server, CLI, skills) but no evidence describes a persistent runtime environment for an agent that automatically checkpoints its state — the closest hits are disk snapshots for a database service (render-docs-35) and short-lived inspection instances (render-docs-32), neither of which is agent-state checkpointing.

   • [claimed-docs] “You can start a short-lived instance of your service to inspect its runtime or run one-off commands without connecting to production.”
   • [claimed-docs] “You can run your own ClickHouse instance as a [private service](private-services) on Render backed by *high performance SSDs* with [automati…”
   • [claimed-docs] “Coding agents”

   proof ↗⚑ flag

Placement latency

1. devops-leadDeploy my application to specific regions closer to my users

   weight 2 · round to Fly.io
   Fly.io✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack covers many Render features (CDN, TLS, autoscaling, CLI, MCP, blueprints) but never mentions region selection, data-center choice, or geographic deployment options for services. Region-based deployment is a plausible and common capability for a cloud application platform, so the axis applies, but no evidence supports it here.

   ⚑ flag

2. devops-leadRely on automatic compute placement near backend data to optimize latency

   weight 2 · round to Fly.io
   Fly.io~partialclaimed4/10

   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…”

   proof ↗⚑ flag

   Render—none0/10

   No evidence describes automatic compute placement based on proximity to backend data stores or latency-aware scheduling; Render's docs mention region selection and private networking (render-docs-10) but nothing about automatic co-location of compute with data for latency optimization.

   ⚑ flag

Realtime connections

1. developerHandle persistent WebSocket connections from within edge/serverless functions for real-time apps

   weight 2 · round to Fly.io
   Fly.io~partialclaimed4/10

   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…”

   proof ↗⚑ flag

   Render—none0/10

   Render's evidence pack describes persistent web services, background workers, docker deployments, autoscaling, etc., but contains no mention of edge functions or serverless functions at all, nor any WebSocket-specific capability tied to such a compute model. Without evidence of an edge/serverless function offering supporting persistent WebSockets, this applicable axis is unmet.

   ⚑ flag

Runtime compatibility

1. developerRun unmodified Node.js code and npm packages in edge/serverless functions instead of a restricted runtime subset

   weight 3 · round to Fly.io
   Fly.io~partialclaimed4/10

   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!”

   proof ↗⚑ flag

   Render—none0/10

   Render's evidence describes general Docker-based web services, background workers, and autoscaling, but there is no mention of an edge/serverless functions product or any claim about running unmodified Node.js/npm code where competitors impose a restricted runtime subset. The axis is fair to ask of a cloud platform, but no evidence supports it.

   ⚑ flag

Scaling

1. devops-leadDeploy instances that boot in under a second and scale to tens of thousands under load

   weight 2 · round to Render
   Fly.io!disputedcontradicted5/10

   Fly.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…”

   proof ↗⚑ flag

   Render~partialclaimed4/10

   Render documents load-based autoscaling handling '100x traffic bursts and beyond' (render-docs-11), which addresses the scaling-to-large-load portion of the story, but there is no evidence of sub-second boot times or edge-compute cold-start performance anywhere in the pack. missing for 10: sub-second instance boot/cold-start benchmarks, edge-compute deployment model, evidence of tens-of-thousands-instance scale in practice.

   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”
   • [claimed-docs] “Deploy reliable agents and background processes at scale, without wiring up queues, workers, and retry logic.”

   proof ↗⚑ flag

2. devops-leadRely on load-based autoscaling to absorb large traffic bursts automatically

   weight 2 · round to Render
   Fly.io~partialcommunity4/10

   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 …”

   proof ↗⚑ flag

   Render~partialcommunity6/10

   Render's first-party docs explicitly claim 'load-based autoscaling that handles 100x traffic bursts and beyond,' directly matching the story, and community feedback corroborates autoscaling as a real, working feature (though not stress-tested by 100x claims). However, there's no independent evidence or hands-on benchmark validating the 100x burst claim, and community feedback notes past outages, raising some doubt about reliability under extreme load. Missing for 10: independent load-testing evidence, detailed autoscaling configuration/limits documentation, and confirmation the outages weren't autoscaling-related failures.

   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”
   • [community] “Render had some pretty bad outages (10+ hours) and couple shorter ones just couple months ago, so it's not perfect either. But anyways I hav…”

   proof ↗⚑ flag

Serverless runtime

1. developerRun my code on a global edge network close to end users

   weight 3 · round to Fly.io
   Fly.io✓fullcommunity8/10

   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…”

   proof ↗⚑ flag

   Render—none0/10

   Evidence shows Render offers a global CDN only for caching static assets (render-docs-19), not for running arbitrary application code at edge locations; services are deployed to specific regions rather than a distributed edge-compute network. No evidence pack items describe edge functions, edge workers, or code execution distributed globally near end users.

   • [claimed-docs] “Serve static assets faster with caching powered by Render’s global CDN.”

   proof ↗⚑ flag

2. developerDeploy serverless functions and full-stack apps with no servers to manage

   weight 3 · round to Render
   Fly.io!disputedcontradicted5/10

   Fly.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…”

   proof ↗⚑ flag

   Render~partialcommunity6/10

   Render clearly delivers full-stack app deployment with no server management (git-push deploys, Docker support, managed databases, autoscaling, YAML-based architecture, global CDN/TLS) per render-docs-1,8,9,11,19,20. However, there is no evidence of a dedicated 'serverless functions' product (e.g., FaaS-style short-lived function execution) distinct from its web services/workers model. Missing for 10: explicit serverless functions offering, evidence of per-invocation/scale-to-zero function execution, independent hands-on confirmation of serverless function deploys.

   • [claimed-docs] “Connect your repo and ship with every push.”
   • [claimed-docs] “Iterate quickly with ephemeral previews of your entire application architecture for every change.”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Load-based autoscaling that handles 100x traffic bursts and beyond”
   • [claimed-docs] “Serve static assets faster with caching powered by Render’s global CDN.”
   • [claimed-docs] “Free TLS certificates for every domain, including wildcards.”
   • [community] “Render.com is such a better option these days (and I've been a huge Heroku fan since the beginning). Render has better support and pricing. …”
   • [community] “One of the biggest appeals to me is their simplified, docker-compose like approach to infrastructure as code... I still like to have it as c…”

   proof ↗⚑ flag

Workflows

1. developerDeploy durable, long-running workflows as code without manually wiring queues and retries

   weight 2 · round to Render
   Fly.io—none0/10

   Fly.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…”

   proof ↗⚑ flag

   Render✓fullclaimed7/10

   Render explicitly advertises deploying 'reliable agents and background processes at scale, without wiring up queues, workers, and retry logic,' and ships Workflows SDKs for both TypeScript and Python that support defining workflow tasks and triggering runs, directly matching the durable-workflow-as-code story. Missing for 10: independent/hands-on validation of durability guarantees under failure, and deeper documentation of retry/backoff semantics beyond marketing copy.

   • [claimed-docs] “Deploy reliable agents and background processes at scale, without wiring up queues, workers, and retry logic.”
   • [claimed-docs] “The Render SDK for TypeScript provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other TypeScript co…”
   • [claimed-docs] “The Render SDK for Python provides support for: - Defining workflow tasks - Triggering runs of those tasks from your other Python code”

   proof ↗⚑ flag

Access control

1. developerPut simple password protection on a deployed site without standing up a custom auth system

   weight 2 · round drawn
   Fly.io—none0/10

   The 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.”

   proof ↗⚑ flag

   Render—none0/10

   No evidence in the pack mentions basic auth, password protection, or similar site-access-gating features for deployed services; only unrelated deployment, database, CLI, and MCP capabilities are documented.

   ⚑ flag

Ddos waf

1. devops-leadHave DDoS protection and a web application firewall applied to every request by default

   weight 3 · round drawn
   Fly.io—none0/10

   No evidence pack item mentions DDoS protection or a web application firewall being applied by default (or at all); docs cover secrets, scaling, and Machine isolation but never security perimeter features like WAF/DDoS mitigation.

   ⚑ flag

   Render—none0/10

   The evidence pack contains no mention of DDoS protection or a web application firewall (WAF) applied by default or otherwise; Render's docs reference TLS, CDN caching, private networking, and OIDC, but nothing about WAF/DDoS mitigation.

   ⚑ flag

Domains

1. developerAttach custom domains to my deployed services

   weight 2 · round to Render
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render✓fullclaimed7/10

   Render's docs explicitly list "Custom domains" as a feature and also mention free TLS certificates for every domain including wildcards, directly supporting attaching custom domains to services. missing for 10: no independent/hands-on corroboration or detailed walkthrough of the domain-attachment process beyond the doc title reference.

   • [claimed-docs] “Custom domains”
   • [claimed-docs] “Free TLS certificates for every domain, including wildcards.”

   proof ↗⚑ flag

2. developerProgrammatically provision and route custom domains for my own multi-tenant SaaS customers

   weight 2 · round to Render
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render~partialclaimed4/10

   Render documents custom domains with free TLS (including wildcards) and a general REST API/CLI for managing services, which could in principle be used to provision domains programmatically, but no evidence explicitly confirms a domain-provisioning API endpoint or a documented workflow for multi-tenant SaaS customer domain routing. Missing for 10: explicit API/CLI examples for adding/removing custom domains programmatically, and any mention of multi-tenant domain routing patterns or SaaS-specific guidance.

   • [claimed-docs] “Custom domains”
   • [claimed-docs] “Free TLS certificates for every domain, including wildcards.”
   • [claimed-docs] “REST API”
   • [claimed-docs] “Render CLI”

   proof ↗⚑ flag

Env isolation

1. devops-leadIsolate non-production environments from accessing production services

   weight 1 · round to Render
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render~partialclaimed6/10

   Render explicitly advertises the capability ('Prevent non-production environments from accessing production services') and separately offers private networking that keeps internal traffic off the public internet, suggesting environment isolation is achievable via private services/network policies. However, there is no detailed documentation of the mechanism (e.g., specific network policies, per-environment isolation controls) or independent/hands-on verification of this feature working as claimed. missing for 10: detailed first-party docs on how isolation is configured/enforced, independent or hands-on confirmation, edge-case handling (e.g., preview environments).

   • [claimed-docs] “Prevent non-production environments from accessing production services.”
   • [claimed-docs] “Keep internal traffic off the public internet without VPC complexity.”

   proof ↗⚑ flag

Identity

1. devops-leadSecure internal apps, deployments, and agents using my organization's identity provider

   weight 2 · round drawn
   Fly.io—none0/10

   No 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.

   ⚑ flag

   Render—none0/10

   Evidence shows Render can issue short-lived OIDC tokens for its own services to authenticate outbound to Anthropic/OpenAI (render-docs-30), but nothing documents integrating an organization's own identity provider (SSO/SAML/OIDC) to authenticate users or gate access to internal apps, deployments, or agents on Render. No mention of SSO, SAML, Okta/Azure AD integration, or team-level IdP-based access control appears anywhere in the pack.

   • [claimed-docs] “Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens fo…”

   proof ↗⚑ flag

Private networking

1. devops-leadKeep internal service-to-service traffic off the public internet without VPC complexity

   weight 2 · round to Render
   Fly.io~partialclaimed4/10

   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.”

   proof ↗⚑ flag

   Render✓fullclaimed8/10

   Render's docs explicitly claim private networking that keeps internal service-to-service traffic off the public internet without VPC complexity, matching the story almost verbatim, and related isolation features (blocking non-prod access to prod services) reinforce this. Missing for 10: independent/hands-on verification of private networking behavior and technical detail on how internal DNS/routing works.

   • [claimed-docs] “Keep internal traffic off the public internet without VPC complexity.”
   • [claimed-docs] “Prevent non-production environments from accessing production services.”

   proof ↗⚑ flag

Protocols

1. developerServe HTTP, TCP, gRPC, and WebSocket traffic from the same deployed service without separate protocol configuration

   weight 1 · round drawn
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render—none0/10

   No evidence in the pack mentions Render web services supporting multiple protocols (HTTP, TCP, gRPC, WebSocket) from the same service without extra configuration; docs reference general web/private services, custom domains, TLS, and CDN but never protocol-agnostic multi-protocol serving. Missing for 10: any mention of gRPC support, TCP service type, WebSocket handling, or a single service exposing multiple protocols simultaneously.

   ⚑ flag

Tls certs

1. devops-leadGet free, automatically renewing TLS certificates for every domain including wildcards

   weight 3 · round to Render
   Fly.io—none0/10

   No evidence in the pack mentions TLS certificate provisioning, automatic renewal, or wildcard domain support; the docs excerpts focus on Machines, Sprites, MCP servers, and pricing, not certificate management.

   ⚑ flag

   Render✓fullclaimed8/10

   Render's own docs explicitly state free TLS certificates for every domain including wildcards (render-docs-20), directly matching the story, and custom domains are also documented (render-docs-6). Missing for 10: independent/hands-on corroboration of wildcard cert auto-renewal behavior beyond the vendor claim.

   • [claimed-docs] “Free TLS certificates for every domain, including wildcards.”
   • [claimed-docs] “Custom domains”

   proof ↗⚑ flag

Alerting

1. devops-leadSet up alerts that notify me via chat or email when specific conditions are met

   weight 2 · round to Render
   Fly.io—none0/10

   No evidence in the pack of Fly.io offering alerting/notification features (chat or email) tied to conditions or metrics; documentation covers deployment, compute, and infrastructure but not alerting/observability notification setup.

   ⚑ flag

   Render~partialclaimed4/10

   Render supports webhooks to notify other systems on service events (deploy starting, scaling, etc.), which could be routed to chat/email via external integrations, and offers metrics/telemetry streaming to external tools. However, there's no evidence of native alert configuration with custom thresholds/conditions, nor built-in email/chat (Slack) notification channels for alerting. missing for 10: native alerting rules/conditions UI, built-in email/Slack notification channels, documentation of alert-specific configuration beyond generic webhooks and metrics streaming.

   • [claimed-docs] “You can configure *webhooks* for your Render workspace to notify other systems when specific service events occur (such as a deploy starting…”
   • [claimed-docs] “See critical metrics for all of your Render infrastructure from day zero, and stream telemetry to external tools.”

   proof ↗⚑ flag

Metrics dashboards

1. devops-leadBuild custom dashboards combining metrics from any service

   weight 2 · round to Render
   Fly.io—none0/10

   No evidence of a custom dashboarding capability or metrics/observability aggregation feature across services; the evidence pack covers deployment, compute, VMs, and agent 'Sprites' but nothing about building dashboards from metrics.

   ⚑ flag

   Render~partialclaimed4/10

   Render exposes infrastructure metrics and can stream telemetry to external tools (render-docs-13), which implies dashboard-building would need to happen in a third-party system rather than natively combining metrics from 'any service' within Render itself. There's no evidence of a built-in custom dashboard builder or multi-service metric aggregation UI. Missing for 10: native custom dashboard UI, ability to pull metrics from non-Render services, evidence of cross-service dashboard composition, independent confirmation of telemetry export working in practice.

   • [claimed-docs] “See critical metrics for all of your Render infrastructure from day zero, and stream telemetry to external tools.”

   proof ↗⚑ flag

Reliability sla

1. devops-leadCheck a public status page with historical incident postmortems before committing

   weight 2 · round drawn
   Fly.io—none0/10

   The 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 …”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack contains no mention of a public status page or historical incident postmortems for Render; community comments reference past outages but do not reference a status page or postmortem records. This axis applies to any cloud platform a devops-lead would evaluate, but no supporting evidence exists.

   ⚑ flag

2. devops-leadReview a published uptime SLA with defined credits for downtime

   weight 3 · round drawn
   Fly.io—none0/10

   No evidence of a published SLA document with defined uptime percentage or downtime credits; community evidence even shows Fly's status page failing to reflect actual outages, but this is not a documented SLA dispute, just absence of one.

   ⚑ flag

   Render—none0/10

   No evidence pack item references a published SLA document or downtime credit policy; only general outage anecdotes exist, not a formal SLA with credit terms.

   ⚑ flag

3. devops-leadThe guaranteed support response times and escalation paths for my plan tier

   weight 2 · round drawn
   Fly.io—none0/10

   No 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 …”

   proof ↗⚑ flag

   Render—none0/10

   No evidence pack item mentions SLA-backed support response times, escalation tiers, or plan-specific support guarantees; only general product docs, community sentiment, and outage anecdotes are present.

   ⚑ flag

Unified logging

1. developerView all my build, deploy, and runtime logs in one place

   weight 3 · round to Render
   Fly.io—none0/10

   The 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 …”

   proof ↗⚑ flag

   Render~partialclaimed5/10

   Render docs mention viewing critical metrics for infrastructure and streaming telemetry to external tools, implying a centralized dashboard for infrastructure observability, but there is no explicit evidence of a unified view combining build, deploy, and runtime logs specifically. Missing for 10: explicit documentation of a unified logs UI covering build/deploy/runtime logs together, independent/hands-on confirmation of this unified logging experience.

   • [claimed-docs] “See critical metrics for all of your Render infrastructure from day zero, and stream telemetry to external tools.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Render
   Fly.io~partialprobed6/10

   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/”

   proof ↗⚑ flag

   Render~partialprobed7/10

   Render documents a full REST API with OpenAPI spec, a CLI, and an MCP server that exposes actions like triggering deploys and managing services/datastores, indicating broad API-level control mirroring UI capabilities. However, there is no explicit vendor claim or independent verification of 100% feature parity between UI and API/CLI, so some UI-only edge cases may remain unconfirmed. Missing for 10: explicit parity statement covering every UI feature, and independent/hands-on confirmation that no UI-only actions exist.

   • [claimed-docs] “REST API”
   • [probe] “PROBE openapi: HTTP 200 at https://render.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Render CLI”
   • [probe] “official CLI documented at https://render.com/docs/cli”
   • [claimed-docs] “Render's Model Context Protocol (MCP) server enables you to manage your Render infrastructure directly from compatible AI apps, such as Clau…”
   • [claimed-docs] “The Render MCP server now includes a `trigger_deploy` tool that enables you (and your agents) to kick off a new deploy of an existing servic…”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Fly.io—none0/10

   No evidence describes data export tooling, open-format export, or an account/data portability process for Fly.io apps, volumes, or databases; the pack covers deployment, scaling, and infrastructure features but nothing about exporting user data to leave the platform.

   ⚑ flag

   Render—none0/10

   Evidence shows Render supports YAML-based infra-as-code (render.yaml) and a REST API/CLI, which aids portability, but there is no documented feature for exporting full database/service data in open formats or any explicit 'export and leave' capability. missing for 10: documented data export/backup-download tooling, explicit open-format data portability guarantees, and any mention of migrating data out of Render.

   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”
   • [claimed-docs] “Define, deploy, and version your entire architecture with a single YAML file.”
   • [claimed-docs] “Use the Render CLI to manage your Render services and datastores directly from your terminal”
   • [claimed-docs] “Manage your multi-service architecture with a single YAML file.”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Fly.io—none0/10

   Fly.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.

   ⚑ flag

   Render—none0/10

   Render is a closed-source commercial PaaS; no evidence indicates its source code is published under an open license (docs, CLI, SDKs are documented but not shown to be open-source). missing for 10: any evidence of a public open-source repository or license for Render's core platform source.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Fly.io—none0/10

   Fly.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…”

   proof ↗⚑ flag

   Render—none0/10

   Render is a proprietary cloud hosting platform with no evidence of an open-source or self-hostable version of its core service; all evidence describes using Render's own managed cloud, not deploying Render itself on one's own infrastructure.

   ⚑ flag

Cost controls

1. devops-leadSet hard spending limits to control my cloud costs

   weight 2 · round drawn
   Fly.io—none0/10

   No evidence describes hard spending limits, budget caps, or cost-control controls; only pay-as-you-go pricing and cost visibility are mentioned, with community comments criticizing pricing/network costs but no dispute of a spending-limit feature.

   ⚑ flag

   Render—none0/10

   The evidence pack covers deployment, IaC, datastores, CLI/MCP, and pricing-page usability feedback, but contains no mention of hard spending limits, budget caps, or cost-control alerts on Render. This is a fair axis for a cloud platform, but no evidence supports it being delivered.

   ⚑ flag

2. devops-leadReceive migration credits when moving my production infrastructure to a new platform

   weight 1 · round to Render
   Fly.io—none0/10

   No evidence in the pack mentions migration credits or any financial incentive program for switching from another platform; pricing docs only describe pay-as-you-go billing.

   ⚑ flag

   Render✓fullclaimed8/10

   Render explicitly advertises up to $10K in migration credits for moving production infrastructure to their platform, directly matching the story. Missing for 10: details on eligibility criteria/process, independent confirmation from community reports of actually receiving credits.

   • [claimed-docs] “Migrating production infrastructure? Get up to $10K in migration credits.”

   proof ↗⚑ flag

Execution limits

1. 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 drawn
   Fly.io—none0/10

   Fly.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…”

   proof ↗⚑ flag

   Render—none0/10

   No evidence in the pack documents any CPU or wall-clock execution time limits for Render services or functions—there's no mention of request timeouts, background job duration limits, or serverless-style execution caps. Render is positioned as long-running containers/services rather than time-boxed functions, but nothing confirms or denies specific limits a devops-lead could plan around.

   ⚑ flag

Overage fees

1. devops-leadThe exact overage fee schedule for exceeding plan usage limits (bandwidth, invocations, build minutes) before I get billed

   weight 3 · round drawn
   Fly.io—none0/10

   Evidence 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…”

   proof ↗⚑ flag

   Render—none0/10

   No evidence pack item documents an overage fee schedule for bandwidth, invocations, or build minutes; community feedback even notes Render's pricing page requires clicking into each component and isn't fully transparent (render-comm-5). The axis applies to a usage-billed cloud platform, but no supporting documentation exists.

   • [community] “Can you put actual pricing on https://render.com/pricing please? / They are there, but you need to click on each individual component to get…”

   proof ↗⚑ flag

2. devops-leadWhether pricing is per-seat with minimum seat counts that increase cost as my team grows

   weight 2 · round drawn
   Fly.io—none0/10

   Fly.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.”

   proof ↗⚑ flag

   Render—none0/10

   No evidence pack items discuss Render's pricing model, seat-based pricing, or minimum seat counts; community comments only mention pricing being 'easier to understand' or 'slightly better' without detail. Missing for 10: any documentation of per-seat pricing structure, minimum seat requirements, or team-based cost scaling.

   ⚑ flag

Usage billing

1. devops-leadPay only for active compute time rather than idle wall-clock time

   weight 2 · round to Fly.io
   Fly.io✓fullclaimed7/10

   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…”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack contains no documentation of Render's billing granularity (e.g., per-second billing, scale-to-zero for paid services, or idle-time exclusion). Autoscaling (render-docs-11) addresses traffic handling, not billing model, and community comments only discuss pricing clarity, not compute-time-based billing.

   ⚑ flag

2. devops-leadAttached disk/storage auto-grows with usage and I'm billed only for bytes actually written rather than pre-provisioned capacity

   weight 2 · round to Fly.io
   Fly.io✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack only mentions disks in passing (automatic daily snapshots for ClickHouse) but contains no documentation of auto-growing disk capacity or usage-based billing per byte written; Render's disk docs elsewhere describe fixed pre-provisioned sizes, but even setting that aside, this pack has no evidence supporting the story's specific claim.

   • [claimed-docs] “You can run your own ClickHouse instance as a [private service](private-services) on Render backed by *high performance SSDs* with [automati…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Fly.io
   Fly.io~partialclaimed6/10

   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.”

   proof ↗⚑ flag

   Render—none0/10

   No evidence pack items mention region selection, data residency, or geographic deployment location options for Render services or data storage. missing for 10: region selection docs, data residency policy, multi-region deployment options.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Fly.io—none0/10

   The 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…”

   proof ↗⚑ flag

   Render—none0/10

   No evidence of data retention policies, deletion controls, or privacy/compliance documentation specific to AI usage or data lifecycle management; evidence covers deployment, MCP, CLI, and infra features but nothing on retention/deletion controls.

   ⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Fly.io—none0/10

   No evidence in the pack mentions telemetry collection, usage tracking, or any opt-out mechanism/settings for Fly.io products or CLI; the docs cover deployment, scaling, and infrastructure features but never address analytics/telemetry controls.

   ⚑ flag

   Render—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for Render's own product; this is a fair question for a cloud platform but no documentation or community evidence confirms such a setting exists.

   ⚑ flag

Cdn assets

1. developerServe static assets faster using a global CDN with edge caching

   weight 2 · round to Render
   Fly.io—none0/10

   Evidence 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…”

   proof ↗⚑ flag

   Render✓fullcommunity8/10

   Render explicitly documents serving static assets faster via caching powered by its global CDN, directly matching the story, plus supporting free TLS/custom domains for static sites and community corroboration of free static site hosting. Missing for 10: independent benchmarks of CDN performance and details on edge cache configuration/invalidation controls.

   • [claimed-docs] “Serve static assets faster with caching powered by Render’s global CDN.”
   • [claimed-docs] “Free TLS certificates for every domain, including wildcards.”
   • [community] “Render had some pretty bad outages (10+ hours) and couple shorter ones just couple months ago, so it's not perfect either. But anyways I hav…”

   proof ↗⚑ flag

Integrations

1. 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 Render
   Fly.io~partialclaimed4/10

   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.”

   proof ↗⚑ flag

   Render~partialclaimed6/10

   Render auto-provisions managed Postgres/Redis and injects env vars/connection strings between services, and offers OIDC-based short-lived credential auth to select external providers (Anthropic, OpenAI) instead of long-lived API keys, reducing manual credential wiring. However, evidence doesn't show broad native SDK bindings for arbitrary third-party APIs/storage beyond Render's own managed services and a couple of AI providers. Missing for 10: evidence of a wide addon/integration marketplace or generic client-library bindings for common external SaaS APIs, independent verification of reduced boilerplate claims.

   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”
   • [claimed-docs] “Low-latency in-memory storage ideal for shared caches and job queues.”
   • [claimed-docs] “Keep internal traffic off the public internet without VPC complexity.”
   • [claimed-docs] “Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens fo…”
   • [claimed-docs] “Environment variables”

   proof ↗⚑ flag

Kv cache

1. developerUse a Redis-compatible key-value store for low-latency caching and job queues

   weight 2 · round to Render
   Fly.io—none0/10

   The 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.

   ⚑ flag

   Render✓fullclaimed7/10

   Render docs explicitly advertise a 'Low-latency in-memory storage ideal for shared caches and job queues' managed datastore offering (Render Key Value, Redis-compatible), alongside general managed database docs with HA and recovery features. Missing for 10: explicit confirmation of Redis protocol compatibility details, independent hands-on benchmarks, and specifics on persistence/eviction configuration.

   • [claimed-docs] “Low-latency in-memory storage ideal for shared caches and job queues.”
   • [claimed-docs] “Provision flexible datastores with advanced recovery features.”
   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”

   proof ↗⚑ flag

Object storage

1. developerPersist user-generated uploads using built-in object storage

   weight 2 · round drawn
   Fly.io—none0/10

   Evidence 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 …”

   proof ↗⚑ flag

   Render—none0/10

   The evidence pack shows Render offering managed databases, in-memory caches, and disk-backed private services (e.g., ClickHouse with disk snapshots), but nowhere mentions a built-in object storage product (S3-like) for arbitrary user uploads. No documentation, blog, or changelog item describes an object storage bucket/service.

   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”
   • [claimed-docs] “Low-latency in-memory storage ideal for shared caches and job queues.”
   • [claimed-docs] “Provision flexible datastores with advanced recovery features.”
   • [claimed-docs] “You can run your own ClickHouse instance as a [private service](private-services) on Render backed by *high performance SSDs* with [automati…”

   proof ↗⚑ flag

Relational db

1. developerProvision a fully-managed Postgres database with point-in-time recovery, replicas, and high availability

   weight 3 · round to Render
   Fly.io!disputedcontradicted3/10

   Fly.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…”

   proof ↗⚑ flag

   Render✓fullclaimed8/10

   Render's official docs directly state fully-managed Postgres with point-in-time recovery, read replicas, and high availability, plus general datastore recovery features and disk snapshotting for other stores, matching the story closely. Missing for 10: independent/hands-on corroboration of PITR and replica behavior in production, and more detail on HA failover mechanics.

   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”
   • [claimed-docs] “Provision flexible datastores with advanced recovery features.”

   proof ↗⚑ flag

2. developerQuery a serverless SQL database directly from my code with no connection management

   weight 2 · round drawn
   Fly.io—none0/10

   Fly.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”

   proof ↗⚑ flag

   Render—none0/10

   Render's evidence only shows traditional fully-managed Postgres/datastores with point-in-time recovery and replicas (render-docs-3, render-docs-21), which require standard connection management — there is no evidence of a serverless SQL query interface (e.g., HTTP-based driver) that eliminates connection handling.

   • [claimed-docs] “Deploy fully-managed databases with point-in-time recovery, read replicas, and high availability.”
   • [claimed-docs] “Provision flexible datastores with advanced recovery features.”

   proof ↗⚑ flag