feat(docs): add planned integrations for ENSDb snapshots, CLI, and webhooks

docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts

@@ -132,7 +132,7 @@ export const integrateSidebarTopic = {
           link: "/docs/integrate/integration-options/omnigraph-graphql-api",
         },
         {
-          label: "ENSDb (PostgreSQL)",
+          label: "ENSDb Integration Quickstart",
           link: "/docs/integrate/integration-options/ensdb",
         },
         {
@@ -143,6 +143,14 @@ export const integrateSidebarTopic = {
           label: "ensskills (AI agents)",
           link: "/docs/integrate/integration-options/ensskills",
         },
+        {
+          label: "ensdb-cli (Snapshots)",
+          link: "/docs/integrate/integration-options/ensdb-cli",
+        },
+        {
+          label: "ENSEngine (webhooks)",
+          link: "/docs/integrate/integration-options/ensengine",
+        },
       ],
     },
     {

docs/ensnode.io/config/integrations/starlight/sidebar-topics/services.ts

@@ -186,5 +186,10 @@ export const servicesSidebarTopic = {
         },
       ],
     },
+    {
+      label: "ENSEngine",
+      collapsed: true,
+      items: [{ label: "Overview", link: "/docs/services/ensengine" }],
+    },
   ],
 };

docs/ensnode.io/src/components/molecules/EnsDbSnapshotsTeaser.astro

@@ -0,0 +1,24 @@
+---
+import { Card, CardGrid } from "@astrojs/starlight/components";
+---
+
+<CardGrid>
+  <Card title="Cut your RPC bill" icon="approve-check-circle">
+    Skip the historical RPC fanout entirely. Pull down a published ENSDb snapshot instead of replaying 9+ years of ENS history through your own RPC provider - saving real money on every bootstrap, every CI run, every fresh environment.
+  </Card>
+  <Card title="Spin up in minutes, not days" icon="rocket">
+    Skip the long historical backfill too. A nearly up-to-date ENS index is ready as fast as you can download it - no specially configured Postgres required, no days of waiting. Perfect for hackathons, demos, prototypes, and any other time you need a fresh ENSDb fast.
+  </Card>
+  <Card title="Repeatable CI environments" icon="seti:shell">
+    Use snapshots as deterministic fixtures for tests and CI pipelines. Every run starts from the same well-known ENS state, with zero RPC dependency.
+  </Card>
+  <Card title="Confident release reviews" icon="approve-check">
+    Diff snapshots across ENSNode versions to catch unexpected changes in indexed data - a powerful way to validate indexing-logic refactors before a release ships.
+  </Card>
+  <Card title="Easier self-hosting" icon="seti:db">
+    Bootstrap your own ENSNode instance from a recent snapshot, then catch up to realtime from there. Less time waiting, more time building.
+  </Card>
+  <Card title="ensdb-cli: purpose-built ops tooling" icon="seti:config">
+    `ensdb-cli` surfaces the operations you actually need day-to-day: inspect indexer instances, manage snapshots, clean up unused schemas, and more.
+  </Card>
+</CardGrid>

docs/ensnode.io/src/content/docs/docs/integrate/index.mdx

@@ -199,3 +199,7 @@ The ENS Omnigraph API is a GraphQL API following the Relay specification, so you
   description='Includes more advanced integration options not introduced in this quickstart guide'
   href="/docs/integrate/integration-options"
 />
+
+:::tip[Coming soon: accelerated self-hosting]
+Planning to self-host? We're building [**`ensdb-cli` & ENSDb snapshots**](/docs/integrate/integration-options/ensdb-cli) so you can stand up a fresh, nearly-current ENSDb in minutes instead of waiting days and spending big on RPC credits to complete a full historical backfill.
+:::

docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb-cli.mdx

