cnews

Engineers who stay current without drowning in feeds have one thing in common: they treat news consumption as an infrastructure problem, not a bookmarking hobby. cnews is the shorthand I use for a lightweight, code-first approach to curating technical updates it's not a single product or a walled garden; it's a pattern for pulling signal out of the firehose of releases, papers, CVEs, and blog posts that hit a modern development team every week.

The core idea is simple but easy to miss: the best technical news system is the one you can query, version, and tune like any other service. That means storing source in Git, filtering with code. And delivering summaries through interfaces you already live in, whether that's Slack, email, a terminal. Or a private RSS reader. In this post, I will walk through how cnews works in practice, where it saves the most time. And where it can go wrong.

Why most developer news feeds become useless

The average engineering team subscribes to dozens of sources: GitHub release pages, project blogs, security advisories, conference playlists. And newsletters. Each source is useful in isolation. Together they create a noise problem that no single app solves well. In production environments, I have watched teams miss critical dependency updates because they were buried between marketing posts and opinion pieces.

The failure mode is predictable. Generic aggregators rank by engagement, which rewards hot takes over patch notes, and email newsletters arrive on someone else's scheduleSocial timelines inject irrelevant replies and sponsorships. A cnews pipeline fixes this by letting you define relevance explicitly: if a post matches your stack, your security profile. Or your migration roadmap, it surfaces. Everything else is archived or dropped.

Defining the scope of a cnews pipeline

Before writing any code, decide what cnews is responsible for. I split the work into four bounded contexts: ingestion, enrichment, ranking, and delivery, and ingestion fetches raw itemsEnrichment adds metadata such as language detection, tag extraction. And duplicate grouping. Ranking scores items against team preferences, and delivery pushes the final list to humans

This scope matters because it keeps the system honest. A cnews instance shouldn't try to replace Google, arXiv, or your issue tracker. It should answer a narrow question: "What changed since yesterday that this team should know about? " If an item doesn't map to a decision, a risk. Or a learning goal, it doesn't belong in the digest. Starting with that constraint prevents the feature creep that kills most personal news projects.

The minimal architecture behind cnews

You can run the first version of cnews with a cron job, a SQLite database. And a hundred lines of Python or Node js. The ingestion step polls RSS or JSON feeds. The storage step normalizes titles, links - publish dates, and content hashes. A small scoring function filters by keywords, authors, or domains. Finally, a renderer produces Markdown or HTML and ships it to your channel of choice.

At scale, the pattern stays the same but the components get more robust. I have moved ingestion to a scheduled container in Kubernetes, used Redis for deduplication queues. And stored normalized articles in PostgreSQL with full-text search. For delivery, a static site generated once per hour is surprisingly effective. It gives the whole team a bookmarkable URL, avoids rate limits. And costs almost nothing to host on object storage. Read our comparison of static-site generators for internal tooling

Parsing sources with RSS, Atom. And API endpoints

RSS and Atom are still the most reliable ingestion primitives for cnews they're stateless, well documented, and supported by most technical blogs and repositories. The Atom Syndication Format is defined in RFC 4287, and RSS has decades of parser support. For sources that do not publish feeds, services like RSSHub or a small scraper written with Playwright can bridge the gap.

When APIs are available, prefer them over scraping. The Hacker News API, GitHub's release and advisory APIs. And PyPI's JSON endpoints all return structured data that's easier to normalize than HTML. Always respect rate limits and cache aggressively. A polite cnews crawler keeps an ETag or Last-Modified header on every source so it doesn't re-fetch unchanged content. MDN has a solid overview of how these feed formats work in practice on their RSS page.

Ranking signals that matter for engineering teams

Not every release note deserves attention. A good cnews ranker combines static rules with lightweight signals. Static rules include domain allowlists, author allowlists, and keyword matches for technologies you actually use. Dynamic signals include mention counts on relevant forums, patch severity scores. And whether the item relates to an open ticket in your tracker.

I usually start with a simple weighted score. A direct mention of a dependency in your lockfile gets the highest weight. A post from an official project blog gets medium weight. A generic listicle gets a negative weight. The key is to make the scoring transparent. When someone asks why an item appeared, the cnews log should show exactly which rule matched. Opaque recommendation algorithms defeat the purpose of a developer-focused tool.

Delivering updates without notification fatigue

The best cnews digest is the one people read without dread. I recommend a single daily summary rather than real-time pings. Group items by theme, such as security, releases, and long reads, and put the highest-scored items firstInclude a one-line context sentence that explains why the item matters to your team, not just the original headline.

For delivery channels, match the format to the audience. Engineers who live in the terminal often prefer a TUI or a plain Markdown file. Managers usually want email. Incident-response teams may want Slack threads with threaded discussion don't blast every channel with the same content. A cnews system that respects attention is much more likely to survive long-term than one that maximizes reach.

Running cnews on cheap, reliable infrastructure

