DEV Community: Sanjay Singh

Cross-Posting for Developers: How to Reach More Readers Without Losing Your SEO

Sanjay Singh — Wed, 09 Sep 2026 04:04:55 +0000

TL;DR: Cross-posting expands your reach across developer networks like Dev.to, Hashnode, Medium, WordPress, Bluesky, and Mastodon. But managing manual re-formatting and platform quirks is exhausting, and missing canonical tags can destroy your search rankings. Learn how canonical URLs, automated formatting (including Mermaid diagrams), Git backups, and modern AEO/GEO optimization let you syndicate everywhere while keeping complete ownership of your work.

You wrote a good technical post. Now what?

Writing in-depth technical articles is demanding. You spent hours debugging an edge case, verifying benchmarks, constructing architecture diagrams, and refining code snippets until the explanation clicked.

Publishing that post is where the next challenge begins.

If you publish exclusively to your own blog, you run into the cold-start problem: without an established audience or high domain authority, very few developers will ever discover your post. If you publish solely inside a walled garden or a single developer network, you become dependent on that platform’s algorithm, formatting constraints, or reading paywalls.

The logical move is cross-posting (syndication): putting your writing in front of existing communities on Dev.to, Hashnode, Medium, and WordPress, while sharing dispatches across developer-friendly social networks like Bluesky and Mastodon.

The concept is straightforward. The execution, however, is notoriously tedious. Once the article is finished, you are suddenly stuck converting Markdown formats, fixing broken code blocks, uploading images across separate dashboards, remembering each platform’s canonical URL settings, and tracking fragmented views across multiple sites.

That is the unglamorous side of content distribution nobody talks about: the friction between “I finished the article” and “the article is live everywhere.”

The part that’s easy to get wrong: Canonical URLs

The biggest risk in cross-posting technical content is search engine cannibalization.

When search engines like Google crawl identical or substantially similar articles published across multiple domains, they must decide which version to rank. Without explicit guidance, a high-authority domain like Medium or Dev.to will almost always outrank your primary post—robbing your home profile of traffic, backlinks, and domain authority.

This is where the canonical URL (rel="canonical") comes in.

A canonical URL acts as an authoritative signal telling search engines: “Even though this article appears here, credit the original URL as the definitive source of truth.”

Suppose your primary article lives on your preferred canonical source—whether that is your ZyVOP author hub or your own self-hosted domain:

https://zyvop.com/@alex/how-to-build-a-resilient-cli
# (or your custom domain: https://alexdev.io/blog/how-to-build-a-resilient-cli)

When syndicated across other networks, those copies should explicitly identify your primary URL as the source:

Dev.to      → canonical: https://zyvop.com/@alex/how-to-build-a-resilient-cli
Hashnode    → canonical: https://zyvop.com/@alex/how-to-build-a-resilient-cli
Medium      → canonical: https://zyvop.com/@alex/how-to-build-a-resilient-cli
WordPress   → attribution link & canonical header

While the concept is simple, the real problem is that every platform implements canonicalization differently:

Dev.to supports a canonical_url property in its Markdown frontmatter and REST API.
Hashnode handles original article URLs through its GraphQL schema (originalArticleURL).
Medium provides a dedicated import API workflow with a canonicalUrl field, which behaves completely differently from pasting Markdown directly into its web editor.
WordPress REST API does not have a native canonical meta field out of the box without third-party plugins (such as Yoast or Rank Math), requiring structured editorial attribution links.

Remembering the quirks, API schemas, and formatting rules of each platform for every single article you write is why manual cross-posting quickly becomes unsustainable.

Own the source, syndicate the reach

Cross-posting does not mean surrendering ownership of your content. The core principle of a sustainable publishing strategy is simple: own the primary source of truth, and treat third-party networks purely as distribution channels.

Notice the distinction between the two groups in the diagram above:

Long-form publication platforms (Dev.to, Hashnode, Medium, WordPress) host a syndicated copy of the article itself. Their job is to bring organic community readership and pass SEO credit back to your primary home via canonical tags.
Social and micro-blogging platforms (Bluesky, Mastodon) are broadcast channels. Their job is to share a concise summary, key takeaways, and a trackable link directing readers back to your primary article.

You should never have to choose between building your own developer presence and publishing where developers already spend their time.

The hidden headaches of manual syndication

Publishing one article to one extra platform once a month is manageable. Doing it every week across six destinations is painful.

Beyond canonical links, there are technical friction points that break down when moving between platforms:

Code formatting and syntax highlighting: Some editors strip language tags, fail to parse multi-line comments, or wrap code poorly on mobile viewports.
Mermaid diagrams and LaTeX math: If your article includes architectural flowcharts (mermaid) or mathematical formulas (LaTeX), pasting them into platforms like Medium or WordPress breaks them entirely because those platforms don't render them natively.
Asset management: Images hosted on ephemeral CDNs or temporary local paths can break when exported across platforms.
Metadata and SEO tags: Manually writing custom meta descriptions, OpenGraph tags, and social cards for each platform consumes time that should be spent writing.

None of these tasks make the writing better. They are mechanical plumbing problems.

Where automation makes sense: How ZyVOP solves this

Cross-posting is an ideal candidate for automation because the creative work is already done. You researched the topic, wrote the code, drafted the post, and edited it. At that stage, everything remaining is purely programmatic: formatting content, making API calls, attaching canonical URLs, and handling platform differences.

That is the exact workflow ZyVOP was built to handle.

ZyVOP operates as a Developer Publishing Hub: you write your article once, and syndicate it simultaneously across supported developer networks and social channels in a single step.

Instead of managing separate routines for Dev.to, Hashnode, Medium, WordPress, Bluesky, and Mastodon, ZyVOP’s syndication engine orchestrates the platform-specific heavy lifting:

Automated canonical tagging: Every syndicated copy on Dev.to, Hashnode, and Medium automatically points back to your primary article URL as the canonical source.
Support for custom personal domains: If you already run your own independent blog (yourdomain.com), you can specify your custom URL in ZyVOP's SEO settings. ZyVOP will syndicate the article across all external platforms while ensuring 100% of the canonical authority points back to your personal domain.
Diagram and code transformation: For destinations like Medium and WordPress that lack native Mermaid support, ZyVOP converts your Mermaid diagram blocks into rendered SVG embeds under the hood, ensuring your system designs never break.
UTM campaign tagging: Every outbound link and backlink is automatically tagged with clean UTM parameters, so you can track where your incoming traffic originates.

Your writing should be portable too (Automatic GitHub Sync)

Distribution is only half the battle. The other half is ensuring your writing isn't trapped inside a proprietary database.

Developers spend years accumulating technical tutorials, architectural post-mortems, and debugging notes. If a platform shuts down, changes its monetization model, or introduces aggressive paywalls, recovering your content can be a nightmare.

ZyVOP eliminates vendor lock-in with Automatic GitHub Markdown Sync.

Every time you publish or update an article on ZyVOP, the system automatically commits a clean, portable .md file with standard YAML frontmatter directly to your connected personal GitHub repository.

---
title: "Cross-Posting for Developers: How to Reach More Readers Without Losing Your SEO"
date: "2026-09-08T03:15:00.066Z"
canonical_url: "https://zyvop.com/@sanjay687/cross-posting-for-developers-how-to-reach-more-readers-without-losing-your-seo-csyc6"
tags: ["cross-posting", "seo", "developer-blogging", "content-distribution"]
---

Your clean Markdown content lives here alongside your code...

For developers, this workflow feels natural:

Your articles live in Git alongside your software projects.
You maintain full commit history, diffs, and offline access.
You can migrate your entire library anywhere at any time with zero friction.

Beyond Google: Preparing for AI Answer Engines (AEO & GEO)

Search is evolving rapidly. Developers don't just rely on traditional Google keyword search anymore—they discover technical solutions through AI answer engines like Perplexity, ChatGPT Search, Claude, and Gemini, as well as community discussions on Discord, Reddit, and Bluesky.

This requires optimizing for both SEO (Search Engine Optimization) and AEO / GEO (Answer & Generative Engine Optimization):

Structured Technical Schema: ZyVOP injects structured JSON-LD (Article, TechArticle, and SpeakableSpecification) so crawlers and LLM indexers clearly understand the author, programming languages, key concepts, and licensing.
Citation-Ready Summaries: Built-in AI copilot tooling helps you generate concise TL;DR blocks and key takeaway bullet points that AI agents can cite directly.
Machine-Readable Endpoints: Content is served with clean semantic markup and dedicated metadata endpoints (/api/geo/posts/...), making your technical explanations easy for AI search systems to parse and attribute back to your source.

Having a stable, high-performance primary URL means AI search engines have an authoritative source to quote and link back to.

Unified telemetry: Tracking impact without twenty tabs

When an article is distributed across multiple platforms, checking its performance usually requires opening half a dozen browser tabs and piecing disparate numbers together.

ZyVOP consolidates this with unified cross-platform analytics:

Aggregated views across ZyVOP, Dev.to, and Hashnode in a single dashboard.
30-second engaged dwell time, tracking whether readers actually read your code or bounced immediately.
A real-time Syndication Multiplier showing the exact reach boost gained from cross-posting.
Referral source classification breaking down visits from search, aggregators, social networks, and direct links.

Terminal-first publishing: Write in your editor, publish via CLI

You shouldn't be forced into a web browser if you prefer writing in VS Code, Obsidian, or Neovim.

With ZyVOP’s official NPX CLI, you can publish and trigger multi-platform syndication directly from your terminal or a GitHub Actions CI/CD pipeline:

# Publish markdown directly from your terminal
npx zyvop publish ./articles/my-new-post.md

Write your markdown locally, test your code, and syndicate everywhere in one command.

The takeaway

Cross-posting is one of the highest-leverage habits a technical writer can build. Developers already read across Dev.to, Hashnode, Medium, and social channels—limiting your articles to a single platform limits your opportunities to be discovered.

The mistake is treating every platform as a separate manual chore.

Own the source: Establish your primary canonical home (whether on ZyVOP with zero reader paywalls, or on your own personal domain).
Protect your SEO: Ensure every cross-posted destination references your canonical URL to avoid search engine cannibalization.
Keep an independent archive: Automatically sync clean Markdown copies to your personal GitHub repository.
Automate the repetitive plumbing: Let software handle format transformations, diagram embeds, social teasers, and multi-platform analytics.

You already did the hard work by writing the code and crafting the explanation. The publishing workflow shouldn't make you do it all over again.

Write once, publish everywhere, own your source.

👉 Start writing on ZyVOP — 100% free, zero reader paywalls, with automated multi-platform syndication and Git backup.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Postgres vs MySQL vs MongoDB: The 2026 Decision Guide

Sanjay Singh — Wed, 09 Sep 2026 03:58:45 +0000

PostgreSQL just posted its biggest DB-Engines score gain on record. MySQL still outranks it on raw popularity. MongoDB makes you read a license clause before you build a business on top of it. None of that tells you which one to actually use.

This guide skips the vendor slides. It's built on where these three databases actually stand in 2026: current versions, real benchmark numbers, real production deployments, and the tradeoffs engineers hit once traffic shows up.

The short answer

	PostgreSQL	MySQL	MongoDB
Model	Relational, extensible	Relational	Document (NoSQL)
Current line	18.6 (major 18 shipped Sept 2025; 19 in beta)	9.7 LTS and 8.4 LTS; 8.0 hit end of life in April 2026	8.0 major, supported through Oct 2029; 8.3 is the latest rapid release
License	PostgreSQL License — permissive, BSD-style	GPLv2 Community, commercial Enterprise from Oracle	SSPL — source-available, not OSI-approved
Transactions	Full ACID since day one	Full ACID via InnoDB	Multi-document ACID since 4.0 (2018), with limits
Horizontal scaling	Needs an extension (Citus) or app-level sharding	Needs a layer like Vitess	Built into the core product
Known for	JSONB, extensions, SQL depth	Simplicity, huge hosting ecosystem	Flexible schema, native sharding
Runs at	Instagram, Uber (partially), Reddit, Apple, Spotify, Coinbase	Meta, YouTube (via Vitess), Booking.com, most of WordPress	Wells Fargo card platforms, CSX rail operations, Electronic Arts

If you only read one line: Postgres is the safe default for almost anything you'll build in 2026. MySQL earns its keep when you're already deep in its ecosystem. MongoDB wins when your data genuinely doesn't want to be rows and columns.

Here's the reasoning behind that table.

What each one actually is

PostgreSQL

Postgres is a relational database that got extensible instead of staying simple. It ships with a real type system (arrays, ranges, native JSON), full ACID transactions, and a plugin architecture that lets you bolt on capabilities most teams would otherwise buy as separate products.

That's not a small deal. PostGIS has handled geospatial queries in production since 2001. pgvector turned it into a viable vector database for AI apps. TimescaleDB turned it into a time-series engine. You add an extension, not a new system to operate.

MySQL

MySQL is the database that shipped with every LAMP-stack tutorial you've ever read. It's simpler than Postgres by design, uses a pluggable storage engine architecture (InnoDB by default since 5.5), and optimizes hard for the common case: read-heavy web and content workloads at scale.

It's owned by Oracle, which unsettles some teams and doesn't bother others. WordPress alone runs on more than 40% of all websites on the internet, and closer to 60% of sites that run any CMS at all, and it keeps MySQL relevant regardless of anyone's opinion on Oracle.

MongoDB

MongoDB stores documents (BSON, a binary form of JSON) instead of rows. There's no fixed schema to negotiate before you ship, no joins to write, and horizontal scaling (sharding) is a first-class feature instead of a bolt-on.

The tradeoff is consistency guarantees that took years to catch up to relational databases, and a license (more on that below) that matters if you're building a hosted product.

Where each one stands right now

PostgreSQL 18 shipped in September 2025 with a new async I/O subsystem that demonstrated up to 3x faster storage reads in some workloads, plus virtual generated columns, a uuidv7() function, and OAuth 2.0 support for SSO. The current patch is 18.6, and PostgreSQL 19 is already in beta.

MySQL renumbered its release train this year to match the calendar. MySQL 26.7 Innovation is the bleeding edge, while MySQL 9.7 became the newest LTS line in April 2026, adding a Hypergraph optimizer, dynamic data masking, and in-database JavaScript. MySQL 8.4 LTS is still fully supported. MySQL 8.0 reached end of life in April 2026, so if you're still on it, that's your actual priority this quarter.

MongoDB 8.0 is the current major release, supported through October 2029. MongoDB's own benchmarks claim up to 36% better read throughput and 56% faster bulk writes over 7.0, with the company citing 32% overall gains specifically for typical mixed read/write web application workloads. The 8.3 rapid release from May 2026 is the current downloadable tip, adding native type coercion in queries and stronger security defaults.

How they actually store and query the same data

Same use case across all three: an order with a flexible list of line items. Here's what it looks like in each.

PostgreSQL, structured columns plus a JSONB field for the flexible part:

