A directory with a useful boundary
The name sounds broader than the project is. free-for-dev collects hosted services with a lasting free tier that infrastructure developers might use. The README rules out self-hosted software, temporary trials, and offers that put TLS behind a paid plan. A time-limited allowance must last at least a year. Those rules remove much of the junk that makes generic free-software lists tiring to search.
The result covers the ordinary parts of a modern stack: major clouds, CI, managed databases, DNS, monitoring, authentication, email, storage, testing, APIs, and many smaller categories. Each entry gives a link and a compact description of the free allowance. That format is fast. If you need somewhere to run a small service or send a modest volume of email, you can scan one section and leave with a shortlist in minutes.
Scope discipline matters here. A list that accepted every free utility would become impossible to browse. The maintainers explicitly decline generic toolboxes, copied services, several kinds of disposable email, and some commodity hosting submissions. The choices are opinionated, as the README says, but they keep the directory aimed at people assembling infrastructure rather than collecting bookmarks.
What happened when we ran it
We did not run the repository. Our sandbox checkout used commit 7b1e6ff on 2026-08-22 with 3 CPUs, 8 GB of RAM, no secrets, and an unprivileged Debian container. The project was classified as HTML, no supported application ecosystem was present, and there was no Dockerfile. That left no install, build, or test command for the lab to execute.
This result fits what the repository contains. The main artifact is the README, while index.html wraps it in Docsify for the free-for.dev website. The page loads Docsify, its search plugin, and a light-dark theme from jsDelivr. With JavaScript disabled, it sends the reader to the GitHub repository. There is no server component, account setup, database, or secret to configure for normal use.
Excellent for discovery, thin for comparison
The terse entry format is both the reason to use free-for-dev and the reason to stop short of trusting it alone. It can tell you that a service has a free allowance and summarize the headline quota. It usually cannot tell you how overages work, where data is stored, how support behaves, whether an account needs a payment card, or how painful export will be. Some entries mention these details, but the list does not apply a fixed comparison sheet to every provider.
Free tiers also move. A vendor can reduce storage, add a card requirement, exclude commercial use, or close the product after an entry is merged. The README acknowledges this directly by asking people to remove offers that changed or retired. That community repair loop is sensible, though it is reactive. Before wiring a service into an application, open its current pricing page and documentation. Save the terms that matter to your decision.
Search works well enough on the hosted page, and the table of contents makes the raw README usable. Discovery still depends on the project's categories and wording. A service may plausibly fit several sections, while a browser search only finds terms used in its description. Readers with strict requirements such as a region, protocol, or compliance feature will still do manual filtering.
Maintenance is visible and unusually current
The repository began in March 2015 and had 133,655 stars when we fetched its metadata on 2026-08-22. The README credits more than 1,600 contributors. Popularity alone says little about accuracy, but the recent activity is more persuasive: the last push was 2026-08-21, and pull requests adding or updating services were opened, reviewed, and closed that same day. GitHub reported 13 open issues and pull requests combined; a separate search found no open issues and two open pull requests.
Contribution rules are blunt. New services must use the pull request template, meet the free-tier requirements, and fall within scope. Updates to existing entries have a lighter process. The maintainers also say AI-generated submissions will be closed without discussion. That tone may deter casual corrections, yet it also tells vendors that promotional copy and evasive submissions are unwelcome.
There is no latest GitHub release and no detected repository license. A release cadence would add little because this is a continuously edited list, so commit and pull request activity are better health signals. The missing license is more consequential for anyone who wants to copy, package, or redistribute the dataset. Reading and linking to the directory is straightforward; reuse deserves a separate rights check.
Where it belongs in a real decision
Treat free-for-dev as an intake list. Start in the relevant category, collect a few candidates, and then compare their current first-party terms. Check the quota unit carefully because requests, credits, stored objects, seats, and compute time create very different ceilings. Confirm what happens when the allowance is exhausted and whether the provider automatically bills an attached card.
The alternatives split by intent. Public APIs is narrower and more useful when an API is the target. Awesome Selfhosted goes in the opposite operational direction, toward software you control. Awesome is broader and helps when you are still choosing technologies rather than vendors. None replaces free-for-dev's focused scan of hosted free tiers.
For a developer trying to keep an early project cheap, this directory earns a bookmark. Use it to discover names you missed and to reject obvious mismatches. The final choice still belongs in the provider's live documentation, with the free allowance treated as a changeable pricing decision rather than part of your application's permanent foundation.