Cost is a silent killer for side projects. A cnews pipeline can run comfortably within free tiers if you're disciplined. And gitHub Actions handles schedulingSQLite or a managed Postgres free tier stores the data. A static site hosted on Cloudflare Pages, Netlify. Or GitHub Pages serves the digest. The only recurring cost is usually the compute to run enrichment. And even that's negligible for small source lists.

Reliability comes from observability, not scale. Log every failed fetch, every parse error, and every empty digest. Alert on silence: if cnews hasn't produced a digest in 24 hours, something broke. I also version the configuration in Git so that bad rule changes can be reverted with a pull request. Treating the news config like application code is one of the biggest wins of the cnews pattern.

Lessons from operating cnews in production

After running variations of cnews for several teams, a few patterns keep showing up. First, source quality beats source quantity. Twenty high-signal feeds consistently outperform two hundred noisy ones, and second, human overrides are essentialA "not relevant" button that feeds back into the ranker improves quality faster than any algorithm tweak. Third, summaries matter more than links. People will skim a two-sentence summary; many won't click through to a long post.

Another lesson is to separate the archive from the digest. The digest is the curated front page, and the archive is the searchable back catalogTrying to combine them creates pressure to include everything in the digest. Which destroys trust. A clean separation lets cnews be both thorough and concise,

Extending cnews with AI summarization

Large language models are a natural fit for the enrichment layer of cnews. They can summarize long posts, extract action items, and classify topics. In production, I found that small models run locally via Ollama are sufficient for most summaries, while larger APIs are reserved for complex security advisories or research papers. The trick is to keep a human in the loop for anything that drives a decision.

When adding AI, guard against hallucination. Always include the original link and a confidence flag. Never let the model invent version numbers or CVE identifiers. A safe pattern is to let the model generate a draft summary, then run a validation pass against the raw text to ensure named entities match. This keeps cnews accurate while still saving reading time.

When cnews is the wrong tool for the job

cnews works best for recurring, low-urgency awareness. It isn't a replacement for security scanning tools like Snyk or OWASP Dependency-Check, and it's not an incident-management platformIf a CVE needs immediate action, it should come from a dedicated scanner with SLAs, not from yesterday's digest. Similarly, cnews isn't great for discovering brand-new frameworks unless you explicitly tune it for exploration.

It is also not a good fit when the team can't agree on relevance. If every item triggers a debate about whether it belongs, the problem is usually unclear priorities, not the tool. Fix the taxonomy first. Once the team agrees on what "relevant" means, the cnews rules write themselves.

Frequently asked questions about cnews

Is cnews a specific product I can download?

No cnews is a pattern and a naming convention for a code-first news curation pipeline. You can build it with any stack. Many teams have internal tools that fit the cnews pattern even if they don't call them that.

How many sources should a cnews instance track?

Start with ten to twenty high-quality sources. Expand only when the digest is consistently useful. In my experience, quality degrades quickly after about fifty sources unless you invest heavily in ranking.

Can cnews replace my newsletter subscriptions?

It can replace the reading experience for newsletters that offer RSS feeds or public archives. However, paid or private newsletters may still require a separate inbox cnews shines when you want to merge many sources into one team-owned view.

What is the cheapest way to host cnews?

The cheapest path is GitHub Actions for scheduling, a SQLite file committed to the repository or a free Postgres tier. And a static site on GitHub Pages or Cloudflare Pages. For most small teams, the monthly cost rounds to zero.

How do I prevent cnews from becoming another ignored digest?

Keep it short, score transparently. And include context sentences that explain why each item matters, and send it at a consistent time,And give readers a way to mark items as irrelevant so the ranker improves.

Building your first cnews digest this week

If this pattern resonates, start smaller than you think. Pick three sources your team already trusts, such as a core dependency's release blog, a security advisory feed, and one high-signal newsletter. Write a script that fetches them, scores them against your current stack. And posts a Markdown summary to Slack or email. Run it manually for a week, then automate it.

The goal isn't to build the perfect news engine on day one. The goal is to prove that a small, code-curated digest is More Useful Than an endless stream of algorithmic recommendations. Once the habit sticks, you can add enrichment, ranking, and archive features incrementally. Check out our starter template for a cron-based cnews pipeline

Conclusion: make news curation part of your engineering practice

Staying informed is a skill. But it's also a system. The teams that keep up without burning out are the ones that treat information flow as a first-class engineering concern cnews gives that concern a shape: explicit sources, transparent scoring. And delivery channels that respect attention. It turns passive scrolling into an auditable, improvable pipeline.

If you're tired of missing important updates or drowning in irrelevant ones, build a cnews prototype this sprint. Start with cron, SQLite, and Markdown. Measure whether people read it. And iterateThe result won't just save time; it will make your team's technical awareness a shared asset rather than a private burden.

What do you think?

Would you trust an algorithmic ranker to decide what your engineering team reads each morning,? Or should final curation always involve a human reviewer?

What is the single source of technical news your team would refuse to remove from a cnews feed,? And why?

How do you balance the risk of missing a critical update against the cost of constant notification noise in your current workflow?