CREATE TABLE customers (
    customer_id BIGSERIAL PRIMARY KEY,
    email TEXT UNIQUE NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE orders (
    order_id BIGSERIAL PRIMARY KEY,
    customer_id BIGINT NOT NULL REFERENCES customers(customer_id),
    status TEXT NOT NULL DEFAULT 'pending',
    line_items JSONB NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_orders_line_items ON orders USING GIN (line_items);

-- Every pending order with an electronics item
SELECT order_id, customer_id, line_items
FROM orders
WHERE status = 'pending'
  AND line_items @> '[{"category": "electronics"}]';

MySQL, the same shape with a native JSON column:

CREATE TABLE customers (
    customer_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

CREATE TABLE orders (
    order_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    line_items JSON NOT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
) ENGINE=InnoDB;

-- Every pending order with an electronics item
SELECT order_id, customer_id, line_items
FROM orders
WHERE status = 'pending'
  AND JSON_CONTAINS(line_items, '{"category": "electronics"}');

MongoDB, where there's no schema to declare at all:

db.orders.insertOne({
  customerId: ObjectId("65f1a2b3c4d5e6f7a8b9c0d1"),
  status: "pending",
  lineItems: [
    { sku: "SKU-1029", category: "electronics", qty: 2, price: 49.99 }
  ],
  createdAt: new Date()
});

db.orders.createIndex({ "lineItems.category": 1 });

// Every pending order with an electronics item
db.orders.find({
  status: "pending",
  "lineItems.category": "electronics"
});

Notice how close the Postgres and MySQL versions are to the MongoDB one. This is the thing that's actually changed since 2015: JSONB and native JSON columns closed most of the "but I need flexible documents" gap that used to send people straight to MongoDB.

One honest flag on that MySQL query above: JSON_CONTAINS with no supporting index is exactly what most tutorials show you, and it's the slow way to run this in production. Keep reading.

I actually ran this, so you don't have to trust a slide deck

Most comparison posts quote someone else's benchmark. Instead of doing that here, I generated 200,000 identical order records (same JSON shape, same random category distribution, same seed) and loaded the exact same dataset into a real PostgreSQL 16 instance and a real MySQL 8.0.46 instance, then timed the exact containment queries shown above.

Small disclosure up front: this ran on a single-vCPU, 4GB sandbox VM, not production hardware. Don't treat the millisecond figures as absolute. Treat the relative story as the finding, because that part holds regardless of the box it runs on.

	Query	Result count	Median latency
PostgreSQL	WHERE line_items @> '[{"category":...}]', no index	27,318 / 200,000	83.6ms
PostgreSQL	Same query, with a GIN index on line_items	27,318 / 200,000	36.3ms
MySQL	WHERE JSON_CONTAINS(line_items, ...), no index (the query most tutorials show)	27,318 / 200,000	225.9ms
MySQL	Same logic, via a STORED generated boolean column plus a normal index	27,318 / 200,000	4.7ms

Both engines agreed on the row count, which cross-checks that the queries are actually correct and comparing like with like.

Two things stand out. First, unindexed, Postgres outperformed MySQL by roughly 2.7x on this exact containment pattern. Second, and this is the part most comparison posts skip entirely: once you index MySQL properly with a STORED generated column, it comes out faster than Postgres's GIN index for this specific pattern, not slower.

The lesson isn't "MySQL is secretly faster." It's that JSON_CONTAINS without a matching index, which is what nearly every MySQL JSON tutorial shows you, is leaving most of MySQL's actual performance on the table. Postgres's GIN index is closer to a reasonable default for JSONB; MySQL's fast path requires you to know to build it. That's a real, practical difference in how much JSON expertise each database demands from you, and it's more useful than either database's marketing number.

The Postgres schema, load, and benchmark script are straightforward to reproduce: create the tables shown earlier, load a comparable dataset, run EXPLAIN ANALYZE before and after adding the GIN index, and compare.

What the broader benchmark literature shows

Beyond this one query pattern, there's an older but far more detailed benchmark worth knowing, with an upfront caveat: it's dated, and it's worth being precise about what it actually measured rather than repeating the rounded-off version other 2026 blog posts pass around.

EnterpriseDB and OnGres ran a three-part benchmark in 2019 comparing PostgreSQL 11 against MongoDB 4.0. It's the most detailed public benchmark of these two databases that exists, but both have shipped several major versions since, including MongoDB's own multi-document ACID transactions maturing considerably. Treat what follows as historical signal, not a current-generation verdict.

The three tests told three different stories. A custom airline-booking transaction benchmark had Postgres processing over 20,000 transactions per second at high concurrency while MongoDB topped out around 1,800, a 4-15x gap depending on isolation level. A separate sysbench OLTP test found Postgres 2.7-3.2x faster when the dataset fit in memory, widening to 25-40x once the dataset grew past what fit in RAM. A third test, querying a year of GitHub Archive data stored as JSON in both engines, was the closest race of the three: Postgres won three of four queries by 22-53%, and lost the fourth by 22%.

The latency numbers are worth citing precisely instead of loosely, because this is exactly where secondary sources blur things: at 256 concurrent threads in the transaction benchmark, MongoDB's 99th-percentile latency hit 377ms against Postgres's 35ms. Postgres's median latency, separately, stayed under 10ms across every concurrency level tested. Several 2026 recap posts compress that into "MongoDB's p99 exceeds 250ms while Postgres stays under 10ms," which quietly swaps in Postgres's median for its p99. Both individual numbers are real; the comparison isn't apples to apples.

The pattern that holds up, from that 2019 data and from the benchmark I ran myself above: indexing strategy and connection handling change the outcome more than the choice of database does. Postgres tends to win joins, complex queries, and high-concurrency transactions by a wide margin. MongoDB's disadvantage shrinks on workloads that fit entirely in memory and don't need cross-document consistency. Benchmark your actual query patterns and your actual indexes before trusting anyone's numbers, including the ones in this article.

Scaling: replicas, sharding, and what's actually built in

PostgreSQL scales vertically first, then through streaming read replicas. Getting real horizontal write scaling means adding Citus or a similar extension, or building sharding logic into your app.

MySQL scales the same way at the core, but has more mature tooling around it. Read replicas are simple and battle-tested. For write-side horizontal scale, most large deployments reach for Vitess, the sharding layer originally built at YouTube and now a CNCF graduated project, which is how YouTube reportedly serves billions of users on top of a MySQL foundation.

MongoDB is the only one of the three with sharding built into the core product from day one. You define a shard key, and the database handles distributing data across nodes plus routing queries to the right shard. Replica sets give you automatic failover without extra tooling. This is MongoDB's clearest structural advantage, and it's a real one if you actually need to scale writes past a single machine.

The AI angle: vector search in 2026

All three databases now do vector search, which matters if you're building RAG pipelines or semantic search.

Postgres has pgvector, and the newer pgvectorscale extension adds a DiskANN-based index that claims up to 28x lower latency at a fraction of the cost of a dedicated vector database. You get vector search, full-text search, and your relational data in one system with one backup process.

MySQL 9.0 added a native VECTOR data type for storing and querying embeddings directly in columns, aimed at teams that don't want a separate vector store bolted onto an existing MySQL-based app.

MongoDB ships Atlas Vector Search as a managed feature, and it's become a real differentiator for AI-native startups. MongoDB's own customer write-ups point to companies like DevRev building agent memory systems on top of it, citing faster iteration versus keeping vectors and metadata in separate systems.

If you're already on Postgres, pgvector is very likely good enough and saves you an entire extra system. If you're greenfield and fully document-native, Atlas Vector Search removes a decision.

Licensing: the part nobody reads until it matters

This one's boring until it isn't, and then it costs you weeks of legal review.

PostgreSQL uses the PostgreSQL License, a permissive BSD-style license with no strings attached. No company controls it. Nobody can change the terms out from under you.

MySQL Community Edition is GPLv2, and Oracle also sells commercial Enterprise editions with extra features like the dynamic data masking mentioned above. Fine for almost everyone; worth a glance if you're embedding MySQL inside a product you resell.

MongoDB Community Server has shipped under the Server Side Public License (SSPL) since 2018, replacing the AGPL it used before. The Open Source Initiative has never approved SSPL as an open-source license, because it requires anyone who offers MongoDB "as a service" to a third party to open-source their entire surrounding application stack, not just their changes to MongoDB itself. Most companies never trigger that clause. If you're building a SaaS product that exposes database functionality to customers, read the actual FAQ before you architect around it.

Who actually runs what

Real deployments tell you more than feature lists.

PostgreSQL: Instagram runs one of the largest known Postgres deployments in the world. Coinbase uses it for account and transaction data where ACID guarantees aren't optional. Spotify, Reddit, and Apple all run it at scale. Multiple 2026 technology-adoption trackers put production Postgres deployments in the tens of thousands of companies, though their crawl methodologies aren't independently auditable, so treat the scale as directional rather than exact.

MySQL: Meta has run one of the largest MySQL fleets on earth for years, going as far as co-developing WebScaleSQL with Google, LinkedIn, and Alibaba to solve shared scaling problems. YouTube's backend runs on MySQL through Vitess. Booking.com and most of the WordPress-powered internet run on it too.

MongoDB: Wells Fargo's own case study describes building an operational data store on MongoDB for its Cards 2.0 initiative, now handling more than seven million transactions with sub-second response and serving 40% of external vendor traffic. CSX, the US railroad, migrated its real-time operations platform onto MongoDB Atlas to keep it running 24/7 through the cutover. Electronic Arts has used it since its FIFA Online 3 days to scale a multiplayer title to millions of concurrent players, per MongoDB's own case-study archive, though that specific example is now over a decade old.

The Uber story, and why it's more nuanced than the headline

If you've been in backend engineering for more than a year, you've seen the 2016 Uber engineering post titled "Why Uber Engineering Switched from Postgres to MySQL." It's still one of the most-cited database posts ever written, and it's worth understanding accurately instead of just as ammunition.

Uber's actual complaints were specific: Postgres's process-per-connection model cost more memory than MySQL's thread-per-connection model at their connection counts, secondary indexes pointed to physical row locations that changed on every update (write amplification), and replication was verbose across data centers. They built a MySQL-based sharding layer called Schemaless to solve it.

That post is from 2016, describing Postgres 9.3-era behavior. PostgreSQL 18's async I/O subsystem and a decade of replication improvements have closed a meaningful part of that gap. Old benchmarks describing old versions don't transfer cleanly to 2026 decisions, in either direction.

Use case matrix: what to actually pick

Fintech, payments, anything with money. PostgreSQL. Full ACID transactions with no practical limits on complexity or duration, decades of correctness under real audits, and PostGIS if you need geofencing on top.

Early-stage startup, schema still moving fast. Either PostgreSQL with JSONB columns for the unstable parts, or MongoDB if your entire data model is naturally document-shaped. Prototype both against your real access patterns before committing.

Content management, blogs, anything WordPress-adjacent. MySQL. The hosting ecosystem, tutorials, and plugin compatibility make it the path of least resistance, and read-heavy CMS traffic is exactly what it's tuned for.

Product catalogs and content with wildly variable attributes. MongoDB. A shoe and a laptop have almost nothing in common as database rows, but they're both natural documents.

Analytics-adjacent application logic. PostgreSQL. Window functions, CTEs, and a query planner that handles complexity neither of the other two matches.

RAG pipelines and AI agent memory. PostgreSQL with pgvector if you already run Postgres. MongoDB Atlas Vector Search if you're document-native from the start and want vectors plus flexible metadata in one query.

IoT, event streams, logs with unpredictable shape. MongoDB, or Postgres with TimescaleDB if the data is fundamentally time-series with a known schema.

You genuinely need to shard writes across hundreds of nodes today, not eventually. MongoDB's native sharding beats bolting Citus or Vitess onto something else, unless you already have that infrastructure running.

A decision flow

FAQ

Is PostgreSQL faster than MongoDB? Neither wins outright. Postgres tends to win joins, complex queries, and high-concurrency transactions. MongoDB tends to win simple point lookups and raw insert throughput on unstructured data. Test your actual query patterns.

Is MySQL dead in 2026? No. DB-Engines' own H1 2026 report shows Postgres posted the largest popularity-score gain of any database that half-year, with MongoDB not far behind in third place. But that's a momentum metric. By DB-Engines' absolute score, which weighs years of accumulated job postings, forum mentions, and search volume, MySQL still sits ahead of Postgres in the overall rankings. MySQL just got a new LTS line (9.7) with real enterprise features too. Read: not the default pick for new greenfield projects anymore, but nowhere close to going away.

Can PostgreSQL replace MongoDB entirely? For most workloads, yes. JSONB with GIN indexes covers a large share of what used to require MongoDB, while keeping full SQL and ACID transactions. The exceptions are workloads that need MongoDB's native sharding at massive scale, or teams that are fully committed to a document-first architecture.

Should a startup default to PostgreSQL or MongoDB in 2026? PostgreSQL, unless your data model is unambiguously document-shaped from day one. It handles more future scenarios (analytics, AI, geospatial, strict consistency) without adding a second database later.

Is MongoDB safe to use commercially? Yes, for running it yourself. The SSPL only creates obligations if you offer MongoDB's functionality as a hosted service to third parties. Read the actual license text if that describes your product.

The honest verdict

Postgres earned its 2025-2026 momentum the hard way: by quietly closing the gaps that used to send people to specialized databases, one extension at a time. It's the right first choice for most new projects in 2026, and the Stack Overflow 2025 Developer Survey usage numbers back that up.

MySQL isn't losing because it got worse. It's losing mindshare because it stayed simple while Postgres got more capable, and simple stops being the deciding factor once teams need more than a fast key-value store with SQL on top.

MongoDB's document model still solves a real problem: data that doesn't want a fixed shape. Pick it when that's actually true for you, not because a tutorial from 2018 said schemaless was the future.

Run the workload. Check the license. Read the actual docs instead of the comparison articles, including this one.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

The Sandbox Held. The Headline Didn't.

Sanjay Singh — Mon, 07 Sep 2026 05:32:04 +0000

On September 5, 2026, a post titled "Actively exploited sandbox RCE in all Chromium versions" sat near the top of Hacker News. By the time it had been reblogged twice, "sandbox RCE" had quietly become "an attacker can take over your machine by opening a tab," and "all Chromium versions" had become "there is no fixed version yet."

Neither is true. The gap between the headline and the advisory is a better story than the panic version, mostly because closing it means understanding how Chromium is actually built.

The bug underneath the headline is real, serious, and was still being weaponized against real targets as this was written. It's called CVE-2026-85046, it lives in V8, and Google shipped the fix two days before this piece went up.

What it is not, on its own, is a sandbox escape. That distinction is the whole point of this piece: not to downplay a genuinely dangerous vulnerability class, but to explain what Chromium's architecture actually bought its two billion or so users while the bug was live.

What CVE-2026-85046 actually is

Google patched the flaw in Chrome 152.0.7977.82/.83 (Windows/macOS) and 152.0.7977.82 (Linux) on September 3, 2026. It's a type-confusion bug in Maglev, V8's mid-tier JIT compiler, rated CVSS 8.8.

The U.S. Cybersecurity and Infrastructure Security Agency added it to the Known Exploited Vulnerabilities catalog the next day, giving federal civilian agencies until September 18 to remediate under Binding Operational Directive 22-01. That deadline binds federal agencies specifically, not the rest of us, but it's still the industry's highest-confidence public signal that a bug is actually being used against real targets.

Security researcher Salvatore Gulizia, who goes by "Serotav," reported the bug to Google on August 4, 2026, and was paid a $1,000 bounty. He published a full technical writeup on his own blog on August 28, before Chrome 152 had even shipped, laying out how he'd chained the bug with a separate, already-known sandbox-escape vulnerability to enter Google's v8CTF competition.

That detail matters more than it looks. It's Gulizia's own account of how he built a full exploit chain, and it undercuts the "sandbox RCE" framing on its own terms: that framing implies the bug itself breaks the sandbox. It doesn't. What it gets you is arbitrary read/write inside the sandboxed renderer process, which is bad, but a different and much more contained thing.

Google's standard Vulnerability Reward Program pays far more for renderer remote-code-execution reports, which makes the $1,000 bounty worth a second look. The V8 zero-day patched three months earlier, CVE-2026-11645, earned its reporter $55,000 for what was, on paper, a comparable class of bug.

The gap isn't about severity. Gulizia reported through v8CTF, Google's standing capture-the-flag program, which pays a fixed prize regardless of impact, rather than through the standard VRP pipeline that scales rewards to real-world damage. Same bug class, wildly different payout, simply because of which door it walked in through.

Because V8 is shared code across the whole Chromium project, the bug was never really Chrome-specific. Microsoft Edge, Brave, Opera, and Vivaldi all ship the same vulnerable V8 code, and each needs its own vendor update on its own schedule. That's the part of "all Chromium versions" that's actually true, and actually underreported: not that Chrome itself remains unpatched, but that patching Chrome does nothing for the other four browsers sitting in the same Applications folder.

Here's how the clock actually ran:

Gulizia's technical writeup, which laid out the exploitation approach without being a copy-paste weapon, went public on August 28, six days before Chrome 152 shipped. The disclosure-to-patch window was already short; the disclosure-to-public-writeup window was shorter still.

Chromium's actual defense-in-depth

Most coverage of "sandbox RCE" skips the part where Chromium isn't one program with one set of privileges. It's a federation of OS processes with deliberately unequal trust, wired together over an internal IPC layer called Mojo:

Three things in that diagram do the actual work.

Site Isolation puts each origin in its own OS-level renderer process, so a bug triggered by evil.example can't directly read memory belonging to your bank's tab in the next process over. They're not just logically separate; they're physically separate address spaces.

It wasn't originally conceived as a browser-exploitation defense at all. Google fast-tracked its rollout in 2018 as a direct response to Spectre, the speculative-execution hardware flaw that meant any JavaScript sharing a process with sensitive data could potentially read it through a timing side channel.

A fix built for a CPU-level information leak ended up doubling as one of the sturdiest walls against process-level exploitation. Defense-in-depth built for one threat often pays off against a completely different one.

The renderer OS sandbox strips the renderer process of almost all direct syscall access: no arbitrary file opens, no raw sockets, no spawning processes. Everything it needs, like rendering a page or fetching a resource, goes through Mojo IPC to the privileged Browser process, which can apply its own policy checks on every request.

The V8 Sandbox is the newest and narrowest layer, and it's the one CVE-2026-85046 actually lives inside. It's an in-process mitigation: heap pointers inside V8 are represented in a way that keeps a corrupted pointer from forging an arbitrary address into the rest of the process.

Samuel Groß, who leads V8 security at Google, has made the underlying argument plainly: V8's worst bugs are mostly subtle compiler logic errors rather than classic memory-safety bugs, which is exactly why ordinary memory-safety fixes don't reach them. He's called the V8 Sandbox "a necessary step towards memory safety" for that reason. It shipped as the default in Chrome 123, in early 2024.

Put together: reaching the Browser process, and from there the OS, means beating Site Isolation (or already being on the same origin), beating the renderer's OS sandbox, and beating the V8 Sandbox — or finding one bug that skips past all three at once, which is a different and much harder thing than what Gulizia found. CVE-2026-85046 broke the third layer only. That's a real result. It is not sandbox RCE.

Where the bug lived, and how it worked

To see why a bug like this keeps recurring, it helps to look at where in V8 it actually sits. V8 doesn't run JavaScript one way; it pushes code through increasingly aggressive tiers, promoting "hot" functions to faster, more speculative compilers as it learns more about the types actually flowing through them:

Maglev, added to V8 in 2023, sits between the baseline Sparkplug JIT and the deeply optimizing TurboFan. One of its optimizations, TryReduceArrayPrototypeSort, replaces calls to Array.prototype.sort on small arrays (16 elements or fewer) with a much cheaper inline insertion sort, but only once it has observed, through type feedback, that a call site has been trained on both of V8's "packed" array representations: PACKED_SMI_ELEMENTS for small integers and PACKED_ELEMENTS for arbitrary objects.

Because a JavaScript comparator function can have side effects, the inlined sort can't safely sort in place. It copies the array's contents into a temporary buffer, sorts the copy, and then re-checks the original array's map before writing the sorted values back, since the comparator might have mutated the array in the meantime.

Gulizia's writeup, linked at the end of this piece, shows exactly what that check verifies: that the array's current map is present somewhere in the set of maps the call site was trained on, not that it's the same map the array had when sorting began.

That's the whole bug. Array.prototype.fill(), when it replaces every element of an array, is allowed to migrate the array's map backward, from PACKED_ELEMENTS to PACKED_SMI_ELEMENTS, without reallocating the backing store, since both representations are, under the hood, a plain FixedArray of tagged pointer-sized slots.

Call fill() inside the comparator, and the trained-maps check passes even though the array now claims to hold raw integers over memory that still holds real object pointers. From there it's standard V8-exploitation technique: reading the confused slots leaks heap addresses, an "addrof" primitive, and writing through them, using an operation like Array.prototype.unshift() that shifts elements without triggering V8's garbage-collector write barrier, turns into a fake-object primitive.

Chain the two together and you have arbitrary read/write across the JavaScript heap: still inside the V8 Sandbox, still inside the renderer's OS sandbox, and still, on its own, nowhere near your filesystem.

It's worth being precise about what the V8 Sandbox does and doesn't stop here. It doesn't prevent type confusion inside the JS heap; it can't, since that confusion happens entirely within V8's own bookkeeping, before any pointer goes anywhere.

What it prevents is that confusion turning into a pointer that reaches outside the sandboxed heap region into the rest of the renderer process's memory. Gulizia's addrof and fakeobj primitives work on sandboxed, compressed heap references: powerful within that boundary, useless outside it without a second bug that itself breaks out of the Sandbox. That's the layer CVE-2026-85046 broke, and the layer it didn't.

The fix Google shipped is narrow and fairly unglamorous: Maglev simply stops inlining Array.prototype.sort once a call site has been trained on mixed element kinds. No architectural change was needed here. The architecture wasn't what failed; one optimization's bookkeeping was.

Why V8 keeps producing this exact bug class

CVE-2026-85046 was the third V8 zero-day patched in Chrome in 2026, out of six actively exploited zero-days total:

Every one of 2026's six actively-exploited Chrome zero-days carried an identical CVSS score of 8.8. Half of them lived directly in V8; the other half hit adjacent memory subsystems (Skia's 2D rasterizer, the Dawn WebGPU backend) that feed the same rendering pipeline.

That's not a coincidence, and it isn't new. Google's own security research has found that roughly sixty percent of Chrome exploits observed in the wild between 2021 and 2023 originated in V8.

The reason is structural, not a staffing problem. V8's most dangerous bugs are rarely classic memory-unsafety, like a use-after-free or an out-of-bounds write; they're subtle logic errors in speculative compiler optimizations, exactly like the map-check gap here. Conventional memory-safety tooling (bounds checking, Rust rewrites, hardware memory tagging) doesn't reach a bug where every individual memory access is, technically, in-bounds.

The V8 Sandbox exists because Google's own team decided this bug class can't be eliminated at the source, only contained after the fact.

This particular shape of bug, a fast-path optimization for a built-in Array method gated on element-kind feedback that a callback can invalidate mid-operation, isn't a one-off.

Array and TypedArray methods that accept a user callback (sort, map, forEach, splice, and their relatives) have been a recurring source of V8 type-confusion bugs for years, precisely because each one creates the same structural trap: the engine has to trust that an array's shape hasn't changed between when it checked and when it acts, and a callback is a standing invitation to change it in between.

Fixing TryReduceArrayPrototypeSort closes this instance. It doesn't close the pattern, and V8's own security team would likely be the first to admit it.

The other three 2026 zero-days (a CSS font-handling use-after-free in February, a Skia 2D-rasterizer out-of-bounds write in March, and a Dawn/WebGPU use-after-free in April) sit in the same broad territory: native C++ code processing untrusted, attacker-shaped input as fast as possible. None of the six needed a user to do anything beyond load a page.

The blind spot: headless Chrome, Electron, and CI images

Most coverage of a Chrome zero-day assumes a human with a mouse. A meaningful share of Chromium's install base doesn't have one. Headless Chrome renders PDFs and screenshots in backend services; Electron embeds a full Chromium in thousands of desktop apps; CI runners spin up Chrome to run end-to-end test suites against pages they don't fully control.

None of that changes the exploit's mechanics; rendering the malicious page is still what triggers it. But it does change the blast radius, since a compromised renderer in a CI job or a scraping pipeline can sit far closer to real credentials (CI secrets, internal network access) than a compromised renderer in a consumer's browser tab.

Electron makes this worse in one specific, structural way: unlike Chrome or Edge, an Electron app doesn't auto-update its bundled Chromium independently of the app itself. Its maintainers have to bump the Electron dependency, rebuild, test, and ship a new release before users ever see the fix.

That adds days to weeks on top of Google's own patch timeline as a matter of routine, and sometimes much longer for apps still pinned to an older Electron major version. A vulnerable V8 build can keep shipping inside a popular desktop app long after Chrome itself is clean.

It also changes the patch story in a way that's easy to miss. Chrome updates its binaries on disk but doesn't take effect until the process restarts, which matters more for a long-lived headless service or a kiosk build than for a browser someone closes and reopens every day.

VM templates, Docker base images, and CI runner images are exactly the kind of artifact that quietly reverts a patched Chromium back to a vulnerable one the next time it gets rebuilt from an older layer. If your team ships Electron, runs headless Chrome for PDF generation or link previews, or bakes Chrome into a CI image, updating Chrome is a fleet-management problem, not a one-click menu action.

What to actually do about it

Update and restart, not just update. Downloading the patch in the background doesn't protect a running process; every Chrome and Chromium-based browser needs a full relaunch to load 152.0.7977.82 or later.
Check every Chromium-based browser separately. Edge, Brave, Opera, and Vivaldi each ship their own build on their own timeline. Updating Chrome does nothing for the others.
Audit build images, not just endpoints. CI base images, Docker images bundling headless Chrome, and Electron app bundles are common places for a patched version to silently regress on the next rebuild.
Treat anomalous renderer behavior as a signal. A Chrome renderer process spawning a shell, hitting non-Google infrastructure, or restarting unexpectedly is a stronger detection signal than trying to catch the initial JavaScript exploit, which executes entirely in-memory and leaves little to fingerprint.
If you operate Federal Civilian Executive Branch infrastructure, the CISA KEV deadline of September 18, 2026 is a binding compliance date, not a suggestion.

Is "the sandbox held" the real headline?

Here's the opinion part, since a headline correction alone doesn't quite earn the label "opinion breakdown." Chromium's process-and-sandbox architecture is, in my view, one of the more genuinely successful pieces of applied security engineering in mainstream consumer software, and that fact is nearly invisible in how zero-days get covered, including, this time, in the framing of the original submission.

A bug that gets arbitrary read/write on the JavaScript heap and still can't touch your filesystem is exactly what defense-in-depth is supposed to produce. The fact that it takes real effort to explain why that's true, and that the effort mostly doesn't get made, says more about how security coverage works than about the bug itself.

That doesn't make the instinct to patch immediately wrong. It's the correct instinct, and the bug really is being used against real targets today. But there's a second, quieter problem that the accurate framing surfaces and the inaccurate one doesn't: Gulizia's complete technical writeup, methodology included, went live on a public blog six days before most of Chrome's install base had the fix.

Google's own restrained-disclosure policy (withholding bug-tracker details until most users update) depends on nobody else publishing the technical path first. A researcher publishing for CTF credit, entirely within the rules of a program Google itself runs, ended up creating exactly the situation that policy exists to prevent.

That tension, between what's good for an individual researcher's career and what's good for the ecosystem's rollout timing, is the more interesting story underneath this one. "Sandbox RCE in all Chromium versions" doesn't leave room for it.

None of this is unique to Chrome. Almost every high-profile CVE goes through the same compression on its way to a headline: a precise, hedged advisory gets summarized by a blog, re-summarized by an aggregator, and re-titled by whoever wants the most clicks off the front page. The words that survive that process tend to be the scariest ones, not the most accurate ones.

"Sandbox RCE in all Chromium versions" isn't really a lie. It's a headline that won a game of telephone. The advisory it started from was more careful than that, and so, it turns out, was the researcher who found the bug.

OpenBot: A Technical Architecture Review of CopilotKit's Governed Agent Runtime

Sanjay Singh — Sun, 06 Sep 2026 05:54:12 +0000

What shipped

CopilotKit released OpenBot's first alpha on August 17, 2026, then shipped three more tagged versions inside the following five days, ending with v0.0.4 on August 22. The project is MIT licensed and lives at github.com/CopilotKit/openbot. The pitch: a Bot works from a browser and a set of files it shares with no other Bot, limited strictly to whatever an administrator has explicitly granted it. A policy check runs against every action before it executes, and the decision, whether allowed or refused, is written to an audit trail afterward.

Where it sits

OpenBot is not CopilotKit's first release. The company stewards AG-UI, an open protocol for agent-to-application communication that OpenBot's own documentation lists as compatible with LangGraph, Mastra, CrewAI, Pydantic AI, and Google ADK, among other frameworks. CopilotKit raised a $27 million Series A in May 2026, led by Glilot Capital, NFX, and SignalFire, to build out AG-UI and an enterprise layer on top of it, according to TechCrunch. OpenBot is the self-hosted, open half of that layer: governance is its main feature rather than something bolted on afterward.

The shape of a deployment

A deployment is eight moving parts, most of them Docker containers: app, the React interface; server, a Hono API that also holds auth, policy, audit, and the coworker roster; agent-computer, one Chromium instance per Bot with its own workspace. agent-bot and agent-langgraph are the two example Bots that ship in the box, and a supervisor creates and tears them down. PostgreSQL with pgvector holds everything else, and CopilotKit Intelligence, an external service, holds threads and memory.

Component	Port	Role
app	3010	React/Vite interface for channels, chat, and admin pages
server	3001	API, auth, policy, audit, plugins, coworkers, channels
agent-computer	4100	Chromium, workspace, browser profile per Bot
agent-bot	4200	Proof-of-concept AG-UI Bot
agent-langgraph	4201	LangGraph AG-UI Bot
supervisor	4500/4300	Creates, stops, resets per-Bot computers
PostgreSQL + pgvector	5432	Policy, audit, credentials, grants, channels
CopilotKit Intelligence	external	Durable threads and memory

Source: docs/architecture.md.

The gateway is the whole point

A Bot never reaches a browser, a file, or an MCP server directly. Every attempt loops back through the server first, which works through a fixed sequence before anything happens: resolve what the Bot is pointing at, using the snapshot on file, weigh that against the live policy, log the outcome, and only then hand the request to the computer. A second log entry follows if the computer itself fails to carry the action out, and nowhere in that sequence can an action complete before its own record does.

Each rule is written as a CEL expression that can inspect fields such as tool.name, bot.id, page.host, element.ref, or mcp.tool. Denials are always weighed before permissions, and the engine treats its own malfunctions as a reason to say no: nothing gets through under a missing policy, and a deny rule that breaks still counts as a refusal.

There's a catch worth flagging: the shipped default is deny: [] and allow: ["true"], which permits everything until an administrator writes a restrictive rule at /admin/boundaries. "Fails closed" describes what happens when the policy breaks, not what the box does on day one.

One computer per Bot

With COMPUTER_SUPERVISOR_URL set, every Bot gets its own container: its own Chromium, its own /workspace, its own logins. Without it, Bots share one computer, which is a meaningfully weaker guarantee. Nothing on the host network can simply guess its way into a Bot's logged-in browser, either: computers only listen on the loopback address, and every request to one has to present a token scoped to that specific container.

Setting COMPUTER_RUNTIME to runsc switches these containers to gVisor on hosts that support it, trading a bit of performance for a stronger sandbox boundary. A set of SPIRE services for workload identity is already defined in the compose file, though the shipped start script leaves them off for now.

Browser navigation is limited to plain http and https, and anything that resembles a cloud metadata address is refused no matter how the rest of the deployment is configured, closing off a well-known trick for getting an agent to leak cloud credentials it was never supposed to touch. The same validation applies to custom agent endpoints, not just page navigation: pointing a coworker at your own AG-UI server runs through those identical checks, and any authorization header attached to it is stored write-only, never returned by the API afterward.

When a Bot has to stop

When a Bot runs into something it shouldn't push through alone, a sign-in page or a two-factor prompt, it stops and flags a person rather than guessing at a way around it. Control then shifts to that same person inside the live-view panel the Bot had been using, and each stage of that handoff becomes its own logged event: computer.help_requested, computer.control_taken, computer.control_released.

For as long as a human holds the controls, anything the Bot itself attempts is turned away outright rather than held for later. Entering a secret gets the same careful handling: what ends up in the audit trail is the fact that one was requested and its length in characters, not the value a person typed in.

Tools are governed twice

MCP connections and skills draw from the same underlying grant table, but who is allowed to create each one differs. Adding an MCP server is an administrator's call alone, since it reaches outside systems using stored credentials, and the built-in catalogue tops out at Atlassian, Box, Slack, Salesforce, and ServiceNow. Anything not explicitly confirmed as read-only, including tools from custom servers, defaults to being treated as a write.

Skills are just instructions, invoked with a slash in the composer. A skill can declare which tools it expects, but declaring one grants nothing: the actual offer is still intersected with whatever that Bot was separately granted.

That distinction mattered for a scaling problem CopilotKit found in practice. A model's accuracy at picking the correct tool drops off sharply once the list of options grows: reliable around ten, shaky by the time it reaches thirty. As of v0.0.3, that ceiling is handled directly: a Bot holding more than a dozen granted tools is now shown only the subset that the skills matching each message actually declare, not its entire grant list.

A new audit event, mcp.tools_discovered, records how many tools were offered out of how many were granted, and why. That answers the harder failure mode of a Bot that silently calls nothing at all and answers from memory instead, which is a worse outcome than calling the wrong tool.

That narrowing had nothing to draw on until v0.0.4, though: a brand-new deployment ships with no skills at all, so on a fresh clone there was nothing to match incoming messages against, and the feature never actually switched on. v0.0.4 added an optional skills.yaml a tenant package can ship, seeding a starting set of skills at boot so the narrowing has something to work with from the very first run.

Answers can be a component, not just prose

Bots can also answer with a rendered component instead of only prose, the same generative-UI pitch CopilotKit makes to enterprises elsewhere: a revenue question comes back as an interactive chart the company itself designed, not a wall of text. Compiled components publish automatically the first time a catalogue sync sees them; ones built by hand in /admin/playground stay drafts until someone explicitly publishes them. Either way, every render call still asks the server whether that component exists, is published, and hasn't been withheld from the calling Bot specifically.

What four days of patches reveal

Two changes between v0.0.1 and v0.0.4 are worth reading closely, because they show what this kind of gateway has to get right that an ordinary CRUD app does not. The first, in v0.0.2, is a deliberate architectural reversal: OpenBot stopped maintaining its own index of company documents. Early on, a Google Drive connector had run as a single privileged service account, impersonating whichever user asked, and copying files it found into a local vector store.

Under that design, two different people asking the same question got an answer shaped by what one shared credential could see, not by what either of them was individually allowed to see. Removing someone's Drive access did nothing to the copy already sitting in OpenBot's own database. The fix was to delete the index rather than patch it: the rebuilt connector holds no local copy of anything, and each person links their own Google account instead of relying on the shared one.

A Bot now reads Drive scoped to whichever person is asking, requesting a fresh access token on every call instead of reusing a cached one. That means revoking someone's access at Google shows up the moment they try again, not whenever some cached copy of their permission finally times out. Keeping a second, separately-permissioned copy of someone else's data turned out to be a bigger liability than the latency it was saving.

The second change, landing in v0.0.4, is a straightforward security bug rather than a design choice. When a Bot wants to click something on a page, it points at that element using a reference saved in an earlier snapshot, and the server has to look that reference up before any policy rule can weigh in. Before v0.0.4, a lookup that failed to resolve was not treated as a reason to stop.

Instead the action proceeded with an empty description of what was being clicked, so a deny rule written against element.name or element.role had nothing to compare against and simply never matched. The one case this slipped through on was a computer container restarting under an old, previously-taken snapshot after a redeploy. The computer's own staleness check only flags a mismatch between its internal counter and the reference, so a reference that was outdated on both sides looked perfectly consistent to it.

Practically, that meant the exact same click, against the exact same policy, could be refused before a redeploy and silently allowed right after one. As of v0.0.4, any reference the server cannot actually resolve is refused outright rather than passed through with a blank element description, and the person driving that Bot is asked to capture a fresh snapshot before continuing.

What "open source" does not quite mean here

The code is MIT licensed, but a working deployment is not fully self-contained. Durable threads and memory live in CopilotKit Intelligence, an external service that requires its own project and a license token obtained through npx copilotkit login, not in the PostgreSQL instance sitting next to everything else. There is also no hosted option yet: the release notes list it as local-only, and the default run mode, OPENBOT_DEV_NO_AUTH, admits every request as a single administrator until Google sign-in is wired up separately.

Running it

A deployment needs Docker, Bun 1.3 or newer, a CopilotKit Intelligence project and license, and a model key: OpenAI for the built-in Bot, or OpenAI, Anthropic, or Google for the LangGraph one. Copy .env.example to .env, then run npx copilotkit login, project select, and license --write to populate the Intelligence credentials, fill in a model key, and generate a KEY_ENCRYPTION_KEY.

bun install followed by bash scripts/start.sh brings up Postgres, the computers, and both servers, reachable at localhost:3010. The README's suggested first test is asking a Bot to open Hacker News and summarize the top story, then checking /admin/audit to see the decision it recorded.

Verdict

Four tagged releases in five days is a sign of a team actively shepherding something rather than one that shipped and walked away, but it is also a sign this is genuinely alpha: the stale-citation fix in v0.0.4 was a real gap in the exact mechanism the whole project is sold on. Teams evaluating agent governance patterns right now have more to learn from reading docs/architecture.md than from running it in anything resembling production this early.

The idea worth taking regardless of whether OpenBot itself gets used is the ordering it enforces: resolve the target, decide against policy, record the decision, only then act, with a refusal that names the exact rule that caused it.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Nvidia Just Bought Hugging Face for $12.9 Billion — Here's What It Means for Developers

Sanjay Singh — Fri, 04 Sep 2026 05:09:52 +0000

TL;DR: On September 2, 2026, Nvidia signed a definitive agreement to acquire Hugging Face — comprising an $11.9 billion cash payment plus up to $1 billion in employee retention equity, roughly $12.9 billion total. It's Nvidia's second-biggest acquisition ever, behind only the $20 billion Groq deal from December 2025, and well ahead of its previous largest deal, the $7 billion Mellanox acquisition in 2019. Nvidia says the platform stays open — no requirement to use Nvidia hardware, continued support for AMD and Intel libraries. The real question, according to nearly every analyst covering the deal, isn't the stated policy. It's whether a platform owned by the dominant GPU vendor stays neutral by default, or drifts Nvidia-first through ordinary product prioritization. Expect a genuine antitrust review — this is the first Nvidia AI acquisition structured as a full merger rather than the licensing deals that avoided one.

What Was Actually Agreed

Nvidia's September 2, 2026 SEC filing confirms a definitive agreement to acquire Hugging Face, described as operating a platform and community for developing, sharing, and deploying open-source models, datasets, and applications. The transaction includes an approximately $11.9 billion purchase price to Hugging Face stockholders, plus an equity-based retention program of up to approximately $1 billion for Hugging Face employees joining Nvidia. That combination is where the widely reported $12.9 billion figure comes from.

The deal is expected to close in the first half of 2027, pending regulatory approval. Until then, both companies operate independently.

This is Nvidia's second-biggest acquisition on record, trailing only the roughly $20 billion purchase of assets from chipmaker Groq in December 2025. It dwarfs Nvidia's other recent deals, including the $700 million purchase of Israeli AI infrastructure firm Run:ai in 2024, and comfortably exceeds what was previously Nvidia's largest acquisition — the nearly $7 billion purchase of chipmaker Mellanox in 2019.

At an annualized revenue of roughly $150 million recently disclosed by The Information, the deal values Hugging Face at somewhere between 79× and 86× that figure — 79× if you count only the $11.9 billion cash portion, 86× including the retention equity. Either way, a multiple that only makes sense as an infrastructure bet, not a near-term earnings multiple.

Why Hugging Face Said Yes

This wasn't Nvidia cold-approaching a reluctant target. Hugging Face CEO Clément Delangue told CNBC he approached Nvidia first, describing the summer conversations as a realization that Hugging Face and open-source AI had reached a turning point requiring more resources and scale. Delangue called Nvidia "a perfect home" for the company.

That framing matters given the history. Nvidia already held a stake in Hugging Face from a 2023 Series D round worth $235 million alongside Salesforce and Google, which valued the company at $4.5 billion. Earlier in 2026, Hugging Face had turned down a separate $500 million investment offer from Nvidia that would have valued the company at $7 billion.

Eighteen months later, the number is roughly 1.8× that rejected valuation — and this time Hugging Face brought the conversation to Nvidia, not the other way around.

Why Nvidia Wants This

The stated rationale is straightforward. Nvidia CEO Jensen Huang wrote in a blog post that the companies will scale Hugging Face's platform, strengthen its infrastructure, and expand access to AI for developers and institutions worldwide.

The strategic rationale underneath is less about Hugging Face's revenue and more about defending Nvidia's position further up the stack. Every major closed-source AI lab is working to reduce its dependence on Nvidia silicon, to varying degrees — Google has run its own TPU line for years, Amazon designs the Trainium chips that Anthropic trains much of its work on, and OpenAI has reportedly pursued custom silicon of its own.

None of that spending disappears because of this deal. But a thriving open-source ecosystem that still runs overwhelmingly on Nvidia hardware is a hedge against how fast any of it matters — it keeps enterprise customers with a credible alternative to the closed labs tethered to Nvidia, regardless of what those labs do with their own chips.

Nvidia had also scaled back its own DGX Cloud business about a year earlier. This deal reads as a return to that platform ambition — this time by owning the distribution layer rather than building it from scratch.

Owning the platform layer directly above the chip means Nvidia doesn't need to win every individual model or framework fight — it only needs the layer where developers make that choice to keep running on its hardware by default.

What Nvidia Has Promised — And the Catch

Huang said Hugging Face will remain an open platform for the entire AI ecosystem, with developers free to choose their own models, frameworks, clouds, inference providers, and computing hardware — Nvidia systems will not be required. Nvidia's SEC filing formalizes this commitment, stating the company will keep Hugging Face's platform open, consistent with its existing practices, including support for other silicon vendors.

That's a real, filed commitment — not just a talking point in a blog post. But nearly every analyst covering the deal points to the same structural tension underneath it.

Hugging Face currently maintains Optimum AMD and Optimum Intel as first-class libraries enabling developers to run models on non-Nvidia hardware. Under Nvidia ownership, those libraries could see reduced maintenance investment, slower support for new models, or lower visibility in Hub documentation — not through any explicit policy, but through the ordinary resource allocation decisions of a company whose core revenue depends on Nvidia GPU adoption.

If new library features, quantization formats, or serving optimizations quietly ship Nvidia-first, with other hardware backends catching up months later, that lag compounds — developers gravitate toward the fastest-supported path, and the fastest-supported path becomes the one that runs best on the owner's hardware. No policy decision required. Just normal product prioritization, repeated for a few release cycles.

The closest precedent is Microsoft's 2018 acquisition of GitHub. GitHub kept supporting non-Microsoft integrations, and the platform didn't visibly close off — but critics have long pointed to subtler forms of the same dynamic: which tools get first-class support, which get maintained at arm's length.

This Deal Will Actually Face Antitrust Review

This point separates the Hugging Face deal from Nvidia's recent acquisition pattern. Its deals with Groq and Poolside — an AI coding startup Nvidia has an investment and technology partnership with — were structured in ways that avoided triggering mandatory Hart-Scott-Rodino review, the standard US pre-merger antitrust filing.

The Hugging Face deal is different: an outright acquisition of the platform millions of developers rely on to distribute and discover models, it cannot be structured the same way. It triggers mandatory merger review in both the US and EU.

The FTC and DOJ opened a joint inquiry into competitive AI partnerships in February 2026, specifically examining whether "quasi-merger" structures were designed to sidestep standard antitrust review — making this the first real test of that scrutiny against Nvidia's current acquisition strategy.

For comparison: Nvidia's much smaller $700 million Run:ai acquisition took months of EU review before receiving unconditional clearance, despite Nvidia's roughly 80% share of the AI GPU market being a central point of regulatory concern even at that deal size. A $12.9 billion platform acquisition sitting squarely on top of that same market share is a materially bigger question for regulators to work through.

Don't expect a fast close. The stated H1 2027 timeline already assumes a real review process, not a formality.

What This Means If You Build on Hugging Face Today

For the next several months — likely through the H1 2027 close, and probably well beyond it — practically nothing changes for day-to-day usage. The Transformers library, model hub, and Spaces continue operating as they do now. The acquisition doesn't touch model licensing terms.

What's worth actually watching:

Hardware-neutral tooling investment. If you rely on Optimum AMD, Optimum Intel, or other non-Nvidia deployment paths, watch their release cadence over the next 12–18 months relative to Nvidia-first tooling. A slowdown wouldn't be announced — it would just show up as slower issue resolution and fewer supported model architectures.

Alternatives exist, but none fully match Hugging Face's combined scale. Ollama offers neutral local inference, AWS Bedrock and Google's Vertex AI Model Garden provide managed hosting tied to their own hardware, and ModelScope serves a similar role in the Chinese market — but none currently matches Hugging Face's combined reach across model hosting, datasets, and the Transformers ecosystem. Diversifying your deployment tooling now costs little and reduces platform-risk exposure later.

Regulatory conditions could reshape the deal before it closes. If antitrust review results in behavioral commitments — guaranteed non-Nvidia library support levels, for instance — those terms would matter more to working developers than anything in Nvidia's current messaging.

Licensing hasn't changed and there's no indication it will. Nothing reported so far suggests Hugging Face's open-source licensing model changes as a result of this acquisition — the concern raised by analysts is about hardware neutrality and platform incentives, not the licenses attached to hosted models.

FAQ

Is the deal final? No. A definitive agreement is signed, but it's subject to regulatory approval in the US and EU, with an expected close in the first half of 2027. Signed agreements at this scale can still be modified, delayed, or in rare cases blocked during review.

Does this affect the Hugging Face Transformers library or model licenses? Not based on anything disclosed so far. The library remains open source, and existing model licenses are unaffected by a change in company ownership.

Will Hugging Face still work well with AMD and Intel hardware? Nvidia's SEC filing commits to it. The more useful question is what a slow drift away from that commitment would actually look like in practice — not an announced policy reversal, but Optimum AMD and Optimum Intel quietly falling behind on release cadence and model coverage over several quarters. That's the signal worth tracking, not the press release.

How does this compare to Nvidia's other recent AI deals? It's structurally different. The Groq and Poolside transactions avoided triggering standard merger review. This is a full acquisition of a widely used developer platform, which means mandatory antitrust review in both the US and EU — the first time Nvidia's AI dealmaking faces that level of scrutiny.

Implementing Passkey Authentication in NestJS and PostgreSQL

Sanjay Singh — Thu, 03 Sep 2026 04:24:16 +0000

Why now

In May 2026 the FIDO Alliance put a number on something that had been a trend for a few years: 5 billion passkeys are now in active use worldwide. The same report found 90 percent consumer awareness, 75 percent of people with a passkey enabled on at least one account, and 49 percent who use one regularly when it is offered.

That adoption is happening while the threat model underneath it is shifting. Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation, at 31 percent of breaches, overtook stolen credentials as the leading breach entry point for the first time in the report's 19-year history. Credential theft did not go away; it was simply overtaken.

Passwords are still doing plenty of damage in the meantime. SpyCloud's 2026 Identity Exposure Report counted 5.3 billion credential pairs circulating in criminal marketplaces over the previous year, and found that roughly four in ten corporate users had reused an exposed password. None of that risk disappears just because exploitation edged ahead in the rankings.

None of this makes passkeys a silver bullet. It makes them the highest-leverage fix available for the credential half of that risk, and one a small backend team can ship in a weekend rather than a quarter. The rest of this post builds real passkey support into a NestJS and PostgreSQL API, using the current release of SimpleWebAuthn (v13.3.3) and TypeScript 7.

What a passkey actually is

Strip away the marketing and a passkey is a discoverable, resident public-key credential defined by the WebAuthn specification. Registration generates a key pair on the authenticator; the private key never leaves it and the server only ever stores the public half. There is no shared secret to phish, leak, or reuse across sites, which is the entire security argument in one sentence.

Authenticators come in two flavors that matter for how you design an app. A device-bound passkey has a private key locked inside one piece of hardware, a security key or a TPM, and it never leaves. A syncable passkey has its private key replicated across a user's devices through a platform's encrypted sync fabric, such as iCloud Keychain or Google Password Manager, trading a little assurance for a lot fewer lockouts.

That distinction is not academic if you sell into regulated customers. NIST's SP 800-63B-4 puts phishing-resistant authentication into the baseline for Authenticator Assurance Level 2, and it explicitly recognizes synced passkeys at AAL2. Device-bound passkeys can reach the stricter AAL3, but the specification is direct about the tradeoff: syncable authenticators "SHALL NOT be used at AAL3" because AAL3 requires a key that can never be exported.

Assurance level	Syncable passkey	Device-bound passkey
AAL2 (phishing-resistant baseline)	Allowed	Allowed
AAL3 (hardware-isolated key required)	Not allowed	Allowed

Two ceremonies, one round trip each

Both registration and login are two-step ceremonies, and the two steps happen in separate HTTP requests. The server issues a random challenge and a set of options; the browser calls the WebAuthn API with those options and gets back a signed response; the server verifies that response against the challenge it issued. Nothing about the second step can be trusted unless the first step's challenge is still provably the one the server generated.

That means the challenge has to live somewhere between the two requests, and it cannot simply be a value the client hands back to you: an attacker intercepting the flow could hand back whatever challenge you gave them too. This implementation stores each challenge in Redis, keyed by user ID and ceremony type, with a two-minute TTL, which keeps the API itself fully stateless.

import { Injectable } from '@nestjs/common';
import Redis from 'ioredis';

const CHALLENGE_TTL_SECONDS = 120;

// Registration and authentication are two-step ceremonies: generate options
// (which include a fresh challenge), then verify a response against that
// same challenge. The challenge has to live somewhere between those two
// requests, and it must not be trusted if the client hands it back to you.
// A short-lived Redis key keyed by user ID does the job without adding a
// stateful session cookie for a service that is otherwise stateless.
@Injectable()
export class WebAuthnChallengeStore {
  constructor(private readonly redis: Redis) {}

  private key(userId: string, purpose: 'reg' | 'auth'): string {
    return `webauthn:challenge:${purpose}:${userId}`;
  }

  async save(
    userId: string,
    purpose: 'reg' | 'auth',
    challenge: string,
  ): Promise<void> {
    await this.redis.set(
      this.key(userId, purpose),
      challenge,
      'EX',
      CHALLENGE_TTL_SECONDS,
    );
  }

  async consume(
    userId: string,
    purpose: 'reg' | 'auth',
  ): Promise<string | null> {
    const key = this.key(userId, purpose);
    const value = await this.redis.get(key);
    if (value) {
      await this.redis.del(key);
    }
    return value;
  }
}

Nothing here is passkey-specific; it is a short-lived key-value pair with a purpose in the key so registration and login challenges cannot collide for a user doing both in the same window. If your app does not already run Redis, a signed, encrypted cookie with the same TTL works too.

The schema

The schema needs to capture more than just the public key. The counter and the device and backed-up flags are what let you detect a cloned credential later; skipping them now means you cannot add that check without a migration and a gap in your audit trail.

CREATE TABLE webauthn_credentials (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  credential_id TEXT NOT NULL UNIQUE,
  public_key BYTEA NOT NULL,
  counter BIGINT NOT NULL DEFAULT 0,
  transports TEXT[] NOT NULL DEFAULT '{}',
  device_type TEXT NOT NULL,
  backed_up BOOLEAN NOT NULL DEFAULT FALSE,
  aaguid TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  last_used_at TIMESTAMPTZ
);

CREATE INDEX idx_webauthn_credentials_user_id ON webauthn_credentials (user_id);

credential_id is unique across the whole table, not just per user, because a login lookup only has the credential ID the browser returned to work with. public_key is stored as raw bytes rather than a base64 string: encoding it yourself just adds a lossy round trip that verification code then has to undo.

import {
  Column,
  CreateDateColumn,
  Entity,
  Index,
  JoinColumn,
  ManyToOne,
  PrimaryGeneratedColumn,
} from 'typeorm';
import { User } from './user.entity';

@Entity('webauthn_credentials')
export class WebAuthnCredentialEntity {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @ManyToOne(() => User, { onDelete: 'CASCADE' })
  @JoinColumn({ name: 'user_id' })
  user: User;

  @Column({ name: 'user_id' })
  userId: string;

  // Base64url credential ID from the authenticator. Unique across all users
  // so a lookup by ID alone is enough to find the owning row during login.
  @Index({ unique: true })
  @Column({ name: 'credential_id', type: 'text' })
  credentialId: string;

  // COSE public key, stored as raw bytes. Never store this as text: base64
  // encoding it yourself just adds a lossy round trip you have to reverse.
  @Column({ name: 'public_key', type: 'bytea' })
  publicKey: Buffer;

  // Signature counter reported by the authenticator. A stalled or
  // decreasing counter across authentications is the standard signal that
  // a credential was cloned; verifyAuthenticationResponse checks this,
  // this column is what makes that check possible run over run.
  @Column({ type: 'bigint' })
  counter: string;

  @Column({ type: 'text', array: true, default: '{}' })
  transports: string[];

  @Column({ name: 'device_type', type: 'text' })
  deviceType: 'singleDevice' | 'multiDevice';

  @Column({ name: 'backed_up', type: 'boolean', default: false })
  backedUp: boolean;

  @Column({ type: 'text', nullable: true })
  aaguid: string | null;

  @CreateDateColumn({ name: 'created_at' })
  createdAt: Date;

  @Column({ name: 'last_used_at', type: 'timestamptz', nullable: true })
  lastUsedAt: Date | null;
}

This maps directly onto the schema above. Two fields are worth a second look: counter is stored as a string because a Postgres bigint round-trips through the pg driver as a string once it exceeds JavaScript's safe integer range, and transports is a plain text array rather than a join table, since it is metadata about one credential rather than data with its own lifecycle.

The service

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';
import { isoUint8Array } from '@simplewebauthn/server/helpers';
import type {
  AuthenticationResponseJSON,
  AuthenticatorTransportFuture,
  RegistrationResponseJSON,
  WebAuthnCredential,
} from '@simplewebauthn/server';
import { User } from './user.entity';
import { WebAuthnCredentialEntity } from './webauthn-credential.entity';
import { WebAuthnChallengeStore } from './webauthn-challenge.store';

const RP_NAME = 'Example App';
const RP_ID = process.env.WEBAUTHN_RP_ID ?? 'example.com';
const ORIGIN = process.env.WEBAUTHN_ORIGIN ?? 'https://example.com';

@Injectable()
export class WebAuthnService {
  constructor(
    @InjectRepository(WebAuthnCredentialEntity)
    private readonly credentials: Repository<WebAuthnCredentialEntity>,
    private readonly challenges: WebAuthnChallengeStore,
  ) {}

  // Step 1 of registration: build the options object the browser needs to
  // call navigator.credentials.create(). excludeCredentials stops a user
  // from registering the same authenticator twice.
  async getRegistrationOptions(user: User) {
    const existing = await this.credentials.find({ where: { userId: user.id } });

    const options = await generateRegistrationOptions({
      rpName: RP_NAME,
      rpID: RP_ID,
      userName: user.email,
      userDisplayName: user.displayName,
      userID: isoUint8Array.fromUTF8String(user.id),
      attestationType: 'none',
      excludeCredentials: existing.map((cred) => ({
        id: cred.credentialId,
        transports: cred.transports as AuthenticatorTransportFuture[],
      })),
      authenticatorSelection: {
        residentKey: 'preferred',
        userVerification: 'preferred',
      },
    });

    await this.challenges.save(user.id, 'reg', options.challenge);
    return options;
  }

  // Step 2 of registration: verify the signed attestation the browser
  // returned, then persist the credential. Nothing is written to the
  // database until verification succeeds.
  async verifyRegistration(user: User, response: RegistrationResponseJSON) {
    const expectedChallenge = await this.challenges.consume(user.id, 'reg');
    if (!expectedChallenge) {
      throw new UnauthorizedException('Registration challenge expired or missing');
    }

    const verification = await verifyRegistrationResponse({
      response,
      expectedChallenge,
      expectedOrigin: ORIGIN,
      expectedRPID: RP_ID,
    });

    if (!verification.verified || !verification.registrationInfo) {
      return { verified: false };
    }

    const { credential, credentialDeviceType, credentialBackedUp, aaguid } =
      verification.registrationInfo;

    await this.credentials.save(
      this.credentials.create({
        userId: user.id,
        credentialId: credential.id,
        publicKey: Buffer.from(credential.publicKey),
        counter: credential.counter.toString(),
        transports: credential.transports ?? [],
        deviceType: credentialDeviceType,
        backedUp: credentialBackedUp,
        aaguid: aaguid ?? null,
      }),
    );

    return { verified: true };
  }

  // Step 1 of login: list the credential IDs already on file for this
  // account so the browser only prompts for one of those authenticators.
  async getAuthenticationOptions(user: User) {
    const existing = await this.credentials.find({ where: { userId: user.id } });
    if (existing.length === 0) {
      throw new UnauthorizedException('No passkeys registered for this account');
    }

    const options = await generateAuthenticationOptions({
      rpID: RP_ID,
      allowCredentials: existing.map((cred) => ({
        id: cred.credentialId,
        transports: cred.transports as AuthenticatorTransportFuture[],
      })),
      userVerification: 'preferred',
    });

    await this.challenges.save(user.id, 'auth', options.challenge);
    return options;
  }

  // Step 2 of login: verify the signed assertion, then persist the new
  // counter value. Persisting newCounter is what lets the next login
  // detect a counter that went backwards, one signal a credential was
  // cloned onto a second, unauthorized authenticator.
  async verifyAuthentication(user: User, response: AuthenticationResponseJSON) {
    const expectedChallenge = await this.challenges.consume(user.id, 'auth');
    if (!expectedChallenge) {
      throw new UnauthorizedException('Authentication challenge expired or missing');
    }

    const stored = await this.credentials.findOne({
      where: { credentialId: response.id, userId: user.id },
    });
    if (!stored) {
      throw new UnauthorizedException('Unrecognized credential for this account');
    }

    const credential: WebAuthnCredential = {
      id: stored.credentialId,
      publicKey: new Uint8Array(stored.publicKey),
      counter: Number(stored.counter),
      transports: stored.transports as AuthenticatorTransportFuture[],
    };

    const verification = await verifyAuthenticationResponse({
      response,
      expectedChallenge,
      expectedOrigin: ORIGIN,
      expectedRPID: RP_ID,
      credential,
    });

    if (verification.verified) {
      stored.counter = verification.authenticationInfo.newCounter.toString();
      stored.backedUp = verification.authenticationInfo.credentialBackedUp;
      stored.lastUsedAt = new Date();
      await this.credentials.save(stored);
    }

    return { verified: verification.verified };
  }
}

generateRegistrationOptions needs the internal user ID as bytes, not a string, which is what isoUint8Array.fromUTF8String is for. excludeCredentials stops someone from registering the same authenticator twice, and residentKey: preferred asks the authenticator to create a discoverable credential, the property that lets a user sign in by picking an account rather than typing one first.

verifyAuthenticationResponse takes the stored credential, including its last known counter, and returns a newCounter you are responsible for saving. Most platform authenticators report a counter of zero forever, so the check does little there, but for the security keys and older authenticators that do increment it, a counter that goes backward is the textbook sign of a cloned credential and should trigger revoking it, not just logging it.

The controller

import { Body, Controller, Post, Req } from '@nestjs/common';
import type { Request } from 'express';
import type {
  AuthenticationResponseJSON,
  RegistrationResponseJSON,
} from '@simplewebauthn/server';
import { WebAuthnService } from './webauthn.service';

// CurrentUser stands in for whatever request-scoped auth decorator an app
// already uses (session, access token, etc). Passkeys replace the *login
// step*, not the fact that a request has an authenticated subject; the
// registration endpoints in particular must run behind existing auth so a
// stranger cannot add a passkey to someone else's account.
interface AuthedRequest extends Request {
  user: { id: string; email: string; displayName: string };
}

@Controller('webauthn')
export class WebAuthnController {
  constructor(private readonly webauthn: WebAuthnService) {}

  @Post('registration/options')
  getRegistrationOptions(@Req() req: AuthedRequest) {
    return this.webauthn.getRegistrationOptions(req.user);
  }

  @Post('registration/verify')
  verifyRegistration(
    @Req() req: AuthedRequest,
    @Body() body: RegistrationResponseJSON,
  ) {
    return this.webauthn.verifyRegistration(req.user, body);
  }

  @Post('authentication/options')
  getAuthenticationOptions(@Req() req: AuthedRequest) {
    return this.webauthn.getAuthenticationOptions(req.user);
  }

  @Post('authentication/verify')
  verifyAuthentication(
    @Req() req: AuthedRequest,
    @Body() body: AuthenticationResponseJSON,
  ) {
    return this.webauthn.verifyAuthentication(req.user, body);
  }
}

The controller is intentionally thin. Every method reads req.user, which stands in for whatever session or access-token middleware the app already has; the important detail is that the registration endpoints sit behind that same authentication, so a passkey can only ever be added to the account that is already logged in, never to an arbitrary one.

Before you ship it

Do not remove password login the day this ships. Passkeys fail closed in ways passwords do not: a lost phone with no synced backup, a corporate device wiped on offboarding, a user who never finishes the registration flow. Offer passkeys as the default and keep an existing fallback until account recovery for the passkey-only path has actually been tested end to end.

Let users register more than one authenticator, and say so in the UI. A single passkey tied to a single phone is a single point of failure; a phone and a hardware key, or a phone and a laptop's platform authenticator, means losing one device is an inconvenience instead of a lockout ticket.

Two details surfaced only by actually compiling this against current packages. TypeScript 7 removed the legacy node moduleResolution setting outright, so a tsconfig carried over from an older NestJS project needs module and moduleResolution both set to nodenext, or both to node16, not left on the old default. TypeORM entities also need strictPropertyInitialization turned off under strict mode, since the ORM populates columns after construction, not inside it.

The bottom line

None of this closes the door Verizon flagged: vulnerability exploitation is the bigger single vector now, and passkeys will not patch a server. What they do is take the credential half of the risk, the half behind SpyCloud's 5.3 billion exposed pairs, and remove it for every account that enables one. Ship it as an addition, not a replacement, and the registration friction pays for itself the first time it blocks a credential-stuffing run.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Gemini 3.8 Flash and 3.8 Flash Cyber: Google Ships Its Third Flash Release in Six Weeks

Sanjay Singh — Thu, 03 Sep 2026 04:15:09 +0000

On September 2, 2026, Google introduced two new models on the Gemini blog: Gemini 3.8 Flash, a general-purpose workhorse model, and Gemini 3.8 Flash Cyber, a cybersecurity-focused variant with restricted access. The announcement came from Tulsee Doshi, Senior Director of Product Management, and Raluca Ada Popa, Gemini Security Lead at Google DeepMind, on blog.google.

Three releases, six weeks

Google frames this as its third Flash-tier release in six weeks. The cadence started with Gemini 3.6 Flash on July 21, 2026, continued with Gemini 3.7 Flash on August 13, 2026, and now lands on 3.8 Flash and 3.8 Flash Cyber. Google describes 3.8 as building on the momentum of 3.7 Flash, released three weeks earlier, per the announcement.

Gemini 3.6 Flash launched alongside Gemini 3.5 Flash Cyber, the model that 3.8 Flash Cyber now replaces. The cyber-focused line has been iterating on the same six-week schedule as the general-purpose Flash models.

What changed in Gemini 3.8 Flash

Google positions 3.8 Flash as its most intelligent workhorse model yet, with gains in software engineering, agentic tasks, and multi-step reasoning over 3.7 Flash, according to the official announcement. On DeepSWE v1.1, a long-horizon software engineering benchmark, 3.8 Flash scores 73.7 percent, up from 65.3 percent for 3.7 Flash. That places it ahead of GPT-5.6 Sol, GPT-5.6 Terra, and Claude Sonnet 5 in Google's own comparison table, though Claude Opus 5 still leads the group at 74.0 percent.

The model also gained ground on general reasoning and agentic coding. Gemini 3.8 Flash scores 54.9 percent on HLE-Verified, a benchmark spanning STEM, humanities, and professional fields, edging out every model in the same table, including Claude Opus 5's 54.4 percent and GPT-5.6 Sol's 54.5 percent. On Terminal-bench 2.1, agentic terminal coding, 3.8 Flash posts 89.4 percent against 85.8 percent for 3.7 Flash.

Google also credits 3.8 Flash with beating every other model in its comparison table on two specialized agent benchmarks. On Vals Finance Agent V2, 3.8 Flash scores 61.4 percent against 59.0 percent for 3.7 Flash and 58.6 percent for the next-best model, Claude Opus 5. On Harvey's Legal Agent Benchmark, 3.8 Flash reaches a 10.0 percent full pass rate, roughly double GPT-5.6 Sol's 2.5 percent.

Google attributes these gains to the model working harder: taking extra reasoning steps and calling tools iteratively on complex tasks, at the cost of more tokens at higher effort settings. Developers who need lower latency can drop the effort level, or stay on 3.7 Flash, which remains fully supported.

Pricing stays where 3.7 Flash left it, for now. 3.8 Flash costs $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026, per the pricing footnote on the announcement. Starting January 1, 2027, that rate doubles to $1.50 and $7.50 per million tokens, the same rate 3.6 Flash charged back in July.

How Gemini 3.8 Flash stacks up against rivals

Google's own announcement includes a head-to-head table against Gemini 3.7 Flash, Claude Opus 5, Claude Sonnet 5, GPT-5.6 Sol, and GPT-5.6 Terra across fifteen benchmarks. These are Google's self-reported numbers, so treat them the way you would any vendor's own comparison chart, pending independent replication.

Benchmark	Gemini 3.8 Flash	Gemini 3.7 Flash	Claude Opus 5	Claude Sonnet 5	GPT-5.6 Sol	GPT-5.6 Terra
Input price, $ per 1M tokens	$0.75*	$0.75*	$5.00	$2.00	$4.00	$2.00
Output price, $ per 1M tokens	$3.75*	$3.75*	$25.00	$10.00	$20.00	$12.00
DeepSWE v1.1, long-horizon SWE	73.7%	65.3%	74.0%	53.8%	72.7%	69.6%
GDPVal-AA v2, knowledge work (Elo)	1545	1482	1824	1584	1710	1528
Vals Finance Agent v2	61.4%	59.0%	58.6%	53.9%	53.8%	54.4%
Harvey's Legal Agent Benchmark, full pass	10.0%	8.8%	6.7%	5.0%	2.5%	0.8%
Terminal-bench 2.1, agentic terminal coding	89.4%	85.8%	89.1%	80.4%	88.8%	87.4%
Terminal-bench 4.0, general agent	19.1%	11.2%	51.8%	12.4%	37.3%	23.6%
GDP.PDF, expert PDF comprehension, full pass	35.0%	34.0%	37.0%	28.0%	40.0%	29.0%
CharXiv Reasoning, no tools	86.2%	84.5%	83.7%	70.1%	85.8%	85.9%
LVBench, agentic / static, long video	87.8% / 87.1%	85.4%	75.4%	68.5%	82.1%	78.9%
HLE-Verified, multidisciplinary reasoning	54.9%	53.6%	54.4%	31.0%	54.5%	51.1%
OSWorld-2.0, agentic computer use, partial	59.0%	50.6%	75.4%	42.6%	62.6%	50.2%
BioMysteryBench, human-solvable	88.8%	87.1%	90.1%	87.5%	79.5%	83.8%
BioMysteryBench, human-difficult	56.5%	43.5%	49.4%	34.1%	44.7%	49.4%
LABBench2, biology research tasks	86.2%	82.1%	84.2%	80.1%	82.1%	81.2%

* Introductory price through Dec 31, 2026. Regular price is $1.50 input and $7.50 output per 1M tokens.

Source: Google's Gemini 3.8 Flash announcement; methodology listed at deepmind.google/models/evals-methodology/gemini-3-8-flash.

Claude Opus 5 leads on five of the fourteen benchmark rows: DeepSWE v1.1, GDPVal-AA v2, Terminal-bench 4.0, OSWorld-2.0, and the human-solvable split of BioMysteryBench. GPT-5.6 Sol leads on one, GDP.PDF. Gemini 3.8 Flash leads the remaining eight rows, and undercuts every rival on both price columns by a wide margin.

What changed in Gemini 3.8 Flash Cyber, and who can use it

Gemini 3.8 Flash Cyber is not a public model. Access runs through the newly launched Fairwind Program, which Google says prioritizes trusted government authorities, critical infrastructure operators, and software maintainers.

On CyberGym, the standard industry benchmark for vulnerability discovery, Google reports that 3.8 Flash Cyber delivers frontier-level performance, surpassing both 3.5 Flash Cyber and larger frontier models. Because CyberGym leans heavily on C and C++ codebases, Google also ran an internal benchmark spanning 20 programming languages, where 3.8 Flash Cyber crossed a 70 percent vulnerability discovery success rate.

Patching is where the numbers get most specific. On CWE-Bench, an external benchmark run by Collinear, 3.8 Flash Cyber posted a pass@1 of 47.2 percent, just behind a leading frontier model's 47.8 percent, but at meaningfully lower cost per rollout, per Google's writeup of the result. Google calls this landing on the Pareto frontier for the benchmark.

According to the primary announcement, real-world results reinforce the benchmark story. Google's own Chrome Security team found 3.8 Flash Cyber produced 2.6 times more correct vulnerability patches than larger commercial models. Wiz reported 7.5 to 9.7 percent higher recall on its internal penetration-testing benchmark, at 2.3 to 5.2 times lower cost than other leading frontier models. Google's Cloud Vulnerability Research team used the model to find a critical foundational vulnerability in under two hours, a process that normally takes months.

One core model, two access envelopes

Both variants share the same foundational intelligence, refined through what Google calls long-running agentic loops that recursively evaluate and improve the underlying model. What separates them is the safety envelope wrapped around each release channel, not the underlying architecture.

3.8 Flash ships broadly across developer, enterprise, and consumer surfaces. 3.8 Flash Cyber ships to a narrow, vetted list of defenders, reflecting the dual-use risk of a model built to find and patch vulnerabilities at scale.

Side by side

Metric	Gemini 3.7 Flash	Gemini 3.8 Flash	Gemini 3.8 Flash Cyber
Release date	Aug 13, 2026	Sep 2, 2026	Sep 2, 2026
Access	General availability	General availability	Fairwind Program only
Price, input / output per 1M tokens	$0.75 / $3.75	$0.75 / $3.75 through Dec 31, 2026	Not publicly listed
DeepSWE v1.1	65.3%	73.7%	N/A
Terminal-bench 2.1	85.8%	89.4%	N/A
HLE-Verified	53.6%	54.9%	N/A
CyberGym, vulnerability discovery	N/A	N/A	Frontier-level, beats 3.5 Flash Cyber
CWE-Bench patching, pass@1	N/A	N/A	47.2%, vs 47.8% for top frontier model

Source: blog.google.

Safety notes worth reading

3.8 Flash ships with safeguards against misuse in chemical, biological, radiological, and nuclear domains, plus cyber offense, under Google's Frontier Safety Framework, per the announcement. 3.8 Flash Cyber carries a more permissive set of mitigations, which is why it stays behind the Fairwind Program gate rather than shipping broadly.

Google also reports a significant jump in prompt injection robustness for the 3.8 generation, measured against Gray Swan's indirect prompt injection benchmark. The company frames this as protection for everyday Gemini users against prompt-injection attacks, not only a cyber-specialist concern.

Where to find it

Developers reach 3.8 Flash through Google Antigravity, Google AI Studio, and Android Studio, or generate interfaces with it in Stitch. Enterprises get access through Gemini Enterprise. Consumers on a Google AI Pro or Ultra plan can reach it inside the Gemini app, AI Mode in Search, or Gemini in Sheets.

3.8 Flash Cyber only reaches people who apply through the Fairwind Program and get accepted as a trusted defender. Google lists early Fairwind partners including Armadin, Palo Alto Networks, Snowflake, and Wiz in the announcement, though it has not published the program's exact acceptance criteria.

The pattern to watch

Three Flash-tier releases in six weeks is a fast cadence for any model family, and it says as much about Google's release strategy as about any single model. If the pattern holds, 3.8 Flash will not be the last word here for long. Developers building on Gemini should treat these version numbers as a moving target and budget review time whenever a new one drops.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

GitOps for Technical Writers: Continuous Publishing with the ZyVop CLI and GitHub Actions

Sanjay Singh — Wed, 02 Sep 2026 13:57:59 +0000

GitOps for Technical Writers: Continuous Publishing with the ZyVop CLI and GitHub Actions

For software engineers, writing code and writing technical articles should feel like the same discipline. Both require structural hierarchy, precise syntax, logical proofs, and iterative refinement. Yet the developer experience of publishing an article has historically diverged from our software development lifecycle.

Traditional Publishing:
Local Editor (Markdown) ──> Copy/Paste ──> Web CMS Dashboard ──> Manual Formatting ──> Publish ──> Repeat for 4 Platforms

GitOps Publishing:
Local Editor (Markdown) ──> git commit & push ──> GitHub Actions (CI/CD) ──> ZyVop API ──> Automated Multi-Platform Fanout

When writing in a proprietary browser-based CMS, we surrender the tools we rely on daily:

No Real Version Control: Revisions are stored in proprietary database snapshots rather than immutable Git commits with atomic diffs and clear commit messages.
No Peer Review Infrastructure: Collaboration happens via clunky comment sidebars instead of standard GitHub Pull Requests, branch previews, and automated linting.
Context Switching: We are forced out of our configured local environments (Neovim, VS Code, Helix) into browser textareas with fragile clipboard handling.
Manual Multi-Platform Duplication: Distributing an article to Dev.to, Hashnode, Medium, and Bluesky means manually copy-pasting Markdown, re-uploading cover images, re-tagging, and hoping canonical URLs were configured correctly to avoid search engine penalties.

To solve this, we applied the principles of GitOps and Continuous Delivery to technical blogging. By combining the ZyVop CLI, headless REST/GraphQL APIs, and GitHub Actions, you can manage your blog as an open-source repository and automate the entire lifecycle from local Markdown file to globally distributed, SEO-canonicalized publication.

1. System Architecture: The End-to-End Pipeline

At its core, GitOps publishing treats a directory of Markdown files as the single source of truth for your published technical content. A git push to your repository's main branch acts as the deployment trigger.

Here is the architectural lifecycle of an article moving through the pipeline:

Key Architectural Tenets:

Decoupled Synchronous Validation: The GitHub Actions runner communicates with the fast REST endpoint, which validates frontmatter, stores the post in PostgreSQL, and returns within ~250ms.
Asynchronous Multi-Platform Fan-Out: External platform APIs (which often experience variable latency or strict rate limits) are handled by dedicated background BullMQ workers. This guarantees that slow third-party networks never fail or block your CI/CD build.
Deterministic Canonical SEO: The root post URL is automatically computed and injected into the metadata headers of all syndication targets, ensuring Google and Bing attribute domain authority to your primary source.

2. The Anatomy of a Headless Markdown Post

In a GitOps workflow, your Markdown files must declare both their content and their deployment configuration. We use standard YAML frontmatter parsed at the AST level via gray-matter.

Here is an example production post configuration (posts/distributed-queues.md):

---
title: "The Anatomy of a Resilient Distributed Task Queue"
subtitle: "Deep dive into NestJS, Fastify, BullMQ, and Redis worker processes"
excerpt: "Learn how to architect high-throughput asynchronous job pipelines that survive network partitions and node crashes."
category: backend
tags:
  - typescript
  - architecture
  - redis
  - devops
canonical_url: https://myblog.com/posts/distributed-queues
cover_image: https://assets.myblog.com/covers/task-queue.webp
status: PUBLISHED
generate_toc: true
cross_post:
  devto: true
  hashnode: true
  medium: true
  bluesky: true
---

# Introduction

When designing scalable web architectures, separating synchronous request-response cycles from background task execution is essential...

Frontmatter Schema Reference

Field	Type	Description
title	string (Required)	The primary headline of the article.
subtitle	string (Optional)	Secondary description or tagline.
excerpt	string (Optional)	Short summary used for RSS feeds, newsletter preheaders, and preview cards.
tags	string[]	Up to 5 category tags (automatically mapped across syndication platforms).
canonical_url	string (Optional)	Custom origin URL if you are syndicating from a personal standalone domain.
status	PUBLISHED \| DRAFT	When set to DRAFT, the post is created without triggering public feeds or syndication.
generate_toc	boolean	Automatically calculates heading levels (<h2>, <h3>) and renders a floating Table of Contents.
cross_post	object	Boolean flags dictating which downstream syndication adapters should run.

3. Inside the ZyVop CLI: AST Parsing & Token Authentication

The ZyVop CLI was designed with two modes of execution:

Interactive Developer Mode: For local terminal testing with real-time spinners (ora), colored diff logs (picocolors), and session validation.
Headless CI/CD Mode: For non-interactive runners utilizing Personal Access Tokens (zv_...) passed via environment variables.

How the CLI Parses and Dispatches

When you execute npx zyvop publish ./posts/my-article.md, the CLI performs the following operations:

import fs from "node:fs";
import path from "node:path";
import matter from "gray-matter";
import { marked } from "marked";
import { publishArticleRestApi } from "../api.js";

export async function publishCommand(filePath, options) {
  const resolvedPath = path.resolve(process.cwd(), filePath);
  const rawFile = fs.readFileSync(resolvedPath, "utf-8");

  // 1. Extract frontmatter and raw Markdown AST
  const parsed = matter(rawFile);
  const frontmatter = parsed.data || {};
  const content = parsed.content || "";

  // 2. Resolve authentication credentials
  const token = process.env.ZYVOP_TOKEN || options.token;
  const endpoint = options.endpoint || "https://api.zyvop.com";

  // 3. Dispatch to the Headless REST Endpoint
  if (token.startsWith("zv_")) {
    const post = await publishArticleRestApi(rawFile, token, endpoint);
    console.log(`✅ Live URL: ${post.url}`);
    return;
  }
}

The AST Code Fence Protection Challenge

One significant technical hurdle when converting Markdown for multi-platform delivery is nested code fences.

If an article includes Markdown tutorials illustrating triple-backtick fences (`), naive Markdown parsers misinterpret closing boundaries. Furthermore, platforms like Dev.to's Forem engine treat nested triple-backticks as Liquid template syntax errors, throwing unhandled exceptions such as "Unknown tag 'endraw'".

The cross-posting engine dynamically calculates the fence depth:

typescript
this.turndown.addRule('fencedCodeBlock', {
filter: ['pre'],
replacement: (_content: any, node: any) => {
const code = node.querySelector ? node.querySelector('code') : null;
const text = code ? code.textContent : node.textContent;

// Dynamically increase fence length if the content contains triple backticks
let fence = '```';
while (text.includes(fence)) {
  fence += '`';
}
return `\n\n${fence}${lang}\n${text}\n${fence}\n\n`;

},
});