@@ -0,0 +1,72 @@
+---
+title: ensdb-cli & ENSDb snapshots
+description: Coming soon - publish, download, and diff snapshots of the live ENS state with the planned ensdb-cli.
+---
+
+import { LinkCard, Aside } from "@astrojs/starlight/components";
+import EnsDbSnapshotsTeaser from "../../../../../components/molecules/EnsDbSnapshotsTeaser.astro";
+
+<Aside type="caution" title="Coming soon">
+**`ensdb-cli`** and **ENSDb snapshots** are planned capabilities that are coming soon.
+</Aside>
+
+## The problem
+
+Completing a full historical indexing backfill of ENS from zero is **expensive on two axes: time and money**. A full historical indexing backfill of ENS across mainnet, Basenames, Lineanames, 3DNS, ENSv1, ENSv2, etc generally means days of indexing *and* a heavy RPC bill - every request to your RPC provider, multiplied by every chain, multiplied by every block of 9+ years of ENS history you have to index. That tax is painful for anyone building, prototyping, demoing, or testing.
+
+[ENSDb](/docs/services/ensdb) already gives you the live, onchain state of ENS in a plain PostgreSQL database that any language with a Postgres driver can read. The next step is making it **trivial - and cheap - to bootstrap and operate** that database. That's what ENSDb snapshots and `ensdb-cli` are for.
+
+## What we're building
+
+ENSDb snapshots are **portable, versioned packages of an ENSDb instance** that anyone can publish or consume. Pull one down, restore it into Postgres, and start querying ENS in minutes instead of waiting days to complete 9-years+ of historical indexing backfill from scratch - and **without** being required to send hundreds of thousands of pricy RPC-calls yourself. When you start from a fresh ENSDb snapshot, it's cheap and fast to catch up to realtime indexing.
+
+`ensdb-cli` will be the operator-facing tool around them - the surface where you list indexer instances and their indexing status, generate fresh snapshots, inspect what configuration a snapshot was built with, and clean up schemas you no longer need.
+
+<EnsDbSnapshotsTeaser />
+
+## Who this is for
+
+- **Hackathon teams and prototypers** who want a full ENSDb right now and don't have time or money to wait days on 9+ years of an ENS historical indexing backfill.
+- **Self-hosters** standing up new ENSNode instances who'd rather start from a recent snapshot than backfill from genesis.
+- **CI and testing pipelines** that need deterministic ENS state to run repeatable assertions against.
+- **Maintainers** running release reviews who want to diff indexed data across versions to catch unintended regressions before they ship.
+- **Anyone building specialized ENS services on top of ENSDb** who needs faster iteration loops and lower operational cost.
+
+## How this complements ENSDb
+
+Snapshots and the CLI sit *on top of* the [ENSDb open standard](/docs/services/ensdb). Because ENSDb is just Postgres governed by a well-defined schema, snapshots are portable: any [ENSDb Writer](/docs/services/ensdb/concepts/glossary#ensdb-writer) implementation can produce one, and any [ENSDb Reader](/docs/services/ensdb/concepts/glossary#ensdb-reader) (or your own code) can consume one.
+
+This is the same foundation that powers ENSNode's other planned ENSDb capabilities - including [ENSEngine](/docs/integrate/integration-options/ensengine), enabling you to react to changes in ENSDb through webhooks and other event-driven strategies without need for polling.
+
+
+## Related
+
+<LinkCard
+  title="ENSDb Integration Quickstart"
+  description="The integration point these snapshots build on - the live ENS state, ready for SQL or the ENSDb SDK."
+  href="/docs/integrate/integration-options/ensdb"
+/>
+
+<LinkCard
+  title="ENSDb overview"
+  description="Vision, philosophy, and how an ENSDb instance works."
+  href="/docs/services/ensdb"
+/>
+
+<LinkCard
+  title="ENSEngine Integration Quickstart"
+  description="React to ENS state changes with webhooks & events rather than polling."
+  href="/docs/integrate/integration-options/ensengine"
+/>
+
+<LinkCard
+  title="ENSEngine overview"
+  description="React to changes in ENSDb through webhooks and other reactive / event-based development strategies."
+  href="/docs/services/ensengine"
+/>
+
+<LinkCard
+  title="Self-host ENSNode"
+  description="Operate your own ENSNode instance to build and publish your own ENSDb snapshots."
+  href="/docs/self-host"
+/>

docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx

@@ -1,5 +1,5 @@
 ---
-title: ENSDb (PostgreSQL)
+title: ENSDb integration
 description: Direct database access for self-hosters needing custom queries, analytics, or building custom services beyond what existing APIs expose.
 ---
 
@@ -11,6 +11,10 @@ For special use cases that go beyond what the ENS Omnigraph exposes — you can
 
 **ENSDb** is a bi-directional integration standard for any EnsDbWriter and EnsDbReader implementations to coordinate around the live unified onchain state of ENSv1 **and ENSv2** in a carefully-crafted standardized data model within a PostgreSQL database. Because ENSDb builds on Postgres, you can use *any* language with a Postgres driver — **TypeScript**, **Python**, **Rust**, **Go**, and more.
 
+:::tip[Coming soon: ensdb-cli & ENSDb snapshots]
+We're building [**`ensdb-cli` & ENSDb snapshots**](/docs/integrate/integration-options/ensdb-cli) so you can pull down a fresh ENSDb in minutes instead of paying for a full historical RPC backfill among many other benefits.
+:::
+
 
 <EnsDbSelfHostingNote />
 

docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensengine.mdx

@@ -0,0 +1,84 @@
+---
+title: ENSEngine
+description: Coming soon - ENS-native webhooks and push-based events that fire when ENS state changes, so apps can stop polling and start reacting.
+---
+
+import { LinkCard, Aside } from "@astrojs/starlight/components";
+
+<Aside type="caution" title="Coming soon">
+ENS-native event-driven reactive development (such as webhooks) is coming soon with [ENSEngine](/docs/services/ensengine) that builds on top of [ENSDb](/docs/services/ensdb).
+</Aside>
+
+## The problem
+
+Today, if you want your app to react to ENS state changes, you have two unappealing options:
+
+- **Poll constantly.** Hammer API endpoints or RPCs every few seconds and discard most responses. Wasteful, inefficient, and scales poorly.
+- **Build your own complex indexer and data pipeline.** Stand up infrastructure to listen to chain events, decode them, and turn them into the ENS-level signals you actually care about. Way too much work for what should be a primitive.
+
+## What we're building
+
+ENSEngine will be an **ENS-native event-driven reactive development service** (for webhooks and more) so your app can subscribe to ENS state changes in ENSDb the same way you'd subscribe to a Stripe or GitHub webhook - except the events speak the language of discrete meaningful ENS actions, not the language of bare-metal raw onchain event transaction logs.
+
+```http
+POST https://your-app.example.com/webhooks/ens
+Content-Type: application/json
+
+{
+  "type": "domain.transferred",
+  "name": "vitalik.eth",
+  ...
+}
+```
+
+The shape above is illustrative only. Full details coming soon.
+
+## Example events
+
+Events will represent meaningful ENS events, such as:
+
+- `domain.registered`, `domain.renewed`, `domain.transferred`
+- `resolver.address_changed`, `resolver.text_changed`, `resolver.contenthash_changed`
+- `subname.created`
+- ... and many more.
+
+## What this unlocks
+
+### Cache invalidation
+
+Build aggressive, edge-friendly caches for ENS data. The goal is to make it practical to cache profiles, avatars, text records, and resolver responses for much longer than polling-based integrations allow, then invalidate them when relevant onchain state changes. That's the foundation for web2-grade UX on a web3 protocol - fast page loads, low RPC fanout, globally distributed reads - without giving up freshness.
+
+Of course, ENSNode will also include metadata letting you know key attributes about ENS data you fetch so that you can wisely implement the best possible caching strategies. For example: If a particular data record is coming from purely onchain data (that will receive a guaranteed ENSEngine event notification as soon as it changes) or if a particular data record is coming from offchain data (such as a resolver record sourced through CCIP-read) and that therefore still requires polling to identify if it has changed.
+
+Where this matters:
+
+- Frontend apps caching ENS profiles
+- CDNs serving ENS-driven content
+- API gateways with ENS lookups
+- Any service that caches resolver records or other ENS data.
+
+### Additional key use cases
+
+Once a reliable change feed exists, a lot of follow-on use cases get dramatically easier to build:
+
+- **Notification services** - expiry reminders, watchlists, security alerts on unexpected transfers, activity bots in Discord/Telegram/Twitter.
+- **Sync to alternative databases** - want to store alternative representations of ENSDb in databases that provide specialized benefits that Postgres doesn't offer, such as Elasticsearch, Typesense, Meilisearch, Redis, Kafka, Google BigQuery, and more? ENSEngine will ensure 100% delivery of database changes to sinks with strict ordering and exactly-once processing.
+- **Realtime dashboards** - surface ENS analytics and activity data as it happens.
+
+## How it works (high level)
+
+ENSEngine builds on solid foundations:
+
+1. **[ENSIndexer](/docs/services/ensindexer)** keeps **[ENSDb](/docs/services/ensdb)** up to date with the live, onchain state of ENS - including automatic chain reorg healing.
+2. **[ENSEngine](/docs/services/ensengine)** watches that database for changes and turns them into enriched, filtered, ENS-aware events.
+3. Those events get delivered to **your sinks** - webhooks, cache invalidation hooks, database sync targets, notification systems, and more.
+
+For the architecture overview, see [ENSEngine Overview](/docs/services/ensengine).
+
+## Related
+
+<LinkCard
+  title="ENSEngine Overview"
+  description="Learn more about ENSEngine."
+  href="/docs/services/ensengine"
+/>

docs/ensnode.io/src/content/docs/docs/integrate/integration-options/index.mdx

@@ -62,3 +62,21 @@ For special use cases that go beyond what the ENS Omnigraph exposes, query the l
   title='ensskills Integration Documentation'
   href="/docs/integrate/integration-options/ensskills"
 />
+
+## 7. `ensdb-cli` & ENSDb snapshots
+
+`ensdb-cli` is the operator-facing tool for ENSDb snapshots — portable, versioned packages of an ENSDb instance. Pull one down, restore it into Postgres, and start querying ENS in minutes instead of waiting days to complete a full historical indexing backfill from scratch.
+
+<LinkCard
+  title='ensdb-cli & ENSDb snapshots Documentation'
+  href="/docs/integrate/integration-options/ensdb-cli"
+/>
+
+## 8. ENSEngine
+
+ENSEngine watches your ENSDb for changes in real time and delivers ENS-aware events — including webhooks — to any sink you configure. Stop polling and start reacting to ENS state changes.
+
+<LinkCard
+  title='ENSEngine Integration Documentation'
+  href="/docs/integrate/integration-options/ensengine"
+/>

docs/ensnode.io/src/content/docs/docs/reference/roadmap.mdx

@@ -34,6 +34,20 @@ ENSNode could handle CCIP-Read logic internally, batch multiple requests to redu
 
 Besides dramatically decreasing latency for client applications, the Protocol Accelerator is also a key step forward in decentralization, away from reliance on centralized offchain gateway servers. This is a big win for the ENS protocol!
 
+## ENSDb CLI & Snapshots
+
+We're investing in [ENSDb](/docs/services/ensdb) as a first-class integration point - and the next big step is making it trivial *and inexpensive* to **operate** an ENSDb and to **share state** across instances. See the full teaser at [ensdb-cli & ENSDb snapshots](/docs/integrate/integration-options/ensdb-cli).
+
+Goals on this roadmap stream include:
+
+- **Snapshot creation & consumption** - publish a portable, versioned package of an ENSDb instance to a destination like Cloudflare R2, and pull it down to bootstrap a new ENSNode instance in minutes instead of waiting on a full historical backfill. Saves **both time and RPC cost** - consumers don't need to replay 9+ years of ENS history through their own RPC provider to catch up.
+- **Snapshot metadata** - record which ENSIndexer config, version, and chains a snapshot was produced from, so consumers can pick the right one and trust it for their use case.
+- **Snapshot diffing** - compare snapshots produced before and after an indexing change to confirm the change didn't unexpectedly alter indexed data. A powerful safety net for release reviews.
+- **Operational ENSNode CLI** - list indexer instances tracked in an ENSDb, inspect their configuration and indexing status, and clean up schemas that are no longer in use.
+- **Snapshot verification (exploratory)** - strategies for letting third parties confirm a snapshot's integrity, such as multi-publisher hash consensus or signed attestations. Open research, not a commitment.
+
+These capabilities will unlock dramatically faster - and cheaper - iteration for hackathon teams, self-hosters, marketplaces, and anyone building custom services on top of ENSDb.
+
 ## ENS TokenScope: ENS NFT Marketplace Data API
 
 With Reservoir shutting down in the coming months, ENSNode aims to provide replacement infrastructure for tokenized ENS name market data. This includes:

docs/ensnode.io/src/content/docs/docs/self-host/index.mdx

@@ -4,6 +4,7 @@ description: Decide whether to self-host ENSNode and understand the architecture
 ---
 
 import { LinkCard } from "@astrojs/starlight/components";
+import EnsDbSnapshotsTeaser from "../../../../components/molecules/EnsDbSnapshotsTeaser.astro";
 
 
 This page will help you decide whether to self-host ENSNode or use the hosted instances. Includes architecture overview of the ENSNode stack (ENSIndexer, ENSDb, ENSRainbow, ENSApi).
@@ -23,6 +24,20 @@ Running your own ENSNode instance is helpful for those that wish to:
 Note that because ENSNode makes many label healing requests to ENSRainbow while indexing, it's _imperative_ that they be on the same local network to minimize request time.
 :::
 
+## Bootstrap from a snapshot (coming soon)
+
+Self-hosting today means standing up a fresh ENSNode instance from zero and waiting on an initial backfill - including the RPC bill that comes with it. **[ENSDb snapshots and `ensdb-cli`](/docs/integrate/integration-options/ensdb-cli)** flatten that ramp.
+
+The headline value props for self-hosters:
+
+<EnsDbSnapshotsTeaser />
+
+<LinkCard
+  title="Read the full teaser"
+  description="Problem, outcomes, and who this is for — all in one page."
+  href="/docs/integrate/integration-options/ensdb-cli"
+/>
+
 ### Deploying with Docker
 
 The Docker deployment option provides the easiest way to run the full ENSNode suite of services both locally and in the cloud.

docs/ensnode.io/src/content/docs/docs/services/ensdb/index.mdx

@@ -88,6 +88,12 @@ ENSDb unlocks a new universe of ENS applications:
   href="/docs/services/ensdb/integrations/ensnode"
 />
 
+## What's next
+
+<Aside type="tip" title="Coming soon: ensdb-cli & ENSDb snapshots">
+We're building [**`ensdb-cli` & ENSDb snapshots**](/docs/integrate/integration-options/ensdb-cli) so you can pull down a fresh ENSDb in minutes instead of paying for a full historical RPC backfill among many other benefits.
+</Aside>
+
 ## Related Projects
 
 - **[ENSIndexer](/docs/services/ensindexer/)** — The reference [ENSDb Writer](/docs/services/ensdb/concepts/glossary#ensdb-writer) implementation