Free-for.dev is a shortlist, not a promise of zero-cost production
A critical guide to reading free developer tiers, verifying current terms, and separating prototype savings from operational risk.
What the Free-for.dev index can—and cannot—tell you
Free-for.dev is best read as an opinionated map of candidates. It can show where to look; it cannot prove that a quota is current, suitable for your region, or safe for your workload. A small project may need source hosting, CI, deployment, DNS, storage, observability, email, authentication, testing, and security tooling. Those services live in separate product ecosystems, and their free plans use different units, regions, eligibility rules, and overage behavior.
The repository ripienaar/free-for-dev is explicitly scoped to SaaS, PaaS, and IaaS offerings useful to DevOps and infrastructure developers. Its README says the list has been shaped by pull requests, reviews, and work from more than 1,600 people. GitHub’s API currently reports roughly 130K stars and a push on 28 July 2026. That makes it a substantial community index, not a live contract with every provider named in it.
Free tier is a bundle of conditions
A quota without its conditions is not a useful engineering fact. For every candidate, record whether the offer is permanent or time-limited, whether a credit card or identity check is required, which regions and account types qualify, and how the limit resets. Then ask what happens at the boundary: does the service reject requests, throttle them, retain an invoice, suspend a project, or enable paid usage?
Also record the exit path. Can you export the database, logs, objects, build configuration, DNS records, and alert rules? Can another provider consume the same format? A generous free tier can still be an expensive dependency if the data model and operational knowledge are trapped in one control plane.
Use the index to build a delivery map
The README spans major cloud providers, APIs and data, CI/CD, testing, security and PKI, authentication, logging, monitoring, email, DNS, IaaS, managed data, storage, tunnelling, payments, and web hosting. Treat those headings as stages of a delivery map rather than a shopping list.
For a static site, a sensible evaluation may cover repository integration, build minutes, preview deployments, custom domains, cache invalidation, rollback, and asset behavior. For an API, it should cover authentication, latency, rate-limit responses, error formats, data residency, and a way to leave. For observability, it should cover event volume, retention, sampling, alert delivery, and export. The right service is the one whose boundary behavior is understood, not the one with the largest headline number.
A small test beats a large comparison table
Before moving a production workload, run a bounded test. Deploy one representative build and exercise a failed build and rollback. Send enough API traffic to observe normal and throttled responses. Ingest structured logs and check whether fields are truncated or delayed. Export a sample of the data and restore it somewhere else. Document the account, region, date, plan, measured limits, and observed failure modes.
This is also where the list’s editorial nature matters. Free-for.dev has a stated focus on free tiers rather than free trials and excludes services that reserve TLS for paid plans, but providers still control their own terms. Entries can become stale, and the same plan can differ by region or customer type. The repository is a shortlist generator; the provider’s current pricing and limits page is the authority.
Where free infrastructure stops being a free decision
Free tiers are excellent for prototypes, personal tools, preview environments, and low-risk experiments. They become a governance question when they hold customer data, identity records, email, payment events, or the only copy of operational logs. At that point, evaluate backups, retention, access control, incident response, billing protection, and migration time alongside price.
Several familiar entries—Cloudflare, Deno Deploy, Sentry, OpenObserve, CircleCI, Netlify, and Vercel—illustrate why verification matters. Their offers are useful, but names and numbers in a community list should not be copied into a budget or deployment manifest without checking the current official plan. “Always free” may apply only to a resource type, region, or usage ceiling. “No charge” may still require a payment method.
Make the free tier replaceable
Keep builds reproducible locally, export data on a schedule, store secrets outside the provider dashboard, and write down DNS and deployment steps. Set usage alerts below the advertised ceiling and disable automatic paid expansion unless it is an intentional decision. These controls turn a free tier into a controlled experiment rather than an invisible single point of failure.
Free-for.dev earns a place in an engineer’s toolkit because it reduces discovery cost. Its best use is not to assemble an unreviewed pile of free accounts, but to find candidates, test their real limits, and preserve a credible exit path.