This ensures that your code snippets—no matter how complex or nested—remain syntactically intact across all platforms.

* * *

## 4\. Setting Up the Production GitHub Actions Workflow

To achieve true GitOps publishing, we don't want to re-publish every single post on every commit. We only want to publish **new or modified Markdown files** in the current push.

Here is the production-ready GitHub Actions workflow.

### File: `.github/workflows/publish.yml`

```

yaml
name: Continuous Publishing (GitOps)

on:
  push:
    branches:
      - main
    paths:
      - 'posts/**.md'
  workflow_dispatch: # Allows manual trigger from the GitHub Actions UI

concurrency:
  group: publishing-${{ github.ref }}
  cancel-in-progress: false

jobs:
  publish-articles:
    name: Validate & Publish to ZyVop
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout Repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 2 # Fetch the previous commit for accurate git diffing

      - name: ⚙️ Setup Node.js Runtime
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: 🔍 Detect Changed Markdown Posts
        id: changed-files
        run: |
          # If initial commit or forced push, fallback to all posts
          if [ "${{ github.event.before }}" = "0000000000000000000000000000000000000000" ]; then
            FILES=$(git ls-files 'posts/*.md')
          else
            FILES=$(git diff --name-only --diff-filter=ACMR ${{ github.event.before }} ${{ github.sha }} | grep '^posts/.*\.md$' || true)
          fi

          if [ -z "$FILES" ]; then
            echo "No Markdown files modified."
            echo "has_changes=false" >> $GITHUB_OUTPUT
          else
            echo "Files to publish:"
            echo "$FILES"
            # Format files into a space-separated list
            FILES_CLEAN=$(echo "$FILES" | tr '\n' ' ')
            echo "files=$FILES_CLEAN" >> $GITHUB_OUTPUT
            echo "has_changes=true" >> $GITHUB_OUTPUT
          fi

      - name: 🚀 Run ZyVop CLI Publisher
        if: steps.changed-files.outputs.has_changes == 'true'
        env:
          ZYVOP_TOKEN: ${{ secrets.ZYVOP_TOKEN }}
        run: |
          for file in ${{ steps.changed-files.outputs.files }}; do
            if [ -f "$file" ]; then
              echo "──────────────────────────────────────────────"
              echo "📦 Deploying: $file"
              npx zyvop publish "$file"
            fi
          done

      - name: 📊 Summary Report
        if: steps.changed-files.outputs.has_changes == 'true'
        run: |
          echo "### 🚀 GitOps Publishing Complete" >> $GITHUB_STEP_SUMMARY
          echo "The following articles were verified and deployed:" >> $GITHUB_STEP_SUMMARY
          for file in ${{ steps.changed-files.outputs.files }}; do
            echo "- \`$file\`" >> $GITHUB_STEP_SUMMARY
          done



```

