Add scalability story to ENSNode self-hosting module#2146
Merged
tk-o merged 8 commits intoMay 20, 2026
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Caution Review failedFailed to post review comments Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds a new Scalability documentation page describing ENSNode's horizontal scaling approach via PostgreSQL asynchronous replication, introduces a reusable hosted-instance SDK-version warning component wired into integration pages, and updates all example and package READMEs with ENSNode v1.13 version-compatibility notices. ChangesENSNode Docs and Hosted-Instance Warnings
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx`:
- Line 30: Rephrase the awkward sentence about replicas for clarity: update the
sentence mentioning ENSApi and ENSDb so it reads something like "As your query
load grows, add more PostgreSQL replicas to the ENSDb primary and deploy
additional ENSApi instances pointing to those replicas," or similar; edit the
paragraph referencing ENSApi and ENSDb to use "replicas to the ENSDb primary" or
"replicas of the ENSDb primary" and ensure the coupling between adding replicas
and ENSApi instances is clear.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: d40a9d14-6c31-46c9-ac02-38deea926d6d
⛔ Files ignored due to path filters (1)
docs/ensnode.io/public/ensnode-scalability.svgis excluded by!**/*.svg
📒 Files selected for processing (2)
docs/ensnode.io/config/integrations/starlight/sidebar-topics/self-host.tsdocs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx
Contributor
Greptile SummaryThis PR adds a new scalability documentation page to the ENSNode self-hosting module, explaining how to horizontally scale ENSApi and ENSDb using PostgreSQL async replication. It also introduces a reusable
Confidence Score: 5/5Documentation-only change with no runtime code modifications — safe to merge. All changes are documentation content, MDX pages, an Astro presentational component, an SVG asset, and README updates. No application logic, database migrations, or API contracts are touched. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[ENSIndexer] -->|writes| B[ENSDb Primary]
B -->|async replication| C[ENSDb Replica 1]
B -->|async replication| D[ENSDb Replica 2]
B -->|async replication| E[ENSDb Replica N]
C --> F[ENSApi Instance 1]
D --> G[ENSApi Instance 2]
E --> H[ENSApi Instance N]
F & G & H -->|serve requests| I[Load Balancer / Clients]
J[ENSRainbow] <-->|label healing, local network| A
Reviews (6): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Pull request overview
This PR expands the ENSNode self-hosting documentation with a dedicated scalability page, explaining how ENSNode’s architecture separates write-heavy indexing from read-heavy API traffic and illustrating a horizontally scalable deployment using PostgreSQL replication.
Changes:
- Added a new “Scalability” doc page under Self-hosting describing single-writer / many-reader architecture and Postgres read replicas.
- Added a deployment architecture diagram SVG to support the scalability narrative.
- Linked the new page in the Self-host sidebar navigation.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx | New scalability documentation page describing read/write separation and Postgres replication approach. |
| docs/ensnode.io/public/ensnode-scalability.svg | New architecture diagram asset referenced by the scalability page. |
| docs/ensnode.io/config/integrations/starlight/sidebar-topics/self-host.ts | Adds “Scalability” to the Self-host sidebar items. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 2. **Replicas**: The primary ENSDb instance asynchronously replicates its data to one or more ENSDb read replicas. | ||
| 3. **Read scaling**: You can connect any number of ENSApi instances to the ENSDb primary instance or to any ENSDb replica. | ||
|
|
||
| Because ENSApi is read-only, it can safely connect to an ENSDb replica without risking stale writes or replication conflicts. As your query load grows, you simply add more PostgreSQL replicas for ENSDb primary instance and more ENSApi instances pointing to them. |
…lity-story-to-ensnode-self-host-module
|
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (3)
docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx (3)
20-20:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winClarify that true isolation requires replicas.
The statement "indexing process remains unaffected" is misleading if ENSApi reads from the primary database. Heavy read traffic on the primary can cause CPU/I/O contention that impacts indexing performance. True isolation requires ENSApi to connect to read replicas, not the primary.
Consider adding a note here that clarifies this point, or forward-reference the replication strategy discussed in the next section.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 20, The sentence claiming "indexing process remains unaffected" is misleading because ENSApi reading from the primary can still cause CPU/I/O contention; update the paragraph referencing ENSApi and ENSIndexer to clarify that true isolation requires ENSApi to connect to read replicas (not the primary) or to otherwise offload read traffic, and either add a short note here or a forward-reference to the replication strategy section that explains using read replicas for ENSApi to avoid impacting the ENSIndexer.
26-26: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUse modern PostgreSQL terminology.
The term "Primary (master)" uses deprecated terminology. Modern PostgreSQL documentation refers to this simply as "Primary" without the parenthetical.
📝 Suggested fix
-1. **Primary (master)**: ENSIndexer instance writes to a single ENSDb primary instance. +1. **Primary**: ENSIndexer instance writes to a single ENSDb primary instance.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 26, Replace the deprecated phrase "Primary (master)" with the modern PostgreSQL term "Primary" in the sentence that describes the ENSIndexer writing to an ENSDb primary instance (look for the string "Primary (master): ENSIndexer instance writes to a single ENSDb primary instance."). Update only the label text to "Primary" so the line reads "Primary: ENSIndexer instance writes to a single ENSDb primary instance."
30-30:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix grammar and clarify replication lag implications.
Two issues:
- "replicas for the ENSDb primary instance" is grammatically awkward—should be "replicas of" or "replicas to"
- Missing explanation that asynchronous replication introduces lag, so replicas may temporarily serve slightly stale data (which is acceptable for read-only workloads)
📝 Suggested fix
-Because ENSApi is read-only, it can safely connect to an ENSDb replica without risking stale writes or replication conflicts. As your query load grows, you simply add more PostgreSQL replicas for the ENSDb primary instance and more ENSApi instances pointing to them. +Because ENSApi is read-only, it can safely connect to an ENSDb replica without risking stale writes or replication conflicts. Asynchronous replication means replicas may have slight lag and could temporarily serve slightly stale data, but this is acceptable for read-only workloads. As your query load grows, you simply add more PostgreSQL replicas of the ENSDb primary instance and more ENSApi instances pointing to them.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 30, Reword the sentence to use correct preposition and add a brief note about asynchronous replication lag: change "replicas for the ENSDb primary instance" to "replicas of the ENSDb primary" (or "replicas for the ENSDb primary") and append that because ENSApi is read-only it can safely point to PostgreSQL replicas of ENSDb, but those replicas use asynchronous replication and may temporarily serve slightly stale data—this is acceptable for read-only workloads; reference ENSApi and ENSDb in the updated sentence to keep context clear.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx`:
- Line 20: The sentence claiming "indexing process remains unaffected" is
misleading because ENSApi reading from the primary can still cause CPU/I/O
contention; update the paragraph referencing ENSApi and ENSIndexer to clarify
that true isolation requires ENSApi to connect to read replicas (not the
primary) or to otherwise offload read traffic, and either add a short note here
or a forward-reference to the replication strategy section that explains using
read replicas for ENSApi to avoid impacting the ENSIndexer.
- Line 26: Replace the deprecated phrase "Primary (master)" with the modern
PostgreSQL term "Primary" in the sentence that describes the ENSIndexer writing
to an ENSDb primary instance (look for the string "Primary (master): ENSIndexer
instance writes to a single ENSDb primary instance."). Update only the label
text to "Primary" so the line reads "Primary: ENSIndexer instance writes to a
single ENSDb primary instance."
- Line 30: Reword the sentence to use correct preposition and add a brief note
about asynchronous replication lag: change "replicas for the ENSDb primary
instance" to "replicas of the ENSDb primary" (or "replicas for the ENSDb
primary") and append that because ENSApi is read-only it can safely point to
PostgreSQL replicas of ENSDb, but those replicas use asynchronous replication
and may temporarily serve slightly stale data—this is acceptable for read-only
workloads; reference ENSApi and ENSDb in the updated sentence to keep context
clear.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f4521dce-f582-4de9-bf60-51ba885be653
📒 Files selected for processing (1)
docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx
lightwalker-eth
approved these changes
May 19, 2026
Member
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@tk-o Good to see this, thank you! Reviewed and shared feedback 👍 Please take the lead to merge when ready!
| link: "/docs/self-host/terraform", | ||
| }, | ||
| { | ||
| label: "Scalability", |
Member
There was a problem hiding this comment.
Suggested change
| label: "Scalability", | |
| label: "Horizontal Scaling", |
| - **ENSIndexer** is the sole writer to ENSDb. It processes blockchain events and updates the database with the latest ENS state. | ||
| - **ENSApi** is a read-only service. It serves GraphQL and REST API requests by querying ENSDb, but never writes to it. | ||
|
|
||
| This separation insulates ENSIndexer from high request volumes. Whether you serve 10 requests per second or 10,000, the indexing process remains unaffected because ENSApi does not compete with ENSIndexer for database write locks or indexer resources. |
Member
There was a problem hiding this comment.
Suggested change
| This separation insulates ENSIndexer from high request volumes. Whether you serve 10 requests per second or 10,000, the indexing process remains unaffected because ENSApi does not compete with ENSIndexer for database write locks or indexer resources. | |
| The best first step for increasing your ENSNode's overall horizontal scalability is to horizontally scale ENSApi. You can go far with this, but if your request volumes become exceptionally high there is potential CPU/IO contention in a single "primary" ENSDb instance. |
|
|
||
| - **One ENSIndexer instance** → writes to the ENSDb primary instance | ||
| - **One ENSDb primary instance** → replicates asynchronously to `M` replicas | ||
| - **Multiple ENSApi instances** → each of `N` instances connected to the ENSDb primary instance or any ENSDb replica (often load-balanced across replicas) |
Member
There was a problem hiding this comment.
This is the massive horizontal scalability case, right? Therefore, suggest to say that they only connect to replicas and no ENSApi instances connect to the primary.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: lightwalker.eth <126201998+lightwalker-eth@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx (2)
40-40:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAlign "massive" scaling guidance with isolation best practice.
In a "Going Massive" deployment scenario, ENSApi instances should connect exclusively to read replicas (not to the primary) to fully isolate the indexing workload from API request volumes. Line 40 currently states ENSApi can connect to "the ENSDb primary instance or any ENSDb replica," which contradicts the isolation strategy described earlier in lines 26-28.
🔧 Suggested fix for consistency
-- **Multiple ENSApi instances** → each of `N` instances connected to the ENSDb primary instance or any ENSDb replica (often load-balanced across replicas) +- **Multiple ENSApi instances** → each of `N` instances connected exclusively to ENSDb replica instances (load-balanced across replicas to fully isolate indexing from API request volumes)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 40, The "Multiple ENSApi instances" bullet currently allows connecting to "the ENSDb primary instance or any ENSDb replica" which conflicts with the isolation guidance; update that bullet so it explicitly states each ENSApi instance must connect exclusively to ENSDb read replicas (not the primary) to fully isolate indexing from API request traffic and mirror the earlier isolation guidance referenced in the doc; modify the phrase mentioning "ENSDb primary instance" to "ENSDb read replicas" (or similar) under the "Multiple ENSApi instances" bullet to ensure consistency.
20-20: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winQualify the isolation claim for completeness.
The statement "the indexing process remains unaffected" is accurate regarding write locks but doesn't mention potential CPU/IO contention when ENSApi instances read from the primary database. Consider adding a brief note that full isolation from high request volumes requires read replicas (which is explained in the next section).
📝 Suggested clarification
-This separation insulates ENSIndexer from high request volumes. Whether you serve 10 requests per second or 10,000, the indexing process remains unaffected because ENSApi does not compete with ENSIndexer for database write locks or indexer resources. +This separation insulates ENSIndexer from high request volumes. Whether you serve 10 requests per second or 10,000, the indexing process remains unaffected because ENSApi does not compete with ENSIndexer for database write locks or indexer resources. For complete isolation from extremely high API request volumes, you can connect ENSApi instances to read replicas (explained below).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 20, The sentence claiming "the indexing process remains unaffected" should be qualified: change the paragraph that references ENSIndexer and ENSApi to state that write-lock contention is avoided but CPU/IO contention can still occur if ENSApi instances perform heavy reads against the primary database; explicitly mention that full operational isolation requires using read replicas (referencing the upcoming read-replicas section) to offload read traffic and avoid impacting ENSIndexer's resources. Ensure you reference ENSIndexer and ENSApi by name so readers see the distinction.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx`:
- Line 13: Standardize heading capitalization for consistency: change the
heading "Horizontally scale ENSApi" to use the same title-casing style as
"Horizontally Scale ENSDb" (e.g., "Horizontally Scale ENSApi") and verify other
similar headings follow the same capitalization rule; update the heading text in
the document where "Horizontally scale ENSApi" appears and any other occurrences
(e.g., "Horizontally Scale ENSDb") to match the chosen title-case style.
- Line 11: Update the phrasing "read / write workloads" in the documentation
sentence to use the consistent technical convention "read/write" (remove the
spaces around the slash) so the sentence reads "...By separating read/write
workloads and making use of PostgreSQL's async replication..." to maintain
consistent formatting for read/write throughout the docs.
- Line 30: The sentence uses non-standard phrasing ("without write-routing or
write-conflict concerns"); simplify it by stating that ENSApi is read-only and
can connect to ENSDb replicas, but replica reads may lag due to asynchronous
replication—replace the phrase referencing "write-routing or write-conflict"
with a concise note about potential replication lag and how scaling adds more
PostgreSQL replicas and ENSApi instances pointing to them (referencing ENSApi
and ENSDb primary/replica concepts).
---
Duplicate comments:
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx`:
- Line 40: The "Multiple ENSApi instances" bullet currently allows connecting to
"the ENSDb primary instance or any ENSDb replica" which conflicts with the
isolation guidance; update that bullet so it explicitly states each ENSApi
instance must connect exclusively to ENSDb read replicas (not the primary) to
fully isolate indexing from API request traffic and mirror the earlier isolation
guidance referenced in the doc; modify the phrase mentioning "ENSDb primary
instance" to "ENSDb read replicas" (or similar) under the "Multiple ENSApi
instances" bullet to ensure consistency.
- Line 20: The sentence claiming "the indexing process remains unaffected"
should be qualified: change the paragraph that references ENSIndexer and ENSApi
to state that write-lock contention is avoided but CPU/IO contention can still
occur if ENSApi instances perform heavy reads against the primary database;
explicitly mention that full operational isolation requires using read replicas
(referencing the upcoming read-replicas section) to offload read traffic and
avoid impacting ENSIndexer's resources. Ensure you reference ENSIndexer and
ENSApi by name so readers see the distinction.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e5f6efd4-7f1f-4820-8ae0-4652d6f7179c
📒 Files selected for processing (1)
docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx
|
|
||
| import { LinkCard } from '@astrojs/starlight/components'; | ||
|
|
||
| ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read / write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance. |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Use consistent formatting for "read/write".
The phrase "read / write workloads" has spaces around the slash. In technical documentation, the standard convention is to write "read/write" without spaces.
✏️ Suggested fix
-ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read / write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance.
+ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read/write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read / write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance. | |
| ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read/write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 11,
Update the phrasing "read / write workloads" in the documentation sentence to
use the consistent technical convention "read/write" (remove the spaces around
the slash) so the sentence reads "...By separating read/write workloads and
making use of PostgreSQL's async replication..." to maintain consistent
formatting for read/write throughout the docs.
|
|
||
| ENSNode's architecture achieves effectively limitless horizontal scalability, no matter how large your query demands might be. By separating read / write workloads and making use of PostgreSQL's async replication you can scale your ENSNode deployment to handle any request volumes while continuing to index the latest ENS data without impact to indexing performance. | ||
|
|
||
| ## Horizontally scale ENSApi |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Standardize heading capitalization.
The section headings use inconsistent capitalization: "Horizontally scale ENSApi" (line 13) vs. "Horizontally Scale ENSDb" (line 22). Use consistent capitalization across similar heading levels.
✏️ Suggested fix
-## Horizontally scale ENSApi
+## Horizontally Scale ENSApiAlso applies to: 22-22
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/ensnode.io/src/content/docs/docs/self-host/scalability.mdx` at line 13,
Standardize heading capitalization for consistency: change the heading
"Horizontally scale ENSApi" to use the same title-casing style as "Horizontally
Scale ENSDb" (e.g., "Horizontally Scale ENSApi") and verify other similar
headings follow the same capitalization rule; update the heading text in the
document where "Horizontally scale ENSApi" appears and any other occurrences
(e.g., "Horizontally Scale ENSDb") to match the chosen title-case style.
| - **ENSIndexer** is the sole writer to ENSDb. It processes blockchain events and updates the database with the latest ENS state. | ||
| - **ENSApi** is a read-only service. It serves GraphQL and REST API requests by querying ENSDb, but never writes to it. | ||
|
|
||
| This separation insulates ENSIndexer from high request volumes. Whether you serve 10 requests per second or 10,000, the indexing process remains unaffected because ENSApi does not compete with ENSIndexer for database write locks or indexer resources. |
Comment on lines
+10
to
+21
| * - "both": mention both enssdk and enskit, show both install commands (default) | ||
| */ | ||
| for?: "enssdk" | "enskit" | "both"; | ||
| } | ||
|
|
||
| const { for: target = "both" } = Astro.props; | ||
| --- | ||
|
|
||
| <Aside type="tip" title="No backend required"> | ||
| You don't need to run your own ENSNode to follow this guide — the steps below default to a NameHash-hosted instance. Browse the available deployments below. | ||
| </Aside> | ||
| <HostedInstanceSdkVersionWarning for={target} /> |
Comment on lines
+40
to
+41
|
|
||
| **Important:** Our hosted ENSNode instances currently run ENSNode v1.13. The latest published version of `enssdk` is `1.14.0+`, which contains breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. If you are querying a hosted instance from your own app, you **must** use `enssdk@1.13.1` to avoid type errors and runtime mismatches. This notice will be removed once the hosted instances are upgraded. |
Comment on lines
+36
to
+37
|
|
||
| **Important:** Our hosted ENSNode instances currently run ENSNode v1.13. The latest published versions of `enskit` and `enssdk` are `1.14.0+`, which contain breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. If you are querying a hosted instance from your own app, you **must** use `enskit@1.13.1` and `enssdk@1.13.1` to avoid type errors and runtime mismatches. This notice will be removed once the hosted instances are upgraded. |
Comment on lines
+26
to
+28
| <Aside type="caution" title="Version compatibility with hosted instances"> | ||
| Our hosted ENSNode instances currently run ENSNode v1.13. If you are querying them from your own app, you <strong>must</strong> use <span set:html={sdkList} />. The latest published versions (<code>1.14.0+</code>) contain breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. Use these exact install commands: | ||
|
|
Comment on lines
+13
to
+17
| > **Version compatibility:** Our hosted ENSNode instances currently run ENSNode v1.13. If you are querying them from your own app, you **must** use `enssdk@1.13.1`. The latest published version (`1.14.0+`) contains breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. This notice will be removed once the hosted instances are upgraded. | ||
| > | ||
| > ```bash | ||
| > npm install enssdk@1.13.1 | ||
| > ``` |
Comment on lines
+9
to
+18
| ## Installation | ||
|
|
||
| ```bash | ||
| npm install enskit enssdk | ||
| ``` | ||
|
|
||
| > **Version compatibility:** Our hosted ENSNode instances currently run ENSNode v1.13. If you are querying them from your own app, you **must** use `enskit@1.13.1` and `enssdk@1.13.1`. The latest published versions (`1.14.0+`) contain breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. This notice will be removed once the hosted instances are upgraded. | ||
| > | ||
| > ```bash | ||
| > npm install enskit@1.13.1 enssdk@1.13.1 |
Comment on lines
+18
to
+27
|
|
||
| const sdkList = isEnskit | ||
| ? "<code>enskit@1.13.1</code> and <code>enssdk@1.13.1</code>" | ||
| : isBoth | ||
| ? "<code>enssdk@1.13.1</code> (and <code>enskit@1.13.1</code> when using React)" | ||
| : "<code>enssdk@1.13.1</code>"; | ||
| --- | ||
|
|
||
| <Aside type="caution" title="Version compatibility with hosted instances"> | ||
| Our hosted ENSNode instances currently run ENSNode v1.13. If you are querying them from your own app, you <strong>must</strong> use <span set:html={sdkList} />. The latest published versions (<code>1.14.0+</code>) contain breaking changes in the Omnigraph API data model not yet deployed to our hosted infrastructure. Use these exact install commands: |
…lity-story-to-ensnode-self-host-module
tk-o
deleted the
docs/2115-add-scalability-story-to-ensnode-self-host-module
branch
This was referenced May 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lite PR
Tip: Review docs on the ENSNode PR process
Summary
Why
Testing
Notes for Reviewer (Optional)
Pre-Review Checklist (Blocking)