See how Chainstack uses Chainstack for Chainstack

Chainstack Self-Hosted is not just something we built for customers who want to run blockchain nodes on infrastructure they control. We use the same operational thinking inside Chainstack to run, supervise, and improve the Dedicated Nodes we provide to customers.

That matters because Dedicated Nodes are not a nice marketing wrapper around a server. A Dedicated Node is isolated infrastructure, tuned for a specific workload, across a specific protocol, network, client, cloud, region, and node mode. Ethereum full node in London is one shape. Solana with heavy data access is another. BNB Smart Chain archive workloads are another.

The short version

Dedicated Nodes	Self-Hosted
Chainstack-run node infrastructure for teams that need isolated resources, high throughput, and custom configuration.	The Chainstack node operations layer, packaged for teams that want to run nodes on their own infrastructure.

Internally, that combination changes Dedicated Node operations from “build another custom setup” to “deploy a tested, observable, repeatable node stack, then tune what actually needs tuning.”

It also gives us a brutal feedback loop. New protocols, clients, pre-configured setups, monitoring signals, and recovery workflows first meet Chainstack-owned traffic and production-like load before they become public Self-Hosted features.

If a feature cannot survive our own internal workloads, it is not ready for someone else’s production environment.

A Dedicated Node is not just a node

The word “node” is dangerously small.

That is the tutorial version. Production is less polite.

A real Dedicated Node setup has to answer questions like:

• Which client and version should run this protocol today?
• What resource profile is safe for this network, this mode, and this workload?
• How do we know the node is healthy beyond “the process is running”?
• What happens when a chain upgrade lands on Friday?
• How do we detect sync drift before the customer notices?
• How do we keep deployment logic consistent across Ethereum, BNB Smart Chain, Base, Optimism, Polygon, Solana, and the next protocol that arrives with a different personality?

This is why Chainstack Dedicated Nodes exist as a managed product. Customers get isolated infrastructure, choice of cloud and location, predictable billing, high performance, and Chainstack handling the operational work behind it.

But inside Chainstack, we still have to run that operational work well. At scale, “expert humans with scripts” is not a platform. It is a calendar full of future incidents.

Why Self-Hosted became useful internally

Chainstack Self-Hosted was built for teams that want to own their infrastructure without building the whole node operations layer themselves.

That is exactly the same problem we solve internally, only with a sharper edge. We run nodes for customers who expect reliability, performance, and fast support. We cannot afford mystery deployments, undocumented tweaks, or monitoring that only works when the person who built it is online.

So the Self-Hosted model gives us a cleaner internal operating pattern:

• Deployment through right-sized, pre-configured setups instead of one-off setup notes.
• Client configuration captured in the product, not scattered across private scripts.
• Monitoring and alerts included in the operating model, not added after the node is already live.
• Recovery behavior designed into the system.
• Upgrade workflows that can be tested, reviewed, and repeated.
• Protocol additions that move through the same path from internal validation to customer-ready operations.

For Dedicated Nodes, this means the under-the-hood work becomes more like running a factory and less like building every machine from loose parts.

The customer still gets the bespoke outcome: the right chain, mode, location, resources, and configuration for the workload. We get a repeatable way to build and operate it.

The boring magic: right-sized setups

The most underrated part of blockchain infrastructure is not latency. It is defaults.

Bad defaults create work forever. Good defaults quietly erase work before it exists.

Chainstack Self-Hosted currently supports production deployments of Ethereum Mainnet, Sepolia, and Hoodi full nodes with Reth and Prysm. Publicly, that looks like a deployment wizard and supported setup options. Internally, the same idea is much more important: a pre-configured setup is a decision we do not want every operator to remake from scratch.

For Ethereum, that means known client pairing, resource sizing, storage expectations, and snapshot-based bootstrapping. That is not just convenience. It is operational memory turned into product behavior.

When we run Dedicated Nodes, this matters because every repeated manual decision is a chance for drift:

• One node gets a slightly different resource profile.
• One deployment uses an older client combination.
• One runbook forgets a monitoring check.
• One region-specific setup carries a workaround nobody remembers.

Right-sized setups reduce that surface area. They give our teams a known starting point and let them spend attention on the parts that actually vary by customer workload.

The punchline is simple: if you want customization at scale, standardize everything around it.

Monitoring that starts before the incident

Anyone can check whether a service is up.

Blockchain nodes need better questions:

• Is the node synced?
• Is it catching up or falling behind?
• Are peer counts healthy?
• Is disk growth normal?
• Are execution and consensus clients disagreeing?
• Is Kubernetes fine while the blockchain client is quietly having a bad day?