* * *

## 5\. Securing the Pipeline with Personal Access Tokens

Authentication in CI/CD pipelines requires zero interactive prompts. ZyVop uses cryptographically hashed **Developer Personal Access Tokens** (`zv_live_...`).

![Mermaid Diagram](https://mermaid.ink/img/pako:eNqFklFv2jAUhf_K3X3YU0jVrQ8bQkhpRwGNrhFhSGsyIce5EK-OHdlOWij898kBsW5StSdfXx37O_fYL8h1QdjHtdRPvGTGwWyeKQDb5BvD6hJmmjMJaYaXIXyhlqSuycAd46VQlOFPLwaIo0Wa4ZgUGeYIFvqRFAgFCTkn1MYOcnMxHHjWcNeupGhp9Xn9iYdhOLjouqebSBWZ-os_nnj4hxDGwk2aHOZUayucNtszPCFuyKUZjhQ329pRcWq9oj78WN7Hq8X919G3_xHnjVJkPPXjmRpxJ7SyZ-RItWmGU_WLuMeNVCuMVhWp18zaaE7WhqTa8E0-wM1smmb4sF3q2tdv-krItEdfVyEc5VE8PV8TNa5MM1wyKQr_BgnXNVl4D3O_m4lKuD_-4yaXwnr9qYJYW_cvOo4W0OsN91FRgNPnx4ThKV-7PxVefKw6_TEXYM5n6URFe5-QF41U6xXdnKob_QhoXKmN2DGfch-uiRkysGtXYRjuu8m82q_d6ZNnDLAiUzFRYP8FXUmV_8kFrVkjHQbHzpIZwXJJ1mvWWrlbVgm5xT72WF1L6tmtdVQFcC2FerxjPOn2t1q5ADJMaKMJvk8zDGCuc-10ABOSLTnBWQCREUwGYJmyPUtGrDHoIInYeS-XV_UzHg4B5psbLbXBPr57KoUjPPwGR8Yolw?type=png)

### Steps to Configure:

1.  Log in to your **Dashboard** and navigate to **Settings > Developer API**.

2.  Click **Generate New Token**, assign a descriptive name (e.g., `github-actions-blog`), and copy the generated key.

3.  In your GitHub repository, navigate to **Settings > Secrets and variables > Actions**.

4.  Click **New repository secret**, set the name to `ZYVOP_TOKEN`, and paste the token string.


* * *

## 6\. Engineering Best Practices for Repository Structure

When managing your publication as code, organizing your directory structure helps maintain readability and simplifies pre-commit validations.

### Recommended Repository Layout:

```

yaml
my-tech-blog/
├── .github/
│   └── workflows/
│       ├── publish.yml          # Automated deployment pipeline
│       └── lint.yml             # Pre-merge validation (Markdownlint, CSpell)
├── .markdownlint.json           # Style consistency rules
├── posts/
│   ├── 2026-08-20-distributed-queues.md
│   ├── 2026-08-22-at-protocol-internals.md
│   └── drafts/
│       └── upcoming-raft-consensus.md
├── static/
│   └── diagrams/
│       └── queue-architecture.png
└── README.md



```

### Pre-Merge Quality Gates (Pull Request Workflow)

Before an article is merged into `main`, you can enforce the same quality checks you use on software projects:

-   **Markdown Linting (**`markdownlint-cli2`**):** Ensures heading hierarchies are semantically correct (e.g., single `h1`, no skipped header levels).

-   **Spell Checking (**`cspell`**):** Catches typographical errors and unknown terminology before publication.

-   **Link Validation (**`lychee`**):** Verifies that all outbound references, documentation links, and image URLs are reachable and return HTTP 200.


```

yaml
# .github/workflows/lint.yml
name: Content Verification

on:
  pull_request:
    paths:
      - 'posts/**.md'

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check Markdown formatting
        uses: DavidAnson/markdownlint-cli2-action@v16
        with:
          globs: 'posts/**/*.md'
      - name: Check spelling
        uses: streetsidesoftware/cspell-action@v6
        with:
          files: 'posts/**/*.md'



```

* * *

## 7\. Summary & Getting Started

By shifting technical blogging to a GitOps workflow:

-   **Your content stays in your hands:** You own the raw Markdown files, version history, and branch reviews in your repository.

-   **You write where you are productive:** No more pasting between browser tabs. Stay in your terminal, IDE, and Git workflow.

-   **Continuous syndication happens automatically:** One `git push` simultaneously publishes your post across Dev.to, Hashnode, Medium, and Bluesky, while maintaining your canonical SEO ranking.


To test publishing an article directly from your terminal:

```

bash
# 1. Login to your account
npx zyvop login

# 2. Test publishing any local Markdown file
npx zyvop publish ./posts/my-article.md



```



---

*Originally published on [ZyVOP](https://zyvop.com/gitops-for-technical-writers-continuous-publishing-with-the-zyvop-cli-and-github-actions-fb690)*

💡 For more articles like this, [subscribe to the ZyVOP newsletter](https://zyvop.com/newsletter)!

Claude Fable 5.1 and Mythos 5.1: One Model, Two Access Levels

Sanjay Singh — Wed, 02 Sep 2026 06:03:43 +0000

Anthropic released Claude Fable 5.1 and Claude Mythos 5.1 on September 1.

Calling them two models is slightly misleading.

Underneath, Fable 5.1 and Mythos 5.1 are the same model. The difference is what Anthropic allows that model to do, and who gets access when the work crosses into cybersecurity or advanced life sciences.

Fable is the commercial release. Mythos is the less-restricted version behind a verification gate.

That makes this launch more interesting than the usual frontier-model cycle of benchmark charts, coding demos, and claims about better reasoning. Anthropic is effectively productizing two things separately: capability and permission.

And there is a reason for that.

Earlier this year, the first Fable and Mythos release became entangled with a U.S. government intervention after researchers demonstrated that the public model could be pushed further into vulnerability research than regulators were comfortable with.

So while 5.1 is faster, cheaper in some workloads, and apparently better at coding and science, a large part of the release is really about cleaning up the boundary between useful capability and capability Anthropic does not want available by default.

Same weights, different guardrails

Fable 5.1 is available through the usual Anthropic channels: Claude.ai, the API, Claude Code, Claude Cowork, and major cloud providers.

It runs with Anthropic's standard production safeguards.

Mythos 5.1 uses the same underlying model but loosens some of those restrictions in two areas where the line between legitimate research and dangerous use is unusually thin:

cybersecurity
life sciences

A model that is unusually good at finding software vulnerabilities is useful to a security team trying to harden infrastructure.

The same capability can also help someone weaponize a vulnerability.

A model capable of reasoning deeply about protein design can accelerate legitimate drug research. The capability becomes much harder to release casually once the same system begins approaching work that previously required specialized laboratories and expert teams.

Anthropic's answer is not to cripple the underlying model. It is to gate the more permissive version.

The company had already been moving in this direction before 5.1.

Earlier in 2026, Project Glasswing gave organizations including AWS, Microsoft, Google, Apple, Cisco, CrowdStrike, and JPMorganChase access to an unreleased system called Claude Mythos Preview.

Anthropic said that model could hunt down serious software vulnerabilities — including flaws affecting major operating systems and browsers — at a level approaching elite human security researchers.

Instead of shipping that capability directly into Claude, Anthropic put it in the hands of vetted defensive partners first and backed the program with up to $100 million in usage credits.

At the time, it looked like an unusually cautious research preview.

With Mythos 5.1, it now looks more like the blueprint.

Then June happened

The first branded Fable 5 and Mythos 5 models launched on June 9.

Three days later, both disappeared.

On June 12, the U.S. Department of Commerce ordered Anthropic to prevent foreign nationals from accessing the models under national-security authorities. Because Anthropic had no practical way to verify the nationality of every user in real time, it suspended access globally.

The episode reportedly followed research from Amazon showing that Fable 5 could be jailbroken into identifying known vulnerabilities and, in one case, producing exploit code.

Anthropic's position was that the jailbreak was narrow rather than universal, and that the government's response was disproportionate.

That distinction mattered less to the regulator than it did to Anthropic.

Mythos returned first, on June 26, for approved critical-infrastructure organizations. The broader order was lifted on June 30. Fable returned to general availability on July 1. Anthropic published a detailed timeline and explanation of the redeployment.

That brief shutdown exposed a problem frontier-model developers are going to keep running into: a vendor's internal definition of acceptable risk is not necessarily the definition regulators will use.

Anthropic can classify a jailbreak as narrow, non-universal, or below some internal severity threshold. A government agency looking at the same capability can still decide it has crossed a line.

Fable 5.1 is, in part, Anthropic's attempt to make that line less ambiguous.

Cybersecurity interventions in Claude Code are now down roughly 60% per session, according to the company. Fable is allowed to identify vulnerabilities for defensive purposes, but more aggressive activity — including exploit generation and certain forms of binary vulnerability analysis — remains restricted or routed elsewhere.

Anthropic has also published more detail on its cyber safeguards and jailbreak-severity framework, which tries to distinguish minor bypasses from genuinely dangerous jailbreaks.

Biology restrictions have also been narrowed. Anthropic says ordinary medical and basic biology questions trigger safeguards around 85% less often than before, following an August update to Fable's biology safeguards.

The direction is clear: fewer annoying false positives for normal users, while the genuinely sensitive capability moves behind a more explicit gate.

That is a harder engineering problem than simply making the model refuse more often.

The coding gains look real. The benchmark story is less interesting.

Anthropic reports improvements across coding, research, and general knowledge workloads.

On GDPval-AA v2:

Model	Score
Fable 5.1	1,853
Opus 5	1,824
Fable 5	1,723

On Terminal-Bench 4.0, the difference between the public and gated variants becomes particularly useful:

Model	Score
Mythos 5.1	60.9%
Fable 5.1	55.8%

Anthropic attributes much of that gap to cases where Fable's safety layer intervenes. The company publishes the broader benchmark table and evaluation notes alongside the release.

That is arguably more informative than another leaderboard win. It gives us a rough idea of the performance tax imposed by policy rather than model intelligence.

Anthropic also reports Fable 5.1 ahead of GPT-5.6 Sol on the benchmarks where it published results for both models, although vendor-run comparisons deserve the usual caveat: benchmark selection, prompts, effort settings, tool configuration, and evaluation harnesses can all change the shape of the result.

The more useful signal comes from workloads outside the standard tables.

At Millennium, a senior portfolio manager described a system crash that appeared roughly once in a million runs and had resisted investigation for years. Fable 5.1 reportedly worked backward through a third-party binary, correlated its behavior with crash data, and isolated the bug inside the dependency.

That is the kind of task where agentic models are becoming genuinely interesting: not autocomplete, not another greenfield React app, but messy diagnosis across binaries, logs, tools, and incomplete evidence.

Cognition says it is moving Devin traffic from Opus 5 to Fable 5.1 because of the price-to-performance tradeoff. MongoDB described a prototype that ran unattended for hours and finished overnight. Canva reported improvements in writing and creative work.

These are still vendor-selected customer stories, not controlled independent evaluations. But they point toward the workload Anthropic seems to be optimizing for: long-running, tool-heavy tasks where the model has to stay coherent across a large amount of context.

That leads to one of the more practical changes in the release.

The pricing table barely changed. The agent economics did.

Base pricing remains:

Usage	Price
Input	$10 / million tokens
Output	$50 / million tokens
Cached-context reads	$0.25 / million tokens

The important number is the last one.

Cached reads previously cost $1 per million tokens. Fable 5.1 cuts that to $0.25 — a 75% reduction.

For ordinary chat, that may not matter much.

For agents, it can matter a lot.

A coding agent rarely reads a repository once. It repeatedly revisits system instructions, source files, conversation state, tool output, plans, and previous context over dozens or hundreds of turns.

Suppose an agent carries a 50,000-token codebase context and re-reads it during 100 tool-call turns.

50,000 × 100 = 5,000,000 cached tokens

At the previous cache-read rate:

5M × $1 / 1M = $5.00

At the new rate:

5M × $0.25 / 1M = $1.25

Run 50 sessions like that per day:

Cache rate	Daily cost
Previous rate	$250.00
Fable 5.1	$62.50

Over a 30-day month, the difference is roughly $5,625 on cache reads alone.

That number is more useful than Anthropic's headline claim of 25–45% lower workload costs because teams can plug their own cache-hit patterns into the same arithmetic.

An agent that constantly churns fresh context will save less.

One that repeatedly works over the same large repository may save considerably more.

For production teams, context reuse is becoming an architectural cost variable, not just an API optimization.

Science is where Anthropic is making the biggest bets

The most aggressive claims in the release have little to do with software engineering.

Anthropic says Mythos 5.1 used open-source protein-design tools to produce drug-binder candidates that bound roughly 10× more tightly than the best public entries in Adaptyv Bio's protein-design competitions for three targets.

Across 12 targets, it reports a hit rate approaching 50%, compared with a typical 10–15% range in the field.

Those numbers are large enough that independent replication matters far more than another internal benchmark.

The Venus work is unusual for a different reason.

Fable 5.1 reportedly trained a neural network over decades-old Magellan radar observations to produce an elevation map covering roughly one-third of the planet, taking effective resolution from around 10–20 km to 2–3 km.

Anthropic has released the Venus elevation-map artifact on Zenodo under a Creative Commons license ahead of upcoming NASA and ESA Venus missions.

Mythos also reportedly generated custom GPU kernels for seven open-source genomics models, producing speedups of up to 2.5× while preserving identical outputs. Anthropic estimates that could cut the cost of some large-scale genetic analyses by 30–60%.

Any one of these results would be interesting on its own.

Together, they explain why Anthropic is uncomfortable treating Mythos like another premium subscription tier.

Once the same general-purpose model is debugging binaries, searching for vulnerabilities, designing proteins, optimizing genomics workloads, and building planetary models, the question is no longer just whether the system is more capable than the previous release.

The question becomes: which capabilities should inherit normal API access?

Mythos is starting to look less like a product tier

Anthropic says Mythos 5.1 will remain available only through vetted programs.

The Cyber Verification Program covers approved security work and is expanding toward Mythos-class access.

A separate Life Sciences Verification Program, developed with the U.S. government, handles advanced biology research.

For now, access is limited to a relatively small set of U.S. organizations, although Anthropic says international expansion is planned.

This is a very different model from the normal software ladder.

Haiku, Sonnet, and Opus are primarily products differentiated by capability, latency, and cost.

Mythos is increasingly something else: a policy boundary around the frontier checkpoint.

That boundary may become more common across the industry.

The more general these systems become, the harder it is to create a clean separation between "cyber model," "biology model," "coding model," and "research model." The underlying model can increasingly do all of those things.

So access control moves upward.

Instead of asking which specialized model a user can access, providers begin asking which parts of a general model's capability envelope that user should be allowed to exercise.

That is effectively what Anthropic is testing here.

There is another small but telling change in the same direction.

Anthropic has published an explanation of how Claude's text watermark works. The change sits alongside the EU AI Act's Code of Practice on Transparency of AI-Generated Content, whose Article 50-related transparency obligations began applying on August 2, 2026.

Anthropic says the watermark does not encode information about the user or conversation and does not affect output quality. Detection tooling is initially being made available to regulators, researchers, media organizations, and companies with compliance obligations.

Individually, that may look like a compliance footnote.

Placed next to verification programs, reduced-safeguard access tiers, government coordination, jailbreak evaluations, and gated biological capability, it fits the larger pattern.

Anthropic is no longer treating model deployment as simply:

train model → test model → expose API

The stack is becoming closer to:

train
→ evaluate capability
→ classify risk
→ choose safeguards
→ verify user
→ expose capability
→ monitor use

That infrastructure may end up being as consequential as the model itself.

Fable 5.1 will get most of the usage because it is the version developers can actually deploy.

Mythos 5.1 is the more revealing release.

It shows what happens when a frontier lab decides that the strongest version of a general-purpose model is no longer something everyone should automatically receive just because the weights are ready.

The benchmark race is still happening.

But another race has started beside it: who can build a workable control plane for models whose useful and dangerous capabilities increasingly come from the same underlying intelligence?

After June, Anthropic has learned that it will not be the only party deciding where that line sits.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Apple's Mac Studio Is Becoming an AI Workstation as Enterprise AI Demand Grows

Sanjay Singh — Tue, 01 Sep 2026 04:40:47 +0000

Apple's August 25 Mac announcement was unusual.

The company introduced new Mac mini and Mac Studio systems earlier than expected, and reporting from The Information, relayed by MacRumors, suggests unexpectedly strong enterprise demand for Macs capable of running AI workloads locally helped influence the timing.

Reuters separately reported that Apple launched the new desktops amid growing demand for AI-capable hardware.

Apple has not publicly confirmed that enterprise demand dictated the timing.

What it has confirmed is more important: the Mac is being positioned far more aggressively as an on-device AI platform.

The new Mac Studio with M5 Max and M5 Ultra is explicitly aimed at demanding AI workloads, while the Mac mini is being pushed toward local models and agentic computing.

The Mac Studio is no longer simply a workstation for developers, designers, and video professionals.

It is becoming a serious desktop AI machine.

The 512GB Advantage

The M5 Ultra is where Apple's strategy becomes clearest.

At the top end, Mac Studio offers:

36-core CPU
80-core GPU
Up to 512GB of unified memory
1.2TB/s memory bandwidth

Apple also adds Neural Accelerators to every GPU core and claims up to 4.3× the peak AI compute performance of M3 Ultra.

That performance figure is Apple's own benchmark claim.

For local AI, the more consequential number may be 512GB.

Consider a 70-billion-parameter model stored at 16-bit precision:

70 billion × 2 bytes = roughly 140GB

And that only accounts for the weights.

Inference also needs memory for the KV cache, context, runtime overhead, and other working data.

This is where Apple's unified-memory architecture becomes unusually useful.

Instead of maintaining separate pools of system RAM and comparatively limited GPU VRAM, Apple silicon allows the CPU and GPU to operate from the same large memory pool.

That can make workloads practical on a single machine that might otherwise require aggressive quantization, model sharding, CPU offloading, or multiple discrete GPUs.

But there is an important distinction:

More memory does not automatically mean more tokens per second.

A smaller-memory accelerator may still be considerably faster when a model fits comfortably inside its available memory.

Apple's advantage is different.

It is increasingly about how large an AI workload can fit inside one desktop.

Apple says the new Mac Studio will support up to 512GB of unified memory, although the 512GB configuration is scheduled to arrive in late October.

Mac Mini Is Following the Same Strategy

Apple is bringing the same idea downmarket with the new Mac mini.

The M6 model supports up to 32GB of unified memory and 170GB/s of memory bandwidth, while integrating Neural Accelerators into its GPU.

For heavier AI development, the M5 Pro configuration is more interesting:

64GB unified memory307GB/s memory bandwidth

That creates a clear hierarchy:

M6 Mac mini: lightweight local AI and agentic workflows.

M5 Pro Mac mini: larger models and professional AI development.

M5 Ultra Mac Studio: high-memory inference and very large local models.

Mac mini remains Apple's entry-level desktop.

But it is increasingly also the entry point into Apple's local-AI stack.

Why Businesses Care About Local AI

The attraction of local inference is straightforward.

For some organizations, sending proprietary information to an external AI service is undesirable or impractical.

Local models can be useful when working with:

Confidential source code
Proprietary documents
Internal research
Customer information
Sensitive datasets
Regulated workloads

There are also latency and cost considerations.

Cloud inference remains easier to scale and avoids a large upfront hardware purchase. For many workloads, it will continue to be the better option.

Local hardware shifts the economics from per-call cloud spending toward upfront infrastructure and ongoing operating costs.

For teams continuously experimenting with coding agents, retrieval systems, open-weight models, or private datasets, that trade-off can become attractive.

Mac Studio vs. NVIDIA DGX Spark

A natural comparison is NVIDIA's DGX Spark.

Built around NVIDIA's GB10 Grace Blackwell platform, DGX Spark offers:

128GB coherent unified system memory
273GB/s memory bandwidth
Up to 1 PFLOP of FP4 Tensor performance
Support for local inference with models up to 200 billion parameters

The comparison is striking.

Specification	Mac Studio M5 Ultra	NVIDIA DGX Spark
Maximum memory	512GB	128GB
Memory bandwidth	1.2TB/s	273GB/s
Architecture	M5 Ultra / Apple silicon	GB10 Grace Blackwell
Published AI claim	Up to 4.3× vs. M3 Ultra*	Up to 1 PFLOP FP4**
Core AI ecosystem	MLX, Metal, Core AI	CUDA, NVIDIA AI stack
Positioning	Large local models + general workstation	Purpose-built AI development

Apple's figure compares M5 Ultra with M3 Ultra.

** NVIDIA's figure refers to theoretical FP4 Tensor performance using sparsity.

These performance claims are not directly comparable.

The maximum Mac Studio configuration has four times DGX Spark's memory capacity and roughly 4.4 times its published memory bandwidth.

That does not make it four times faster.

The platforms use fundamentally different accelerator architectures, numerical formats, frameworks, and optimization stacks.

The better question is:

Which constraint matters more — memory capacity or software compatibility?

NVIDIA Still Owns the Ecosystem Advantage

If Apple's strongest argument is memory, NVIDIA's strongest argument remains CUDA.

CUDA is deeply embedded across AI research and production. Optimized kernels, inference engines, training libraries, and deployment systems frequently assume NVIDIA hardware.

DGX Spark therefore fits into an ecosystem that stretches from a developer's desk to cloud GPUs and large data-center systems.

Apple's AI software ecosystem is much younger than CUDA's.

Its counterargument is integration.

MLX is Apple's open-source machine-learning framework designed specifically around Apple silicon and its unified-memory architecture.

Apple's newer Core AI framework provides native tools for building and running AI models on-device across Apple silicon.

Together with Metal, macOS, and Apple's broader developer tooling, they create a different kind of AI workstation:

A development machine, general-purpose computer, and large-memory local AI system in one box.

For some developers, that combination may matter more than CUDA compatibility.

Apple Is Thinking Beyond One Mac

Perhaps the most interesting change is that Apple is no longer treating Mac Studio strictly as a single-machine system.

Multiple Mac Studios can be connected through Thunderbolt 5 and RDMA for distributed AI workloads.

In Apple's testing, a four-Mac Studio cluster delivered up to 3× the AI inference performance of a single system.

Distributed inference is not equivalent to placing several GPUs inside one server.

Communication between machines introduces overhead, and real performance depends heavily on the model, framework, and implementation.

But the direction matters.

One Mac Studio is a workstation. Several interconnected Mac Studios begin to resemble a small AI cluster.

That is a very different conversation from the one Apple was having about this machine only a few years ago.

When Does a $5,499 Mac Make Sense?

Mac Studio with M5 Max starts at $2,499, while M5 Ultra starts at $5,499.

A $5,499 machine makes little sense if the goal is occasionally running a small local model.

But that is not necessarily the workload Apple is targeting.

For teams running large private models regularly, the comparison becomes broader:

Mac Studio versus the infrastructure required to achieve the same result another way.

That could involve:

Multiple GPUs
High-capacity system memory
A dedicated inference server
Networking
Storage
Recurring cloud inference costs

The economics depend entirely on the workload.

For some teams, NVIDIA hardware or cloud inference will remain the obvious choice.

For others, a compact machine capable of keeping extremely large models local could be surprisingly attractive.

Mac Studio or DGX Spark?

The decision ultimately comes down to priorities.

Choose DGX Spark when:

CUDA compatibility is critical.
Your existing AI stack already depends on NVIDIA.
You rely on CUDA-specific libraries or optimized kernels.
Workloads are likely to move to NVIDIA servers or cloud GPUs.

Choose a high-memory Mac Studio when:

Memory capacity is the primary constraint.
You want to experiment with very large open-weight models locally.
macOS is already part of your development workflow.
You want one system for both general development and AI.
Local processing and data control are important.

Neither machine is universally better.

They optimize for different constraints.

The Bigger Shift

The most important development here is not Apple's latest benchmark.

It is the change in what the Mac represents.

For years, the standard answer to a demanding AI workload was simple:

Run it in the cloud.

Now another question is becoming increasingly practical:

Can we keep it local?

The M5 Ultra Mac Studio will offer up to 512GB of unified memory and 1.2TB/s of bandwidth in a compact desktop.

DGX Spark offers a different proposition: less memory, but direct access to CUDA and NVIDIA's much larger AI ecosystem.

Apple does not need to beat NVIDIA at every benchmark.

It needs to make local AI on Apple silicon capable and convenient enough that developers and businesses begin treating Macs as part of their AI infrastructure.

The reported enterprise demand suggests that shift may already be underway.

And that is more significant than any single benchmark number.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

REST vs gRPC vs GraphQL in NestJS: What the Numbers Actually Show

Sanjay Singh — Sun, 30 Aug 2026 06:17:14 +0000

Comparisons of these three protocols tend to cite specific performance multipliers without saying much about what was actually measured. One recent writeup put gRPC's median latency at roughly a third of REST's for the same operation. I wanted to know if that held up in the stack I actually ship — NestJS, on Node — so I built the same GET /users-shaped endpoint three times: once as a REST controller, once as a GraphQL resolver, once as a gRPC service. Same 100-record dataset, same machine, same load test harness as far as the transport allows.

REST won — and not narrowly. REST served roughly 2.8-3x more requests per second than gRPC on my machine, almost the exact inverse of the ratio quoted above. That's not me disputing the other measurement; it's a different stack, different data, different network conditions, and both can be true. The reasons why are more useful than either number. This post is the benchmark, the code, and what I'd actually pick and why.

The question everyone asks in the wrong order

Most REST vs gRPC vs GraphQL comparisons start with the protocol and work backward to your problem: here are three boxes, here's what's inside each one, pick a box. That's backward. The protocol is a consequence of decisions you've usually already made — who's calling this API, how many services sit behind it, and what your actual performance budget is — not an input to them.

So instead of another feature matrix, I built the same thing three ways and measured it. Not because benchmarks settle the argument — they don't, a synthetic localhost test is not your production traffic — but because "gRPC is faster" is a claim you can actually check, and checking it surfaces the real trade-offs better than restating them.

REST, gRPC, and GraphQL in 30 seconds each

REST sends and receives JSON over plain HTTP. Every resource is a URL, every operation is a verb, and the server always returns the full shape of whatever it decides a "user" is. It's the default because there's nothing to explain — any client, in any language, on any platform, can call it with nothing but an HTTP library.

gRPC replaces JSON with Protocol Buffers, a binary format, and plain HTTP/1.1 with HTTP/2. Every message is defined in a .proto schema up front, both sides generate strongly-typed client and server code from it, and calls run over persistent, multiplexed connections instead of a new request each time. It's built for service-to-service traffic where both ends are code you control.

GraphQL keeps JSON and HTTP but replaces fixed endpoints with a single query language: the client states exactly which fields it wants, and the server resolves only those fields. It trades REST's simplicity for the ability to shape the response per request — which matters most when one screen needs data assembled from several underlying sources.

What I actually built and measured

I built one dataset — 100 users, each with a nested address (street, city, zip) — and served it identically through three servers: Express for REST, graphql-yoga for GraphQL, and @grpc/grpc-js with a hand-written .proto schema for gRPC. All three read from the same in-memory array, so none of them do any real work beyond serializing and sending it — this measures transport and serialization overhead, not database time.

For load testing, REST and GraphQL got hit with autocannon — 10 concurrent connections, 10 seconds, keep-alive. Autocannon doesn't speak gRPC, so I wrote a matching harness: 10 concurrent workers calling the gRPC client in a loop for the same 10 seconds, timing each call with process.hrtime. Payload sizes came from a separate, deterministic measurement — no load test needed, just encoding the identical 100-record dataset as JSON versus Protobuf and comparing byte counts directly.

Everything ran on one machine, Node 22, localhost — meaning zero network latency, no TLS handshake cost, and no cross-language client. That matters for reading the results honestly, and I'll come back to it.

Payload size: the protobuf number that surprised me

The pitch for Protobuf is that binary encoding beats JSON's text encoding by a wide margin. Here's what encoding the same 100 users actually produced:

Protobuf came in at 8,922 bytes against REST's 16,415 — smaller, but by 1.84x, not the 3-11x figure that gets thrown around. I re-ran the same comparison at 2,000 records to check whether the ratio widens at scale: it didn't. Protobuf stayed at 1.81x smaller. That's because this dataset is mostly strings — names, emails, addresses — and Protobuf's real advantage is in numeric fields, where varint encoding beats JSON's decimal text representation by a much wider margin, and in not repeating field names on every record. A schema that's mostly IDs, timestamps, and enums will show a bigger gap than one that's mostly text. Know your data before you trust a generic ratio.

The bigger number on that chart is the one nobody markets: GraphQL asking for only id and name came back at 2,704 bytes — 83.5% smaller than asking for everything. That's not a protocol-level trick, it's just not fetching data you don't need, but it's the one place in this whole comparison where the savings are dramatic instead of incremental.

Throughput and latency: REST wins on my machine

Here's what 10 concurrent connections hammering each server for 10 seconds actually produced:

Protocol	100 records: req/s	100 records: avg / p95 latency	2,000 records: req/s	2,000 records: avg / p95 latency
REST	4,785	1.6 ms / 6 ms	515	18.9 ms / 33 ms
gRPC	1,712	5.8 ms / 15 ms	168	59.5 ms / 82 ms
GraphQL	1,624	5.7 ms / 14 ms	133	74.4 ms / 95 ms

REST beat gRPC by roughly 2.8x at 100 records and 3.1x at 2,000. Three honest reasons, not one:

@grpc/grpc-js is pure JavaScript. The performance case for gRPC is usually built on Go, C++, or Java implementations that call into a native core library. Node's official gRPC client is a pure-JS reimplementation — it doesn't get that native speed, and the well-known cross-language benchmarks don't transfer to it automatically.

Express serving static JSON is about as close to the metal as Node gets. There's no query parsing, no schema validation, no protobuf encode step — just JSON.stringify and a socket write. It's a low bar for the other two to clear, and in this test, neither did.

Zero network latency erases gRPC's actual advantage. gRPC's HTTP/2 multiplexing and binary framing pay off when you're crossing a real network with real round-trip time and many concurrent streams — that's the internal-microservices case it's built for. On localhost, there's no latency to hide behind, so the picture flips.

The 2,000-record run adds one more data point worth noting: gRPC's lead over GraphQL widened from a 5% edge to a 26% edge as payload size grew. GraphQL's per-field resolver execution scales with the number of fields resolved; gRPC's schema-fixed encode/decode scales more predictably. Neither caught REST.

Take this for what a single-machine benchmark is: a controlled comparison of Node-specific implementations, not a verdict on the protocols themselves. If you're calling gRPC services written in Go from a Node gateway over a real network, expect a very different result.

Wiring up each transport in NestJS

The benchmark used plain Express, graphql-yoga, and grpc-js directly — that's what let me measure transport overhead in isolation, since NestJS's own layer adds a small, roughly constant cost on top of all three. Here's the shape of the same endpoint idiomatically wired into NestJS.

REST is a controller, nothing more:

// users.controller.ts
@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get()
  findAll(): User[] {
    return this.usersService.findAll();
  }
}

GraphQL, code-first with @nestjs/graphql, needs a resolver plus a typed object:

// users.resolver.ts
@Resolver(() => User)
export class UsersResolver {
  constructor(private readonly usersService: UsersService) {}

  @Query(() => [User])
  users(): User[] {
    return this.usersService.findAll();
  }
}

// user.model.ts
@ObjectType()
export class User {
  @Field(() => Int) id: number;
  @Field() name: string;
  @Field() email: string;
}

gRPC is the one that needs real setup — a .proto file, a microservice bootstrap, and @GrpcMethod instead of a controller decorator, per NestJS's own docs:

// main.ts
const app = await NestFactory.createMicroservice<MicroserviceOptions>(AppModule, {
  transport: Transport.GRPC,
  options: {
    package: 'users',
    protoPath: join(__dirname, 'users.proto'),
  },
});
await app.listen();

// users.controller.ts
@Controller()
export class UsersGrpcController {
  constructor(private readonly usersService: UsersService) {}

  @GrpcMethod('UserService', 'ListUsers')
  listUsers(): { users: User[] } {
    return { users: this.usersService.findAll() };
  }
}

That extra setup is the real cost of gRPC in NestJS — not runtime speed, but a schema file, a codegen or dynamic-load step, and a client that has to inject a ClientGrpc and call getService() instead of just hitting a URL:

// api-gateway/users.controller.ts (calling the gRPC service from a REST gateway)
@Controller('users')
export class GatewayUsersController implements OnModuleInit {
  constructor(@Inject('USER_PACKAGE') private readonly client: ClientGrpc) {}

  private userService: UserServiceClient;

  onModuleInit() {
    this.userService = this.client.getService<UserServiceClient>('UserService');
  }

  @Get()
  findAll() {
    return this.userService.listUsers({});
  }
}

REST needed one decorator. GraphQL needed a resolver and a typed model. gRPC needed a schema file, a second bootstrap function, and a client wrapper. That ordering held up in the benchmark too.

Where each one actually wins

	REST	gRPC	GraphQL
Best for	Public APIs, simple CRUD, anything a stranger's HTTP client needs to call	Internal service-to-service calls where both ends are your code	Frontends assembling data from several sources with different shapes
What it costs you	Over-fetching, one endpoint per shape	A schema file, codegen, and — in Node specifically — a slower client than the marketing suggests	Resolver complexity, N+1 query risk, a slower ceiling under load
What my numbers back up	Fastest raw throughput, by a wide margin, in this stack	Modest payload savings on this data shape; the throughput case needs a real network to prove out	The only place a "protocol" choice cut payload size dramatically — by not asking for fields you don't need

None of these are new conclusions. What's different is having a number attached to each one instead of a plausible-sounding claim.

The pattern that shows up in real systems

Few real systems pick just one. The common shape is REST or GraphQL at the edge, talking to gRPC internally: an external-facing layer that public and mobile clients can call with an ordinary HTTP client, backed by internal services that talk to each other over gRPC's faster, strongly-typed connections where the caller is also your code.

NestJS makes this specific composition cheap because its microservices layer is transport-agnostic: the same message-handler pattern that talks gRPC can talk TCP, Redis, NATS, Kafka, or RabbitMQ without changing the handler logic, so a gateway can front several backend transports without a rewrite for each one. The ClientGrpc snippet above is exactly that seam — a REST controller at the edge, calling into a gRPC service behind it. GraphQL slots into the same position when the edge needs to assemble one response from several backend calls instead of proxying a single one straight through.

A decision framework for your next service

Skip the protocol question and answer these first:

Who's calling this? A browser, mobile app, or third party you don't control → REST or GraphQL. Only your own services → gRPC is on the table.
Is the client shape fixed or variable? One consistent shape per resource → REST is simplest. Several different screens need different slices of the same data → GraphQL earns its complexity.
What's actually slow? If it's your database or a downstream call, changing transport protocol won't fix it — my own numbers show transport differences in the single-digit milliseconds at this scale, dwarfed by anything hitting disk or another network hop.
Are you willing to own a schema file and codegen step? gRPC's contract is also its tax. If your team won't maintain .proto files, you'll fight the tooling more than you benefit from the wire format.

Takeaways

The usual expectation — that gRPC comfortably outruns REST — didn't hold on Node: REST beat gRPC by roughly 2.8-3x in my own benchmark, largely because @grpc/grpc-js is a pure-JS client and localhost erases the network-latency advantage gRPC is actually built for.
Protobuf's payload savings were real but modest — 1.84x smaller than JSON — for data that's mostly strings. Numeric-heavy schemas will see a bigger gap.
The most dramatic savings in this whole comparison came from GraphQL simply not fetching fields nobody asked for: 83.5% smaller than the equivalent full REST response.
In NestJS specifically, gRPC's real cost is setup — a proto schema, a second bootstrap path, and a client wrapper — not runtime speed on a single machine.
None of this replaces testing your own service, your own data shape, and your own network. Benchmark it before you build your architecture around someone else's numbers, including mine.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Implementing Full-Text Search in NestJS with TypeORM and PostgreSQL

Sanjay Singh — Sat, 29 Aug 2026 16:02:33 +0000

Search is one of those features that looks simple until you actually have to build it. A naive LIKE '%term%' query works for a demo, but it ignores word forms, ranking, and typos, and it gets slow fast as your table grows. The good news: if you're already running PostgreSQL, you don't need Elasticsearch or Algolia to get real search. Postgres has a mature full-text search engine built in, and pairing it with TypeORM in a NestJS app is far more straightforward than most tutorials make it look.

This post walks through building a production-ready search feature — from schema design to a ranked, paginated API endpoint — using NestJS, TypeORM, and PostgreSQL's native full-text search.

Why Reach for PostgreSQL Instead of a Dedicated Search Engine

Elasticsearch and similar tools are excellent, but they come with real costs: another service to deploy, monitor, and keep in sync with your primary database. For most applications — blogs, admin panels, marketplaces, internal tools — that overhead isn't justified.

PostgreSQL's full-text search gives you:

Stemming and language awareness — matching "running" to "run"
Relevance ranking out of the box
Typo tolerance when combined with the pg_trgm extension
Zero replication lag — search results are always as fresh as your data, because they live in the same transaction

You lose some of the advanced faceting and horizontal scalability of a dedicated search cluster, but for the majority of apps, Postgres FTS comfortably handles millions of rows.

A Quick Primer on Postgres Full-Text Search

Two types anchor everything: tsvector and tsquery.

tsvector is a preprocessed, normalized representation of your text — lowercased, stemmed, and stripped of stop words like "the" and "and".
tsquery is a parsed search query in the same normalized form.

You match them with the @@ operator:

SELECT * FROM articles
WHERE to_tsvector('english', content) @@ to_tsquery('english', 'nestjs & search');

Computing to_tsvector() on every row for every query is expensive at scale, so the standard pattern is to store a precomputed tsvector column and index it with a GIN index, which is what makes searches over large tables fast.

Setting Up the Entity

Assume you already have a NestJS project with @nestjs/typeorm and pg configured. Here's an Article entity we'll add search to:

// article.entity.ts
import { Entity, PrimaryGeneratedColumn, Column, CreateDateColumn } from 'typeorm';

@Entity('articles')
export class Article {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  title: string;

  @Column('text')
  content: string;

  @Column({ nullable: true })
  author: string;

  @CreateDateColumn()
  createdAt: Date;

  @Column({
    type: 'tsvector',
    select: false,
    insert: false,
    update: false,
  })
  searchVector: string;
}

select: false keeps the raw vector out of normal queries, and insert: false, update: false tell TypeORM never to try writing to it — Postgres will generate that value itself.

Generating the Search Vector

The cleanest approach, available since Postgres 12, is a generated column — Postgres recomputes it automatically whenever the source columns change, no application code or triggers required:

// migrations/1700000000000-AddSearchVectorToArticles.ts
import { MigrationInterface, QueryRunner } from 'typeorm';

export class AddSearchVectorToArticles1700000000000 implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`
      ALTER TABLE "articles"
      ADD COLUMN "searchVector" tsvector
      GENERATED ALWAYS AS (
        setweight(to_tsvector('english', coalesce("title", '')), 'A') ||
        setweight(to_tsvector('english', coalesce("content", '')), 'B') ||
        setweight(to_tsvector('english', coalesce("author", '')), 'C')
      ) STORED;
    `);

    await queryRunner.query(`
      CREATE INDEX "IDX_articles_search_vector"
      ON "articles" USING GIN ("searchVector");
    `);
  }

  public async down(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(`DROP INDEX IF EXISTS "IDX_articles_search_vector";`);
    await queryRunner.query(`ALTER TABLE "articles" DROP COLUMN "searchVector";`);
  }
}

