The ENS Manager App is the primary user interface for registering, renewing, and managing ENS names. While most users interact with the canonical deployment at app.ens.domains, organizations with internal name management requirements—custodians, exchanges, DAOs, and enterprises managing large portfolios—often need to self-host the application. This page covers the production readiness requirements for running a private instance, including build processes, environment configuration, and deployment patterns that ensure compatibility with the ENS protocol.
Protocols
ENS Manager App Production Readiness
A technical operations guide for teams deploying private instances of the ENS Manager App. Covers build processes, IPFS deployment patterns, environment variable configuration for different networks, and ongoing maintenance requirements.
introduction
SELF-HOSTED DEPLOYMENT ARCHITECTURE
Introduction
Operational requirements for teams deploying private instances of the ENS Manager App for internal name management workflows.
Self-hosting the Manager App requires understanding its deployment architecture: the application is a static React frontend built with Vite and designed for IPFS deployment. Operators must configure environment variables for target networks (mainnet, Sepolia, Holesky), IPFS gateways, and metadata service endpoints. The build process generates deterministic content-addressed assets, but teams must manage their own pinning infrastructure, gateway availability, and DNS records to serve the application reliably. Incorrect environment configuration can cause silent resolution failures, broken transaction flows, or display of stale name data.
Teams running private instances should also consider the operational divergence risk: the canonical app receives continuous updates for new ENS features (Name Wrapper fuses, new record types, CCIP-Read improvements), and self-hosted instances can drift from this baseline. Chainscore Labs can assist with deployment architecture review, environment validation, and establishing update monitoring processes to ensure private instances remain compatible with protocol changes and security patches.
SELF-HOSTING THE ENS MANAGER APP
Quick Facts
Operational facts for teams evaluating or deploying a private instance of the ENS Manager App for internal name management, branding, or air-gapped environments.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Deployment Model | The app is a static React site built with Vite and intended for deployment to IPFS or any static web server. | DevOps teams, platform engineers | Verify the build process and static asset pipeline match your hosting environment. |
Environment Configuration | Network behavior is controlled by environment variables (e.g., VITE_ETH_NETWORK, VITE_IPFS_GATEWAY) set at build time, not runtime. | Build engineers, SREs | Audit your CI/CD pipeline to ensure correct variables are injected for each target environment (mainnet, testnet, local). |
RPC Provider Dependency | The app relies on a configured JSON-RPC endpoint for all onchain reads and writes. No fallback is built in. | Infrastructure teams, wallet operators | Provision a reliable, private RPC endpoint or a paid provider plan to avoid public rate-limiting and ensure availability. |
IPFS Gateway Reliance | Content-addressed resources (e.g., avatars, metadata) are fetched through a configured IPFS gateway. A slow or censoring gateway breaks profile display. | Product teams, UX engineers | Configure a dedicated, high-availability IPFS gateway or pinning service to control latency and content availability. |
Wallet Connection | The app uses RainbowKit for wallet connections. Supported wallet lists and RPCs are configured at build time. | Wallet integration teams, security engineers | Review the RainbowKit configuration to ensure only intended wallet connectors are enabled for your user base. |
Subgraph Dependency | Name and registration data is indexed from the ENS subgraph. Stale or failed subgraph queries cause incorrect UI state. | Data engineers, backend teams | Monitor subgraph health and latency. Consider running your own Graph Node instance for production reliability. |
Upgrade Path | The app is updated via the main ENS GitHub repository. Self-hosted instances must manually pull and rebuild to incorporate upstream fixes. | Maintenance teams, DevOps | Establish a regular sync schedule against the upstream release tags to avoid falling behind on security patches and resolver compatibility. |
deployment-architecture
SELF-HOSTING REQUIREMENTS
Deployment Architecture and Build Process
The ENS Manager App is a static React application designed for deployment to IPFS, with a build process that requires specific environment configuration for different Ethereum networks.
The ENS Manager App is built as a single-page application using the Thorin design system and the @ensdomains/ensjs library. The production build process compiles the application into static assets intended for deployment on IPFS, ensuring censorship-resistant access to the ENS management interface. Teams that choose to self-host a private instance must replicate this build pipeline, configuring environment variables to target the correct Ethereum network and offchain gateway endpoints.
The build process relies on environment variables such as VITE_ENS_MAINNET_RPC_URL and VITE_ENS_SEPOLIA_RPC_URL to inject network-specific RPC endpoints at build time. For teams operating on testnets or custom networks, misconfiguration of these variables leads to a non-functional application that cannot resolve names or submit transactions. The app's reliance on CCIP-Read (EIP-3668) for offchain name resolution means that gateway endpoint configuration must also be verified against the canonical gateway deployments for the target network.
Operators self-hosting the ENS Manager App must establish a repeatable build and deployment process that includes IPFS pinning, DNSLink updates for human-readable access, and a strategy for updating the deployed instance when new app releases ship. Because the app interacts directly with onchain ENS contracts, running an outdated version can expose users to a degraded registration flow, missing Name Wrapper fuse management features, or incompatibility with the latest resolver interface standards. Teams should monitor the official ENS App release notes and the ens-app-v3 repository for breaking changes that require a rebuild and redeployment of private instances.
SELF-HOSTING IMPACT
Affected Teams and Systems
Infrastructure Operators
Teams deploying private instances of the ENS Manager App must configure the build environment to target the correct network (mainnet, Sepolia, or Holesky) via environment variables. The app is designed to be built as a static site and deployed to IPFS or traditional web hosting.
Key operational requirements:
- Pin the production build to IPFS and ensure gateway availability.
- Configure the
REACT_APP_CHAIN_IDandREACT_APP_PROVIDER_URLto point to your preferred RPC endpoint. - Verify that the IPFS gateway or web server correctly serves the SPA routing for all paths.
- Monitor the upstream ENS App repository for security patches and breaking changes in the build pipeline.
Failure to keep the self-hosted instance in sync with upstream releases can lead to broken registration flows or incorrect name management behavior.
implementation-impact
SELF-HOSTING REQUIREMENTS
Operational Impact Areas
Teams deploying private instances of the ENS Manager App must address build configuration, environment management, and deployment architecture to ensure compatibility with target networks and resolution infrastructure.
02
IPFS Deployment Architecture
The ENS Manager App is designed as a static site deployed to IPFS. Self-hosters must understand content-addressed routing, pinning strategies, and gateway fallback patterns. A deployment that is not pinned across multiple nodes will become unavailable. Teams should configure dedicated IPFS gateways or use pinning services to ensure reliable access, and must update DNSLink records to point to the latest CID after each build.
03
Build Process and Dependency Management
The production build relies on specific Node.js and pnpm versions. Drifting from the locked dependency tree can introduce breaking changes in the Thorin design system or ENSJS library. Teams should implement CI/CD pipelines that verify the build against the canonical lockfile and run integration tests against a forked mainnet to catch resolution failures before deploying a new CID to production.
04
CCIP-Read Gateway Integration
A self-hosted app instance must be configured to use a specific CCIP-Read gateway for offchain name resolution. Using the default public gateway introduces a trust and availability dependency on a third party. Teams managing sensitive name operations should deploy their own gateway instance and configure the app's NEXT_PUBLIC_CCIP_READ_GATEWAY variable to point to it, ensuring end-to-end control over the resolution path.
05
Network Fork and Testnet Parity
Testing a self-hosted instance against Sepolia or Holesky requires the test environment to mirror mainnet contract states, including the registry, registrar controllers, and Name Wrapper. Discrepancies in resolver addresses or subgraph schemas between environments can mask integration bugs. Teams should verify that their testnet deployment exercises the same code paths as production, including registration flows and fuse management.
06
Monitoring and Availability
A private ENS Manager App is only as available as its IPFS gateway and configured subgraph endpoint. Operators should monitor gateway response times, subgraph indexing lag, and CID resolution health. If the configured subgraph falls behind the chain head, the app will display stale ownership and expiry data, leading to incorrect name management decisions. Automated alerts on these dependencies are a production requirement.
SELF-HOSTED ENS MANAGER APP
Operational Risk Matrix
Risk assessment for teams operating a private instance of the ENS Manager App, covering deployment architecture, configuration, and dependency management.
| Area | Failure Mode | Severity | Affected Actors | Mitigation / Action |
|---|---|---|---|---|
IPFS Gateway Availability | The IPFS gateway serving the app's static build becomes unavailable, preventing users from loading the UI. | High | Internal users, Operations team | Pin the build to multiple IPFS nodes or pinning services. Deploy behind a redundant gateway proxy or use a dedicated, high-availability IPFS cluster. |
Environment Configuration | Incorrect | Critical | Internal users, Operations team | Implement a strict build pipeline with environment validation. Verify all contract addresses against the canonical ENS deployments for the target network before deployment. |
DNS/ENS Routing Failure | The DNS record or ENS name pointing to the IPFS hash is misconfigured, hijacked, or expires, making the app unreachable. | High | Internal users, Operations team | Use DNSSEC for the hosting domain. If using an ENS name, manage it with a multi-sig and set long expiry times. Monitor resolution records and TLS certificate validity. |
Stale Deployment | The self-hosted instance is not updated to track the latest ENS Manager App release, leading to missing features or incompatibility with new resolver or Name Wrapper logic. | Medium | Internal users, Wallet/Integration partners | Subscribe to the ENS App release notes. Automate the build and deployment pipeline to trigger on new upstream releases after a review period. |
Thorin Design System Drift | A custom fork of the app fails to incorporate Thorin component updates, causing visual bugs or broken UI elements. | Low | Internal users, Front-end developers | Monitor the Thorin Design System changelog. Run visual regression tests as part of the CI/CD pipeline when updating the upstream app or Thorin dependency. |
CCIP-Read Gateway Dependency | The self-hosted app relies on a specific CCIP-Read gateway that goes offline or returns malformed data, breaking resolution for offchain names. | High | Internal users | Configure multiple redundant gateway endpoints in the app's environment. Implement client-side timeouts and graceful fallback UI for resolution failures. |
Build Artifact Integrity | A compromised CI/CD pipeline or dependency supply chain injects malicious code into the app's production build. | Critical | Internal users, Security team | Pin all npm dependencies with exact versions and integrity hashes. Build in a hermetic, audited environment. Reproduce and verify the build hash against the upstream release before deployment. |
SELF-HOSTING THE ENS MANAGER APP
Production Deployment Checklist
A technical checklist for teams preparing to deploy a private instance of the ENS Manager App. This covers build verification, environment configuration, IPFS deployment patterns, and operational readiness to ensure a reliable, secure, and maintainable production instance.
Confirm that the production build is generated from a trusted, immutable source and can be reproduced independently.
- What to check: Clone the exact release tag from the canonical
ensdomains/ens-app-v3repository. Execute the build process in a clean, containerized environment matching the documented Node.js version. - Why it matters: A compromised build pipeline can inject malicious code into a self-hosted instance, leading to seed phrase theft or unauthorized transaction signing. Reproducibility ensures the deployed code matches the audited source.
- Readiness signal: The hash of your locally built
out/directory matches the hash of the files from the official IPFS release or a trusted community verifier.
resource-links
ENS MANAGER APP PRODUCTION READINESS
Source Resources
Canonical resources for teams self-hosting, reviewing, or integrating the ENS Manager App. Use these sources to verify build behavior, contract dependencies, UI components, metadata assumptions, and production configuration before deployment.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
SELF-HOSTING THE ENS MANAGER APP
Frequently Asked Questions
Common operational questions for teams deploying a private instance of the ENS Manager App for internal name management, testing, or air-gapped environments.
The ENS Manager App is a Next.js application. To build and run it, you need:
- Node.js: Version 18 or later.
- Package Manager:
pnpmis required. Install it globally vianpm install -g pnpm. - Environment Variables: A
.env.localfile must be configured with the required variables for your target network.
Run pnpm install to fetch dependencies and pnpm dev for a local development server. For a production build, use pnpm build followed by pnpm start. Verify your Node.js version with node -v before starting to avoid cryptic build errors.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.