Hashnode dev blogs on any website.

Hashnode ships a public GraphQL API at gql.hashnode.com, called the Hashnode API v2, and it is the documented, supported, recommended way to read Hashnode content programmatically. The API returns posts, drafts, Publications, series, tags, reading time, cover images, code-block metadata, author profiles, and Sponsors data as fully structured GraphQL responses. RSS feeds also exist for personal blogs and Publications, but they expose a smaller subset of metadata: no series structure, no tag stream filtering, no co-author lists, no reading-time annotations, and no Sponsors information. A widget that runs on RSS can show recent posts but cannot render a series in author-defined reading order, cannot filter a Publication by tag, and cannot surface Hashnode-specific UI like contributor avatars on a multi-author engineering blog. Poper queries the GraphQL API directly. When Hashnode ships a new feature like a Newsletter integration or a content-type extension, the GraphQL schema gets a new field and Poper picks it up on the next deploy. Widget tools that rely on scraping the rendered hashnode.dev HTML are simultaneously slower, more brittle, and missing structured data that the official API hands out for free. The trade-off: GraphQL queries require a small amount of computation per request, so widgets need a CDN edge cache to avoid thundering herd against gql.hashnode.com. Poper caches every query at the edge with an hourly TTL on Free and a 5-minute TTL on Pro, so visitors hit our CDN, not Hashnode's API.

Hashnode's defining feature, and the reason most developers pick it over Medium or Dev.to, is the free custom domain on every blog. Sign up, paste your custom domain like blog.yourname.dev or thoughts.indiehacker.io, point a CNAME record at hashnode-managed infrastructure, and Hashnode handles SSL provisioning, CDN, and host headers automatically. Your blog runs on a domain you own, but the writing tool, comments, drafts, and analytics all live inside Hashnode. There is no fee for the custom domain, no tier gate, no SSL upcharge. This pricing posture is unique among major blogging platforms in 2026: Medium for Publishers requires a paid plan, Substack pushes you to substack.com URLs unless you upgrade, and Ghost is self-hosted unless you pay Ghost(Pro). Hashnode gives custom domains away because the platform monetizes through Sponsors and through hosting Publications for engineering teams that pay for advanced features. The complication for widget tools: when a developer pastes blog.yourname.dev into a widget builder, the tool has to resolve that custom domain back to the underlying Hashnode personal blog identifier before it can query GraphQL. Most third-party widgets do not handle this and either reject the URL or pull no data. Poper resolves custom-domain Hashnode blogs by following redirects, reading the canonical link tag in the blog homepage HTML, querying the publication-by-host GraphQL field, and embedding the correct feed. Paste a custom domain, Poper finds the underlying Hashnode handle, and your embed works regardless of whether the public URL says hashnode.dev or your own domain.

A Hashnode Publication is a multi-author blog with branded chrome, custom navigation, contributor lists, role-based permissions, and its own custom domain or hashnode.dev subdomain. Engineering teams use Publications as the company engineering blog: every engineer has a contributor account, every post has a real author byline, and the Publication itself has a brand identity separate from the writer profiles. Companies like ByteByteGo, Showwcase, and several mid-stage SaaS engineering teams run their public engineering writing on Hashnode Publications specifically because the platform handles multi-author logistics natively. A widget tool that only knows how to embed a single-user blog cannot represent this correctly. Poper queries the Publication GraphQL type, surfaces all contributors with avatars, renders the Publication brand in the embed header, and respects role-based permission cues like draft visibility. Series are another Hashnode-native concept: an author groups a multi-part tutorial into a series with author-defined reading order, and Hashnode renders the series with part numbers and progress UI on hashnode.dev itself. A series is the right unit to embed when you want to feature a tutorial as a course module on a learning platform, since it preserves reading order, total count, and current-position context. Tags work as filters on top: every post can carry tags like #rust, #webdev, #ai, or any custom tag, and the GraphQL API exposes tag-filtered post lists per Publication or per author. Build a topical landing page that surfaces only #rust posts from your engineering Publication, embed it as a course module that reads exactly one series, or merge a contributor's personal blog with the company Publication into one chronological feed for an SDR portfolio site. All of these patterns are first-class against the Hashnode GraphQL API and impossible against generic RSS.

Hashnode monetizes writers through a feature called Sponsors, where readers can sponsor a writer monthly through the writer's Hashnode profile. Sponsors is fundamentally different from the Medium Partner Program in two important ways. First, Sponsors runs on direct reader payments to the writer, not on platform-mediated reading time, so the platform does not pay writers based on where reads happen. A read inside a third-party embed and a read on hashnode.dev count the same to the writer, which is to say neither earns money directly until a reader chooses to sponsor. Second, Sponsors does not gate any content. There is no member-only post type on Hashnode, no paywall, no half-rendered teaser to handle. Every post on Hashnode is free to read forever. This makes embedding Hashnode dramatically simpler than embedding Medium or Substack, where paywalled content forces widget tools to make awkward decisions about teaser-rendering and revenue cannibalization. With Hashnode, the widget renders public posts in full, the reader can click through to the original on Hashnode if they want to comment or sponsor, and the writer's Sponsors revenue is unaffected by where the read happened. Indie hackers and developer creators who picked Hashnode specifically for the no-paywall posture get a clean embedding model out of the box. The widget can also surface the writer's Sponsors button or link to the Hashnode profile on each card, which converts your embed into a discovery-and-sponsor funnel rather than just a content surface. This is one of the few cases where embedding a writer's content on your site can actually grow the writer's monetization rather than dilute it.

Most developer writers eventually have to pick a platform, so a quick honest comparison: Hashnode is the right pick for developers who want a personal brand on their own custom domain with no monetization paywall, structured GraphQL access for embedding, and Publications for team engineering blogs. The free tier is generous, the writing experience is technical-content-first with great code blocks, and the platform genuinely cares about developers as a primary audience. Dev.to is the right pick for developers who care more about reach and community than personal branding: posts are syndicated to a single dev.to URL, every post lives on a community feed, and reach can be huge but you do not own the URL. Medium is the right pick for thought leaders writing essays for a general audience, but the post-2023 reach decline and Partner Program churn make it a worse choice for technical writing in 2026 than it was five years ago. Substack is the right pick for writers monetizing through paid email subscriptions, especially long-form essays sent to an inbox, but it is not optimized for technical content with heavy code blocks. Most working developer writers in 2026 split: Hashnode for personal technical blog with a custom domain, Substack for a paid newsletter with subscribers, GitHub for code, LinkedIn for distribution. A hashnode feed widget on your portfolio site is the right surface to feature the technical writing in that split, because the audience visiting your portfolio is generally the technical buyer audience that converts on technical credibility. If you eventually decide to migrate from Hashnode to a self-hosted Ghost or to a Dev.to-only posture, the same Poper feed widget configuration works against any of those platforms by changing one URL, which keeps platform-migration cost close to zero. This is the boring but correct posture for any developer who takes their writing platform seriously.