Production note: If articles is already populated and serving real traffic, consider creating the GIN index with CREATE INDEX CONCURRENTLY so the index build does not block writes. PostgreSQL does not allow CREATE INDEX CONCURRENTLY inside a transaction, so the TypeORM migration must opt out of the default transaction with transaction = false. For example:

export class AddSearchVectorToArticles1700000000000 implements MigrationInterface {
  transaction = false;

  // ...
}This matters primarily for production migrations on existing, actively used tables; a new or empty table does not have the same locking concern.

setweight() assigns each field a priority — A (highest) through D (lowest) — so title matches will outrank body-text matches later when we rank results.

If you're on Postgres < 12, or the vector needs to pull in data from a related table, use a trigger function that recalculates searchVector BEFORE INSERT OR UPDATE instead — same end result, just maintained procedurally rather than declaratively.

Run the migration with npm run typeorm migration:run, and every existing and future row gets an indexed search vector automatically.

Building the Search Service

TypeORM's query builder doesn't have first-class full-text search helpers, but it happily accepts raw SQL fragments, which is all we need:

// articles.service.ts
import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Article } from './article.entity';

@Injectable()
export class ArticlesService {
  constructor(
    @InjectRepository(Article)
    private readonly articlesRepository: Repository<Article>,
  ) {}

