Dora NodaMid-2026 platform comparisons put two PaaS vendors that once looked interchangeable on opposite trajectories. One is sprinting. The other is tidying the books.
On one side, Render is telling a growth story — a $1.5 billion valuation and 100%+ year-over-year revenue growth in the same mid-2026 comparisons, with pricing pages and changelogs that keep expanding the surface area. On the other, Fly.io is pegged at roughly $11M in annual recurring revenue with zero open roles on its careers page, and its last 18 months of product signals point in a different direction: the Hobby, Launch, and Scale subscription plans deprecated for new customers in October 2024, replaced by pure per-second usage billing, followed by new billing line items added through early 2026.
Neither number alone proves anything — ARR estimates from platform comparisons are not audited filings, and a hiring freeze can be discipline as easily as distress. But the shape of the two stories matters if you are about to migrate a production stack onto one of them. One shape says "we are investing ahead of demand." The other says "we are optimizing the installed base."
This post gives you a way to read that shape for any PaaS before you bet on it: a five-signal vital-signs checklist you can run in an afternoon, a scored walkthrough applying it to Fly.io's actual 2024-2026 moves, a contrast row for Render, and the honest hedge that beats multi-cloud complexity — an exit path built on open APIs, standard containers, and software you can self-host if the vendor's story changes.
Two PaaS, two trajectories — the numbers up front
Before the checklist, put the two snapshots side by side. You came for the title's claim — here it is, with the caveat that all ARR and valuation figures are mid-2026 platform-comparison estimates, not SEC filings.
| Signal | Fly.io (mid-2026 snapshot) | Render (mid-2026 snapshot) |
|---|---|---|
| Scale narrative | ~$11M ARR (platform-comparison estimate) | ~$1.5B valuation, 100%+ YoY revenue growth (same comparison set) |
| Hiring signal | Zero open roles listed | Actively hiring / expanding headcount narrative |
| Plan structure (2024-2026) | Deprecated Hobby/Launch/Scale for new customers Oct 2024 → pure per-second usage billing; ~$3.32/mo for always-on shared-cpu-1x/512MB, ~$5/GB RAM baseline, plus new billing lines in early 2026 | Fixed-tier workspace pricing (Starter $7/mo to Pro $450/mo); April 2026 workspace overhaul kept tiered packaging |
| Pricing motion | Adding metered line items on existing base | Repackaging tiers to capture team-size expansion |
| Reading | Optimizing monetization of current tenants | Investing to grow the tenant base |
The table is not a verdict on Fly.io as a product. Teams run serious workloads on Fly Machines today and will tomorrow. It is a lens: when a vendor stops competing on "come build here" and starts competing on "pay more precisely for what you already run," that is the moment to audit before you migrate toward it.
Why vendor health is your infrastructure problem
Moving onto a PaaS is not like switching a library. It rewires four things that are expensive to rewire again:
- Build and deploy coupling. Your CI pushes to their build pipeline, their registry, their release API. Every
fly deployorrender.yamlis a line of vendor-specific glue. - Network and identity. Custom domains, TLS certificates, private networking, and secrets all live in the vendor's control plane. Migrating means re-issuing certs, re-cutting DNS, and re-scoping secrets.
- Data gravity and egress. Databases, object storage, and logs accumulate where the app runs. Egress fees and dump/restore windows make "just move the data" a weekend you will not get back.
- Operational muscle memory. Your runbooks, dashboards, and on-call playbooks learn the vendor's failure modes. Swapping vendors swaps the failure modes before the team has learned the new ones.
That is why "we'll multi-cloud if it gets bad" is not a hedge. Multi-cloud doubles every integration above. The real hedge is cheaper and more honest: keep the ability to leave without replatforming. More on that in the last section — it is the second half of the promise in the title.
The five vital signs — your audit checklist
Run these five in order. Each one has a concrete place to look, a green flag, and a red flag. No single signal is disqualifying; two or three reds pointing the same direction is the pattern you are looking for.
1. Job-board activity — is the vendor still hiring for the future?
Where to look: fly.io/careers, render.com/careers, Lever/Greenhouse boards, LinkedIn "People" headcount trend. Check both engineering and go-to-market roles.
Green flag: Open roles in product, infrastructure, and support — especially platform and reliability. Headcount growing quarter over quarter.
Red flag: Zero open roles for multiple quarters while competitors are hiring, or a careers page that redirects to a generic "we'll post again soon" message. A hiring freeze can be healthy discipline, but combined with other signals it reads as "staff to the base, not to growth."
Why it matters: A PaaS is mostly people. If the team that builds the platform is not growing, the platform's surface area cannot grow either — at best it is being maintained.
2. Pricing-page churn — who is the new pricing designed for?
Where to look: Wayback Machine snapshots of /pricing, the vendor's pricing blog posts, and the billing docs. Compare October 2024, January 2026, and today.
Green flag: Pricing changes that lower the cost of starting (cheaper entry tier, more generous free allowance) or that add a clear new capability at a clear price.
Red flag: Removing packaged plans in favor of pure metered billing, adding new billable line items without adding new capabilities, or repricing that makes the same workload cost more without a single deploy changing. Fly.io's October 2024 deprecation of Hobby/Launch/Scale for new customers in favor of usage-only billing fits this pattern — it simplifies the vendor's packaging while pushing forecasting work onto the tenant.
Why it matters: Pricing is strategy in public. "Optimize the installed base" pricing and "grow the base" pricing look different on the page before they look different in the product.
3. Changelog cadence — what shipped, and for whom?
Where to look: fly.io/changelog (now at fly-changelog.fly.dev), render.com/changelog, community.fly.io release notes, GitHub releases for open components.
Green flag: Monthly or more frequent entries that ship tenant-visible capabilities — new regions, new instance shapes, new platform primitives.
Red flag: A changelog dominated by billing, compliance, or internal-migration entries for multiple quarters, with few or no new platform capabilities for tenants.
Why it matters: A PaaS that is not shipping platform surface is, by definition, not compounding your leverage for staying. You can quantify this: count changelog entries in the last 90 days and tag each as "tenant capability" vs "billing/ops/internal."
4. Forum and support responsiveness — how fast does the community get unstuck?
Where to look: community.fly.io, Render Community, status pages, and the vendor's GitHub issue response times. Sort by "latest" and sample 20 threads where a user reports a real problem.
Green flag: Staff replies within a business day, public postmortems for incidents, and community answers that reference current docs.
Red flag: Multi-day staff response times, growing tail of unanswered threads, or forum replies that link to docs for features that no longer exist at that URL. A forum is a leading indicator because it is where the long tail of tenants — not just the loudest on X — shows up when something breaks.
Why it matters: Support load is where a hiring freeze shows up first. Fewer hands, same ticket volume, slower answers.
5. Plan deprecations and grandfathering — what happens to the tenants who are already there?
Where to look: Deprecation notices, migration guides for deprecated plans, and the fine print on grandfathering. Ask: "If I had signed up 18 months ago, what would I be paying today for the same workload?"
Green flag: Deprecated plans are grandfathered with a clear migration path and price protection, or replacements are strictly cheaper for the same shape.
Red flag: Hard cutover for new customers with no grandfathered path forward, or deprecations that remove the packaging that made costs predictable (e.g., flat subscription → pure usage metering with new line items layered on).
Why it matters: Deprecations tell you how the vendor treats its existing tenants when strategy shifts. That is the best predictor of how it will treat you 18 months after you migrate.
Scoring Fly.io through the checklist — a worked example
Apply the five signals to Fly.io's public record from October 2024 through mid-2026. Scores are deliberately coarse — green / yellow / red — because the point is pattern, not precision.
| # | Vital sign | Fly.io evidence (2024-2026) | Score |
|---|---|---|---|
| 1 | Job-board activity | Mid-2026 snapshots show zero open roles; platform comparisons contrast with Render's hiring narrative | 🔴 Red |
| 2 | Pricing-page churn | Hobby/Launch/Scale deprecated Oct 2024 for new customers; pure per-second usage billing since; new billing line items added early 2026 | 🔴 Red |
| 3 | Changelog cadence | Changelog exists and is active; mix in 2025-2026 leans more toward runtime/billing/ops entries than new tenant-facing primitives (verify on fly-changelog.fly.dev for your window) | 🟡 Yellow |
| 4 | Forum responsiveness | community.fly.io remains active with staff participation; response-time tail is worth sampling directly for your workload's tag | 🟡 Yellow |
| 5 | Plan deprecations | Packaged subscriptions removed for new customers; usage-only metering pushes forecasting onto tenants; no flat-fee predictability package replaced them | 🔴 Red |
How to read it: Three reds, two yellows, zero greens is not "Fly.io is failing." It is "Fly.io's strategy since late 2024 is consistent with optimizing the installed base, not sprinting for new adoption." That strategy can be perfectly rational for Fly.io — and still be the wrong moment for you to migrate a new production stack onto it, because you would be joining a base being optimized, not a platform being expanded.
Render contrast row: On the same checklist for the same window, Render scores the opposite shape — open hiring, tiered workspace packaging that preserves predictability (Starter $7/mo, Standard $25/mo, Pro to $450/mo), and an April 2026 workspace overhaul framed as retention/expansion rather than metering refinement. Whether that packaging wins on price for your workload is a separate bill-model question; on strategy it reads as "grow the base."
Honesty note: Treat every ARR and headcount figure here as a directional estimate from mid-2026 platform comparisons, not a filed number. The checklist works even if the estimates are off by 30% — you are pattern-matching across five signals, not betting on one leaked spreadsheet.
The honest hedge: exit paths beat multi-cloud
If the checklist above could be wrong — and it can, because hiring and pricing are lagging indicators — the responsible move is not to add multi-cloud complexity. Multi-cloud means two deploy pipelines, two network models, two failure domains to learn, and twice the integration surface to keep current. Most teams that try it end up with one primary and one stale shadow.
The honest hedge is portability you can test before you need it. Before migrating onto any PaaS, verify these six:
| Exit-path check | What "good" looks like | How to test it in an afternoon |
|---|---|---|
| Open API coverage | Every console action has a documented API equivalent (flyctl/render API docs) | Script a deploy, a scale, and a rollback without touching the UI |
| OCI-standard containers | Your app runs as a standard linux/amd64 (and ideally linux/arm64) image, not a proprietary runtime | docker run the built image locally; push the same image to two registries |
| Infra as code | App, service, volume, and env definitions live in versioned YAML/Terraform you own | git clone on a fresh machine and recreate the stack from code |
| Data export without negotiation | Database dumps, volume snapshots, and log exports are self-serve and documented | Take a production-shaped backup and restore it outside the vendor |
| Detachable networking | Domains, TLS, and private networking can move without re-architecting | Point a staging domain at a second provider with the same image |
| A real self-hostable alternative exists | The same workload can run on Kubernetes you own, with the same image | Deploy the image to a single-node k3s or a BYO-account fleet |
That last row is where the 2026 BYO-account wave earns its mention. Tools like Edka (437 points on HN for a ~2-minute Hetzner cluster in your own account), Porter, or an Apache-2.0 control plane like Bex.co are not "multi-cloud" — they are the other copy of your stack on hardware you own, running the same OCI images behind the same Gateway API. Edka's four-layer model (provisioning → add-ons → applications → deployments) and Bex's push-a-repo-get-a-URL PaaS on Cluster API-provisioned Hetzner both leave the servers, volumes, and invoices in your Hetzner account. If the hosted PaaS you chose reprices, stalls, or simply stops being the right fit, the exit is not a replatform — it is a DNS cutover to an image that already ran elsewhere.
The test that makes this real is not a migration guide. It is kubectl on a staging cluster you provisioned in your own account, running the same image you pushed yesterday, with data you restored from the PaaS's own export. If that works, the vendor-health question stays strategic instead of existential.
Bet on portability, not predictions
No checklist predicts the future. Fly.io could reopen hiring next quarter and ship a wave of tenant-facing primitives that flips every yellow to green. Render could reprice in a way that makes its own base harder to forecast. The point of auditing is not to call a winner — it is to avoid making an irreversible bet on a story that is already pointing the other way.
If you take one thing from this post, make it procedural: before the next migration, spend an afternoon on the five vital signs, score the vendor on a coarse green/yellow/red, and then spend the next afternoon proving you can run the same image outside that vendor. The first tells you whether to go. The second tells you how much it costs if you are wrong.
That is the only hedge that does not depend on the vendor surviving.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. The control plane is Apache-2.0 and self-hostable, so your exit path is not a promise but a repo you can run. Star the repo on GitHub or deploy your first app today.