Chainstack Self-Hosted ships with an integrated observability stack: Grafana, VictoriaMetrics, alerting, Kubernetes metrics, host-level metrics, and the Chainstack blockchain-node-exporter for chain-specific health signals.

This is exactly the kind of visibility Dedicated Node operations need. A node can look alive and still be operationally wrong. The process is running, the endpoint responds, but the data is stale, the node is behind, or the next storage threshold is closer than anyone wants.

The useful thing about building this into Self-Hosted is that monitoring stops being a side project.

It becomes part of the node product.

When we improve a dashboard, add a health signal, or discover that an alert is too noisy during a real internal rollout, that learning can feed back into Self-Hosted. The public product gets better because the internal environment is unforgiving.

Internal traffic comes first

A new protocol does not become easy because it has an RPC spec.

It becomes easy after the annoying parts are understood:

• What does initial sync actually look like?
• Which client versions are safe?
• What does normal resource usage look like under load?
• What failure modes are common?
• What should the first dashboard show?
• Which alerts are useful, and which ones wake people up for no reason?
• What should the default deployment look like for production?

That is why the validation path starts inside Chainstack, not on customer Dedicated Nodes.

By the time a customer-facing Dedicated Node setup is live, the point is not to learn whether the setup works. The point is to run a known, supervised, production-grade configuration for that customer’s workload.

When Chainstack adds or improves protocol support, we can route Chainstack-owned workloads through internal dedicated-node environments first. That can mean internal services, monitoring probes, benchmark jobs, traffic replays, and synthetic load shaped around patterns we already see on production nodes. The goal is not to copy one customer’s traffic. The goal is to recreate the pressure that real nodes face: request bursts, long-running reads, sync behavior, storage growth, client upgrades, and protocol-specific edge cases.

That is where the setup earns trust.

We can watch how it behaves when the chain is busy, when a client update lands, when storage grows faster than expected, or when a workload pattern makes a node uncomfortable. We can tune resources, adjust alerts, improve runbooks, and remove sharp edges before the setup becomes part of customer-facing Dedicated Node operations.

Only after that does it make sense to turn the lessons into public Self-Hosted setup options.

That is the path we want:

1. Build the internal setup.
2. Route Chainstack-owned traffic through it.
3. Stress it with production-like load.
4. Move it into Dedicated Node operations only when it is boring.
5. Package the stable workflow for Chainstack Self-Hosted customers.

Today, the public Self-Hosted release supports Ethereum full nodes. The roadmap is much bigger: by the end of 2026, we want Chainstack Self-Hosted to support every chain, starting with additional EVM-compatible chains and layer 2 networks, then expanding across the rest of the protocol lineup.

The goal is not to dump every chain into the product as fast as possible.

The goal is to make each chain boring enough to operate. That is harder. It is also much more useful.

My mission is to make blockchains boring.

If blockchains are ever going to support millions of people and businesses, they cannot feel like constant science experiments. pic.twitter.com/GtXlVNNh9L

— Ξugene Aseev (@easeev) March 26, 2026

What this means for customers

There are three customer-facing benefits to Chainstack using Chainstack this way.

First, Dedicated Nodes become faster and more consistent to deliver. Standardized deployment logic reduces manual variation, while still leaving room for workload-specific tuning.

Second, Self-Hosted gets better from real operations. Features are validated against the kind of node work Chainstack already does every day: deployment, sync, monitoring, updates, recovery, and protocol expansion.

Third, the distance between managed and self-hosted infrastructure gets smaller. Customers who use Dedicated Nodes get Chainstack-managed infrastructure. Customers who use Chainstack Self-Hosted get the Chainstack operational layer on their own infrastructure. Different ownership model, same direction: less custom ops work, more reliable node operations.

This is especially useful for teams that move between models.

The products do not compete as much as they meet customers at different levels of infrastructure control.

What we learned by using it ourselves

The biggest lesson is that blockchain infrastructure does not become scalable when you add more servers.

It becomes scalable when the decisions stop living in individual people’s heads.

Self-Hosted forces the operational model into the product:

• What should deployment look like?
• What should health mean?
• What should recovery do?
• What should an upgrade show before it runs?
• What should a new protocol setup include before anyone trusts it?

Those questions help us run Dedicated Nodes better. Running Dedicated Nodes helps us answer those questions better.

That is the loop.

And it is why “Chainstack uses Chainstack for Chainstack” is more than a funny headline. It is a useful product discipline.

We use Chainstack Self-Hosted to make Dedicated Node operations more repeatable.

We use Dedicated Node operations to make Chainstack Self-Hosted more real.

Then we ship the parts that survive.

Try Chainstack Self-Hosted

Want the same node operations layer on infrastructure you control? Get started with Chainstack Self-Hosted and deploy your first node with monitoring, updates, and self-healing.

FAQ