  async search(term: string, page = 1, limit = 10) {
    const skip = (page - 1) * limit;

    const [items, total] = await this.articlesRepository
      .createQueryBuilder('article')
      .where(`article."searchVector" @@ websearch_to_tsquery('english', :term)`, { term })
      .orderBy(
        `ts_rank(article."searchVector", websearch_to_tsquery('english', :term))`,
        'DESC',
      )
      .skip(skip)
      .take(limit)
      .getManyAndCount();

    return { items, total, page, limit };
  }
}

Note websearch_to_tsquery rather than to_tsquery. It's the function built for user-facing search boxes: it accepts plain phrases, "quoted phrases", -exclusions, and OR, without throwing a syntax error on unbalanced input the way to_tsquery does. Use to_tsquery only when you're constructing the query programmatically and can guarantee valid syntax; use plainto_tsquery for the simplest case of AND-ing all terms together with no operators.

Exposing the Endpoint

// articles.controller.ts
import { Controller, Get, Query } from '@nestjs/common';
import { ArticlesService } from './articles.service';

@Controller('articles')
export class ArticlesController {
  constructor(private readonly articlesService: ArticlesService) {}

  @Get('search')
  search(@Query('q') q: string, @Query('page') page = 1, @Query('limit') limit = 10) {
    return this.articlesService.search(q, Number(page), Number(limit));
  }
}

