free-for.dev: a curated free-tier list with an opinionated filter and no licence

Free tier, not free trial, and self-hosted software is out of scope

The eligibility note is short and does the filtering.

A service must offer a free tier, not just a free trial. The free tier must be for at least a year if it is time-bucketed. And the list is only for as-a-Service offerings, not for self-hosted software.

Each of those three rules removes a category of thing a buyer would otherwise expect to find. A generous thirty-day trial of a good product is deliberately excluded, on the grounds that it is a sales tool rather than a tier. A time-boxed credit that expires in ninety days is excluded even if it is generous. And the entire world of free software you install yourself, which is usually the cheapest option of all, is not here and will never be, because that is a scope decision rather than an oversight.

The maintainer is explicit that the scope line is a judgement: the list is limited to what system administrators and DevOps practitioners are likely to find useful, it is a grey line sometimes, and it is opinionated. Read that as a warning that a missing category means a decision, not a gap.

TLS behind a paywall is a rejection reason, so absence means nothing

One eligibility rule is about security rather than price, and it is the most unusual thing about the project.

The free tier is considered from a security perspective. SSO is fine. Services that restrict TLS to paid-only tiers are not accepted.

So the list applies an opinion about a vendor's security posture as a condition of inclusion. That is not what a price index normally does, and it has two consequences. First, the list is filtered in a way that is invisible from the outside: you cannot tell from a service's absence whether it was rejected for restricting TLS, judged off-topic, or simply never submitted. Second, and more useful, it tells you the maintainer thought about the failure mode where a free tier is deliberately hobbled in a way that matters for a service handling production traffic.

What the rule does not give you is a security rating. Passing this filter is a floor, not an assessment, and no entry in the list carries a security claim beyond it.

The quotas are a snapshot, and the entry sends you to the vendor for the truth

Read the Google Cloud section and the pattern is obvious. App Engine gets 28 frontend instance hours per day and nine backend instance hours per day. Cloud Firestore gets 1GB of storage with 50,000 reads, 20,000 writes and 20,000 deletes per day. Compute Engine gets one non-preemptible e2-micro with a 30GB HDD, 5GB of snapshot storage restricted to certain regions, and 1GB of monthly network egress from North America to all region destinations excluding China and Australia. Cloud Run gets 2 million requests per month. BigQuery gets 1TB of querying per month. Cloud Build gets 120 build-minutes per day.

The detail is genuinely good, and it is also the kind of detail that goes stale without anyone noticing, because it is duplicated from somewhere else.

The section closes by pointing at the vendor's own page for the full list. That is the honest move and it tells you how to use the whole project: the README is an index of things worth reading about, not the authority. Note also the entries that are rate limits rather than free tiers, such as the AI Studio allowance of 5 requests per minute and 20 requests per day, and the Kaggle GPU and TPU allowances that require phone or identity verification. Those are per-day caps, not persistent free capacity.

Removals happen by pull request, so presence is not evidence a tier exists

The maintenance model is stated in one sentence and it is entirely human. The list results from pull requests, reviews, ideas and work done by 1600+ people, and the way to help is to send pull requests that add services or remove ones whose offerings have changed or been retired.

So a dead free tier leaves the index when somebody notices. There is no per-entry verification date, no expiry marker, no automated check, and no link checker mentioned anywhere in the project. The default state of an entry is therefore that it was true at the moment a human last read the vendor's pricing page.

That is workable for a list nobody depends on and a problem for a list somebody does. If a service has ended its free tier and no one has filed a removal, the entry is still there, and the failure mode is silent: you read it as current, you design around it, and you find out at signup or at the first invoice. The rule for using this list is to treat every entry as a pointer to a page to re-read, which is exactly how the Google Cloud section is written.

README.md and index.html are two renderings of the same claims

The repository is a handful of files. The top level holds .github/, .gitignore, AGENTS.md, CLAUDE.md, CNAME, CODE_OF_CONDUCT.md, CONTRIBUTING.md, README.md, index.html and logo.webp, and the recorded primary language is HTML rather than Markdown.

CNAME is the file that binds the domain, so the GitHub Pages site at free-for.dev is served from this repository, and the landing page is index.html rather than the README. That means the same data exists in at least two files that nothing keeps in step. The README is the one people clone and the one contributors edit, and the HTML page is the one people read. If they drift, a reader on the site sees a claim a reader in the repository does not have.

There is no build manifest, no template directory and no generator visible at the top level, so the two files appear to be maintained by hand. The list is small enough to fit in one file, which is a virtue until the file has fifty-odd headings under it and a second copy to keep honest.

Fifty-six headings, and the grey line shows in the domain names

The table of contents is long, and reading it tells you where the maintainer's line about infrastructure developers actually landed.

There are the obvious ones: IaaS, PaaS, DNS, Docker Related, CI and CD, Monitoring, Security and PKI, Artifact Repos, Managed Data Services. And then there are the ones that require a sentence of justification: International Mobile Number Verification API and SDK, Visitor Session Recording, Screenshot APIs, Data Visualization on Maps, Dev Blogging Sites, Commenting Platforms, Feature Toggles Management Platforms, and a heading that reads Flutter Related and Building IOS Apps without Mac.

That last one is a good example of what this list is. It is not a catalogue of free tiers in general; it is a catalogue of free tiers that a person who runs infrastructure has, at some point, wished existed. The headings are the evidence for the scope claim, and they are also the reason the maintainer says not to feel offended by a rejection.

A category called Other Free Resources sits at the end, which is the traditional escape hatch and does not narrow the scope on its own.

No licence file, so the compiled list has no stated terms

There is a CODE_OF_CONDUCT.md and a CONTRIBUTING.md and an AGENTS.md and a CLAUDE.md at the top of this repository, and there is no LICENSE file. The licence identifier attached to the repository is unresolved.

So the terms for reusing the content are not stated anywhere. Reading it and linking to free-for.dev is unremarkable. Forking it, mirroring it, scraping it into a comparison table, or building a service that queries it are all in a different category, and the repository gives you no permission and no prohibition to point at. Unlike a data set published under a public domain dedication or a permissive licence, this one has to be treated as all rights reserved by default, which means asking.

There is a practical asymmetry worth noting. The content is a compilation of facts about other companies' pricing, which is exactly the kind of material that is easy to republish, and the site is public. That makes the absence of a licence a live question rather than a technicality, and the answer is to ask the maintainer rather than to assume the CC0 that a lot of comparable lists use.

Editorial conclusion

Use it as a map of which vendors to go and read about, particularly the always-free allowances on the major clouds, and treat every number in it as a starting point rather than a budget. Do not use it to justify a production dependency, because an entry is removed only when somebody notices and files a pull request, and the repository carries no per-entry verification date. Do not use it to find free software you run yourself either, since self-hosted offerings are excluded by rule, and do not build a dataset out of it, because there is no licence file at the root and the terms of reuse are simply not stated. The first thing to check for any service you care about is the vendor page the entry links to, since the list itself points there for the full detail.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository