daily.dev: An Open Source Developer News Feed That Replaces Your New Tab Page
Project brief: daily.dev is the personalized developer news feed and community. Get the best tech content from 1000+ sources in your browser new tab or on mobile. Free and open source.
At a glance
- What is it?
- daily.dev is an AGPL-3.0 licensed browser extension, web app, and mobile app that aggregates developer content from 2,000+ sources into a personalized feed. This review covers what it does, how it works, how to run it, and where its limits are.
- Who is it for?
- Adopt daily.dev if you want a free, open source, tag-driven developer news feed that lives in your browser new tab, and you are comfortable with an ad-supported model and the AGPL-3.0 license. Do not adopt it if you need a self-hosted feed reader, want a platform where you write and host content (like dev.to), or require a single shared ranking (like Hacker News).
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What daily.dev Actually Solves
daily.dev targets a specific pain: developers drowning in scattered tech content. The README states it aggregates articles, tutorials, release notes, and news from 2,000+ sources. Instead of visiting multiple sites or relying on a generic social feed, you get a single personalized feed. The personalization is tag-based and behavior-based. You choose tags like #webdev, #ai, or #devops, and the feed learns from what you read, upvote, and bookmark. This is for developers who want to stay current without manually curating RSS feeds or checking dozens of blogs. It is not a blogging platform. The README explicitly contrasts it with dev.to, which is a community where content is written on the platform. daily.dev aggregates external content and adds community features like Squads, comments, bookmarks, and search.
The Architecture: A Central Hub Plus Separate Frontend Apps
The repository you are looking at is not the entire product. The README says this repository is the central hub, and the frontend applications (extension and web app) live in a separate repository called dailydotdev/apps. That is an important architectural detail for anyone evaluating the code. The central hub likely contains the backend, API, and shared logic, but the actual browser extension and web UI are elsewhere. The README does not give a directory breakdown or a data flow diagram. What it does describe is the client surface: a new tab extension for Chrome and Edge, a web app at daily.dev, and native iOS and Android apps. The extension's behavior is explicitly scoped: it only replaces the new tab page, never reads or modifies other pages, never touches browsing history, and never injects scripts into websites. That is a concrete privacy claim you can verify in the code, but only if you look at the apps repository, not this one.
Getting It Running: Installation Paths
There are no installation commands in the README. This is not a self-hosted tool. You get daily.dev by installing the Chrome extension from the Chrome Web Store, the Edge add-on from the Microsoft Edge Add-ons site, or by downloading the iOS app from the App Store or the Android app from Google Play. The web app is at daily.dev. For a developer who wants to run the code locally, the README does not provide setup instructions, environment variables, or build steps. You would need to clone the repository and inspect the source, assuming the build process is documented somewhere else, likely in the apps repo. The README does mention a product docs link and a changelog link, but it does not include the URLs in the cleaned text. So the practical on-ramp is: install the extension or app, create an account, and pick your tags. There is no self-hosting path described.
The Privacy Model and Its Limits
The README makes strong privacy claims about the extension: it never tracks browsing on other sites, never reads or modifies other pages, never accesses history, and never injects scripts. These are verifiable because the code is open source. However, there is a limit to what these claims cover. The extension replaces your new tab page, which means every new tab is a daily.dev page. That is a significant surface: daily.dev sees your new tab activity, which includes the frequency of tab opens and the content you interact with. The README says your data is never sold, but it does not say what data is collected or how it is used beyond personalization. The feed is ad-supported, and the README says the feed includes clearly marked native ads. So the privacy model is 'we do not track you elsewhere, but we do serve you ads based on your activity on our own surfaces.' For a privacy-sensitive developer, the distinction matters. The README says you can verify the code, but you have to trust that the published extension matches the source.
A Genuine Limitation: It Is a Hosted Service, Not a Self-Hosted Tool
The biggest limitation is architectural. daily.dev is open source, but it is not self-hostable in any practical sense. The README does not mention Docker, Kubernetes, or any deployment option. The service runs on daily.dev's infrastructure. If you want to run your own instance, you would have to reverse-engineer the backend from the central hub repository, which is a major undertaking. The AGPL-3.0 license means that if you modify the code and run it as a network service, you must make your modified source available to users of that service. That is a real compliance burden for any company that wants to fork it. Also, the README says the core experience is free, but there is an optional paid subscription called daily.dev Plus. The README does not specify what Plus includes. So the open source nature is real, but the product is a commercial service with a proprietary backend component that is not described.
The Wrong Tool for Some Use Cases
If your goal is to publish your own technical writing, daily.dev is the wrong tool. It aggregates external content; it does not host your blog posts. dev.to is the alternative for that, as the README itself points out. If you want a single shared ranking of tech links that everyone sees, Hacker News is the alternative. daily.dev personalizes the feed, so two developers following different tags see different content. That is a feature for discovery, but it also means you lose the shared context of a common front page. If you want to run your own feed aggregator with full control over sources and algorithms, daily.dev is not that either. You would be better off with a self-hosted RSS reader like Miniflux or FreshRSS, which give you direct control over subscriptions and no ad feed. Those tools are not mentioned in the README, but they are the natural comparison for a self-hosted alternative. daily.dev's value is in the curation and personalization, not in user control over the pipeline.
Maintenance, Upgrade Cost, and License Implications
The README does not give release notes or a changelog, and the repository metadata shows no recent releases. That is a gap. For an open source project, you want to know how active the development is and how often the extension is updated. The README links to a changelog, but the content is not in the material. The license is AGPL-3.0, which is a strong copyleft license. If you embed daily.dev code into your own service, you may be required to release your modifications under the same license. That is a serious consideration for a commercial product. The repository is not archived, and the default branch is master, which suggests active maintenance, but without release data you cannot confirm the cadence. The README also points to the apps repository as the home of the frontend, so any upgrade work on the extension happens there. For a user, the maintenance cost is low: the extension updates automatically through the browser store. For a developer who wants to contribute, you need to work across two repositories, and the central hub's build and test setup is not documented in the README.
Who Should Adopt It and What to Verify First
Adopt daily.dev if you are a developer who wants a free, tag-driven feed of tech news and you do not mind the ad-supported model. It is also a good fit if you want a community layer with Squads for discussing content with a team. Do not adopt it if you need a self-hosted solution, if you want to publish your own content, or if you are uncomfortable with a new tab page that is not a blank page. Before you adopt it, verify the extension's permission list in the source, because the README's privacy claims are strong but you should confirm them. Check the daily.dev Plus pricing and features, because the README does not say what they are. Look at the apps repository to see how active the frontend development is, since that is where the extension actually lives. And if you are a company, review the AGPL-3.0 terms with your legal team before embedding any code. The product is genuinely useful, but it is a hosted service with a commercial layer, not a drop-in open source component.
Editorial conclusion
Adopt daily.dev if you want a free, open source, tag-driven developer news feed that lives in your browser new tab, and you are comfortable with an ad-supported model and the AGPL-3.0 license. Do not adopt it if you need a self-hosted feed reader, want a platform where you write and host content (like dev.to), or require a single shared ranking (like Hacker News). Before adopting, verify the extension's permissions in the source, confirm the repository you are reading is the central hub and not the apps repo, and check the current state of the mobile apps and Plus subscription. The core value is real, but it is a hosted service, not a tool you run yourself.
Community notes