A request like GET /articles/search?q=nestjs+migrations now returns matching articles ranked by relevance, with title matches surfacing above body-only matches thanks to the weighting from the migration.

Ranking and Highlighting

ts_rank scores by how often terms appear; ts_rank_cd (cover density) also factors in how close together the matching terms are — often a better signal for longer documents. Swap it in the same way.

To show users why a result matched, use ts_headline to generate a snippet with matches wrapped in a marker:

async searchWithSnippets(term: string) {
  return this.articlesRepository
    .createQueryBuilder('article')
    .select(['article.id', 'article.title'])
    .addSelect(
      `ts_headline('english', article.content, websearch_to_tsquery('english', :term),
        'StartSel=<mark>, StopSel=</mark>, MaxWords=30, MinWords=15')`,
      'snippet',
    )
    .where(`article."searchVector" @@ websearch_to_tsquery('english', :term)`, { term })
    .getRawMany();
}

getRawMany() is important here — ts_headline output isn't a real entity column, so getMany() would silently drop it.

Performance note: ts_headline does not use the GIN index to generate the snippet; it re-processes the source text for each returned row. Always pair it with the same pagination you use for the main search query (take/skip, or SQL LIMIT/OFFSET) rather than running an unbounded snippet query against a large result set.

Tolerating Typos with pg_trgm

