Switch From Railway to Render

[lightwalker-eth]

Key issues with Railway

1. Railway's Poor Indexing Performance

Summary of indexing performance per environment

• Railway
  • ENSIndexer Alpha: 21h42m
  • ENSIndexer Mainnet (subgraph-only): 12h51m
• Contabo VDS L
  • ENSIndexer Alpha: 7h13m
  • ENSIndexer Mainnet (subgraph-only): 4h7m
• Macbook M1
  • ENSIndexer Alpha: 8h50m
  • ENSIndexer Mainnet (subgraph-only): 5h

Based on this limited comparison, we can see that Railway is at least two times slower than other environments we've tested.

This is even after transitioning to Railway's recently launched Railway Metal.

Railway is at least 2-3x slower on historical backfills. This is a huge issue when it comes to development productivity and also our ability to reduce "disaster recovery" downtime.

2. Railway Doesn't Support Full Infrastructure-As-Code Deployments

We've tried making use of an unofficial Railway Terraform provider and defined Terraform scripts to the extent that is supported by the unofficial Railway Terraform provider. However, key use cases are missing in this unofficial terraform provider. This results in a situation where we have part of our infrastructure as IaC, but other parts aren't. This can be confusing / complicated and a frequent source of anxiety with each incremental release we make. We need to manually note down and coordinate actions with releases.

We also have experienced issues such as API rate limiting errors from Railway when using the unofficial Railway Terraform provider.

3. Railway Lacking Maturity As A Hosting Platform

Railway is frequently shipping new features, which is nice. But the maturity of the overall existing feature set leaves a lot to be desired for production-critical use cases.

4. Caution Recommending Railway To Others

We need to take consideration of the recommendations we share with others who run their own ENSNode instances. This gives hesitation when recommending others use Railway as they would experience similar issues as we have above.

Thoughts on Optimizing Simplicity of ENSNode Deployments

So far we've been constraining ourselves to Railway with the goal of optimizing how simple it is for anyone to run their own ENSNode instance. Without 100% IaC support however, the naive Railway hosting configuration others are likely to setup will have shortcomings that won't be mature / production-ready. For example, others may not understand how to setup or manage blue/green deployments for zero-downtime upgrades.

We should also consider the support complexity we might experience from others running their own ENSNode instances in production environments. If we aren't managing all through IaC scripts then it can make supporting ENSNode version upgrades for others more complicated.

Key Hosting Provider Goals (partial list)

1. Support 100% Infrastructure-as-Code deployments.
2. This should include everything from environment variables to DNS configs, etc.
3. It's ok if we incrementally upgrade our IaC scripts across time, but we should only consider cloud providers where we are confident we can successfully complete all the desired upgrades.
4. We should deliver mature production quality IaC deployment configurations that help others host their own ENSNode instances in a mature, production quality manner that benefits from all of our learnings and optimizations.
5. Deliver Optimized Indexing Performance.
   1. At least as fast as running on a Macbook M1 and ideally faster.
6. Support our goal of moving our production ENSAdmin deployment out of Vercel and into the same hosting provider as everything else.
7. Ensure the hosting provider offers multiple regions across the globe. Reducing latency in ENS protocol lookups is one of our key goals. We should position ourselves for being able to support deployments to globally distributed datacenters in the coming future.
8. For optimized uptime, there could also be benefits to us not being reliant on a single cloud-provider. It would be nice if our IaC scripts could be used on more than one cloud-provider, such that:
   1. ... we or others can pick which of the supported cloud-providers we prefer.
   2. ... we or others can create parallel deployments across cloud-providers, such that if one cloud-provider goes down, we fail over to the other.

Subtasks

• Docs Updates
  • Update and refine our Terraform docs and our overall Deployment docs
  • Remove our Railway docs
• Merge Feat/838 switch from Railway to Render #901
  • Note: This gives us an initial "yellow" environment on Render
• Enhance Terraform configs
  • Traefik instance with DNS records and configuration source for Traefik
  • Integrate ENSNode Terraform with Traefik
• Support switching to and deploying to the new "yellow" environment on Render. See here and here.
  • Merge Split CI/CD workflows for ENSNode and ENSDb Playground deployments #2338
• Execute full transition from Railway to Render
  • Create new "blue" and "green" environments on Render
  • Destroy our temporary "yellow" environment on Render
  • Resolve: What (if anything) should we do related to the "postgres exporter" (on Railway blue and green), or prometheus / grafana (on Railway green)
  • Destroy all of our old environments on Railway, including "blue", "green", and "ReverseProxy".
  • Destroy the "Terraform Test" project on Railway
  • Remove Railway from deployment scripts here and here.
  • Cleanup how $PONDER_COMMAND is used in apps/ensindexer/Dockerfile.
  • Note: For now it's ok to keep the various "Deploy to Railway" buttons for ENSRainbow. These aren't hurting anything.

[BanaSeba]

After we merge #901 we will have a single environment on Render.
We still need to add:

• Traefik instance with DNS records and configuration source for Traefik
• Integrate ENSNode Terraform with Traefik
• Document overall process

[lightwalker-eth]

@BanaSeba Thank you. Can you please edit the "Next Steps" section with those ideas in the overall issue description up at the top?

Can you please also add another task of also including ENSAdmin in our deployments to Render such that we can run separate versions of ENSAdmin in each blue / green environment without issue? Or do you suggest we create a totally separate GitHub issue for this goal?

We ran into an issue and complexity with this recently: https://namehash.slack.com/archives/C086Z6FNBHN/p1755018891404979?thread_ts=1755015996.447319&cid=C086Z6FNBHN

[BanaSeba]

@lightwalker-eth We probably should create a separate issue for ENSAdmin. It never existed previously in the Railway, and thus, I do not have enough expertise in quickly attaching it to those changes. I understand the problem we are facing when having a single ENSAdmin instance, but let's handle this migration in a separate scope.