Full-text search matches word stems, not misspellings — "search" won't match "serach". For that, pair it with the pg_trgm extension, which measures string similarity by shared three-character sequences:

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX "IDX_articles_title_trgm" ON "articles" USING GIN ("title" gin_trgm_ops);

async fuzzySearch(term: string) {
  return this.articlesRepository
    .createQueryBuilder('article')
    .where('similarity(article.title, :term) > 0.2', { term })
    .orderBy('similarity(article.title, :term)', 'DESC')
    .getMany();
}

A common pattern: run the full-text query first, and only fall back to trigram similarity if it returns zero results. That way well-formed queries get accurate, ranked results, and typos get a forgiving fallback, without paying the cost of a trigram scan on every request.

Performance Notes

A few things matter more than anything else once you're past prototype scale:

Always query through the GIN index. Make sure your WHERE clause matches @@ against the indexed tsvector column, not to_tsvector(content) @@ ... computed inline, which can't use the index.
Run EXPLAIN ANALYZE on your search queries early. A missing index shows up immediately as a sequential scan.
Cache popular queries at the application layer (Redis works well) if your search endpoint gets heavy repeated traffic — Postgres FTS is fast, but no database beats not querying at all.
Paginate with LIMIT/OFFSET, as shown above, or switch to keyset pagination if you're dealing with very deep result sets.

Wrapping Up

PostgreSQL's full-text search, generated columns, and a GIN index get you relevance-ranked, typo-tolerant search without introducing a new piece of infrastructure. Combined with NestJS's dependency injection and TypeORM's query builder, the whole feature — schema, service, and endpoint — fits comfortably in a single module. Reach for Elasticsearch when you genuinely need distributed scale or advanced faceted search; for everything else, the database you're already running is usually enough.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

DEV Community: Sanjay Singh

Cross-Posting for Developers: How to Reach More Readers Without Losing Your SEO

You wrote a good technical post. Now what?

The part that’s easy to get wrong: Canonical URLs

Own the source, syndicate the reach

The hidden headaches of manual syndication

Where automation makes sense: How ZyVOP solves this

Your writing should be portable too (Automatic GitHub Sync)

Beyond Google: Preparing for AI Answer Engines (AEO & GEO)

Unified telemetry: Tracking impact without twenty tabs

Terminal-first publishing: Write in your editor, publish via CLI

The takeaway

Postgres vs MySQL vs MongoDB: The 2026 Decision Guide

The short answer

What each one actually is

PostgreSQL

MySQL

MongoDB

Where each one stands right now

How they actually store and query the same data

I actually ran this, so you don't have to trust a slide deck

What the broader benchmark literature shows

Scaling: replicas, sharding, and what's actually built in

The AI angle: vector search in 2026

Licensing: the part nobody reads until it matters

Who actually runs what

The Uber story, and why it's more nuanced than the headline

Use case matrix: what to actually pick

A decision flow

FAQ

The honest verdict

The Sandbox Held. The Headline Didn't.

What CVE-2026-85046 actually is

Chromium's actual defense-in-depth

Where the bug lived, and how it worked

Why V8 keeps producing this exact bug class

The blind spot: headless Chrome, Electron, and CI images

What to actually do about it

Is "the sandbox held" the real headline?

Further reading

OpenBot: A Technical Architecture Review of CopilotKit's Governed Agent Runtime

What shipped

Where it sits

The shape of a deployment

The gateway is the whole point

One computer per Bot

When a Bot has to stop

Tools are governed twice

Answers can be a component, not just prose

What four days of patches reveal

What "open source" does not quite mean here

Running it

Verdict

Nvidia Just Bought Hugging Face for $12.9 Billion — Here's What It Means for Developers

What Was Actually Agreed

Why Hugging Face Said Yes

Why Nvidia Wants This

What Nvidia Has Promised — And the Catch

This Deal Will Actually Face Antitrust Review

What This Means If You Build on Hugging Face Today

FAQ

Further Reading

Implementing Passkey Authentication in NestJS and PostgreSQL

Why now

What a passkey actually is

Two ceremonies, one round trip each

The schema

The service

The controller

Before you ship it

The bottom line

Gemini 3.8 Flash and 3.8 Flash Cyber: Google Ships Its Third Flash Release in Six Weeks

Three releases, six weeks

What changed in Gemini 3.8 Flash

How Gemini 3.8 Flash stacks up against rivals

What changed in Gemini 3.8 Flash Cyber, and who can use it

One core model, two access envelopes

Side by side

Safety notes worth reading

Where to find it