System Requirements and Infrastructure Options

Official XRPL documentation provides requirements, but understanding why each requirement exists helps you make informed decisions when requirements conflict with budget.

Official Requirement: 8+ cores @ 3+ GHz (x86_64)

Why This Matters:

rippled CPU Usage:

- Cryptographic signature verification
- Transaction rule validation
- State computation
- Each transaction requires CPU cycles

- Processing proposals from other validators
- Computing agreement percentages
- Building candidate transaction sets
- Time-sensitive operations

- Computing state changes
- Managing ledger database
- Serving API requests (if enabled)

- 3,000+ transactions per ledger possible
- Each requires validation in <4 seconds
- Parallel processing essential
- Slow CPU = missed consensus rounds

Practical Implications:

• 4 cores @ 3+ GHz

• Will work during normal operation

• May struggle during volume spikes

• Risk of falling behind network

• 8+ cores @ 3+ GHz

• Headroom for volume spikes

• Comfortable consensus participation

• Room for growth

• 16+ cores @ 3.5+ GHz

• Significant headroom

• Suitable for additional services

• Future-proofed

CPU Architecture Note: XRPL requires x86_64 architecture. ARM processors (like AWS Graviton or Apple Silicon) are not officially supported for production validators. While rippled can be compiled for ARM, production validators should use x86_64 for reliability.

Official Requirement: 64 GB RAM recommended (32 GB minimum)

Why This Matters:

rippled Memory Usage:

- Recent ledger versions in memory
- Enables fast state lookups
- Grows with ledger complexity
- Currently ~20-30 GB typical

- Pending transaction queue
- Validation buffers
- Consensus data structures
- ~2-4 GB typical

- Linux kernel and processes
- Monitoring agents
- Logging infrastructure
- ~2-4 GB typical

Total typical usage: 25-40 GB

- Headroom for usage spikes
- Room for OS disk caching
- Buffer against memory pressure
- Avoids swap usage (kills performance)

Practical Implications:

• Tight fit for current usage

• No headroom for spikes

• May require swap (bad for performance)

• Acceptable for testnet/non-critical

• Comfortable for current operation

• Headroom for growth

• Avoids memory pressure

• Production appropriate

• Significant headroom

• Enables aggressive caching

• Room for additional services

• Future-proofed for years

Critical Warning: If rippled exhausts memory and hits swap, performance degrades dramatically. Validators using swap will fall behind consensus and miss validation rounds. Size memory to never touch swap under normal operation.

Official Requirement: NVMe SSD, 50+ GB for database partition

Why This Matters:

rippled Storage Usage:

- RocksDB or NuDB backend
- Stores ledger state and history
- Size depends on history retention
- ~30-50 GB for minimal history

- rippled.cfg and related files
- Log files (can grow quickly)
- ~5-20 GB typical

- Compilation (if building from source)
- Crash dumps (if enabled)
- OS operations
- ~10-20 GB buffer

Storage Performance Critical:

Why NVMe specifically:

- rippled requires sustained high IOPS
- 10,000+ IOPS for smooth operation
- Database writes on every ledger close
- Random read/write pattern

- Sub-millisecond access needed
- Each ledger closes in 3-5 seconds
- Storage latency directly impacts validation
- HDD latency = consensus failure

What this rules out:
✗ Traditional HDDs (too slow)
✗ AWS EBS (latency too high)
✗ Network-attached storage (latency)
✗ Most cloud "SSD" tiers (actually EBS)

What works:
✓ Local NVMe SSD
✓ Instance store (ephemeral but fast)
✓ Direct-attached NVMe

AWS EBS Warning: The official XRPL documentation explicitly states: "Do not use Amazon Elastic Block Store (AWS EBS) because its latency is too high to sync reliably." This is a common mistake—AWS instances with EBS storage will struggle to maintain synchronization.

Official Requirement: Enterprise data center network, gigabit interface

Why This Matters:

rippled Network Usage:

- Connects to 10-50+ peers
- Continuous data exchange
- Transaction propagation
- Validation message distribution

- Typical: 5-20 Mbps sustained
- Peaks: 50-100 Mbps during volume spikes
- Monthly: 1-5 TB typical

- Validation messages are time-sensitive
- High latency = late votes
- Late votes = reduced agreement percentage
- Target: <100ms to major network hubs

Network Considerations:

• Minimum: 100 Mbps dedicated

• Recommended: 1 Gbps

• Metered bandwidth can get expensive

• Unmetered preferred if available

• To other validators matters

• Geographic location affects this

• Major hubs: US East, EU West, Asia

• Measure before committing

• Network downtime = validator downtime

• Redundant connectivity valuable

• BGP/multiple upstream preferred

• SLA matters for production

Component       | Minimum      | Recommended   | High-Performance
----------------|--------------|---------------|------------------
CPU             | 4 cores 3GHz | 8 cores 3GHz  | 16 cores 3.5GHz
RAM             | 32 GB        | 64 GB         | 128 GB
Storage         | 50 GB NVMe   | 100 GB NVMe   | 200 GB NVMe
Network         | 100 Mbps     | 1 Gbps        | 1 Gbps redundant
IOPS            | 5,000        | 10,000+       | 20,000+

Note: Minimum specs risk performance issues.
Recommended specs provide comfortable operation.
High-performance provides significant headroom.
```

Cloud infrastructure offers flexibility and managed hardware, but costs more than bare metal over time. Here's how major providers compare for validator operation.

Relevant Instance Types:

• 8 vCPUs @ 4.0 GHz (high frequency)

• 64 GB RAM

• 300 GB NVMe instance store

• Enhanced networking

• Compute: ~$0.744/hour = ~$535/month

• Must use instance store (not EBS)

• Data transfer: ~$50-100/month

• Total: ~$585-635/month

• 16 vCPUs @ 3.6 GHz

• 32 GB RAM (minimum spec)

• 400 GB NVMe instance store

• Compute: ~$0.768/hour = ~$553/month

• Data transfer: ~$50-100/month

• Total: ~$600-650/month

AWS Considerations:

Advantages:
✓ High-frequency CPU options
✓ Global presence (many regions)
✓ Excellent network connectivity
✓ Instance store provides local NVMe
✓ Enterprise support available

Disadvantages:
✗ Most expensive option
✗ EBS not suitable (latency)
✗ Instance store is ephemeral
✗ Complex pricing model
✗ Data transfer costs add up

Critical: Must use instance store, not EBS.
Instance store data is lost on stop/terminate.
Requires careful operational procedures.

Verdict: AWS works well but is expensive. Best for organizations already on AWS or requiring specific compliance certifications.

Relevant Options:

• AMD Ryzen 9 5950X (16 cores @ 3.4GHz)

• 128 GB DDR4 RAM

• 2 × 1.92 TB NVMe SSD

• 1 Gbps unmetered

• Base: €89/month (~$97/month)

• Setup: €0 (during promotions)

• Additional IPs if needed: €1/month each

• Total: ~$100-120/month

• AMD Ryzen 7 3700X (8 cores @ 3.6GHz)

• 64 GB DDR4 RAM

• 2 × 1 TB NVMe SSD

• 1 Gbps unmetered

• Base: €61/month (~$67/month)

• Total: ~$70-90/month

Hetzner Considerations:

Advantages:
✓ Exceptional price/performance
✓ Unmetered bandwidth
✓ Real dedicated hardware
✓ Local NVMe storage
✓ European data centers
✓ Good network connectivity

Disadvantages:
✗ Limited geographic presence (EU, US)
✗ Less enterprise support
✗ Longer provisioning times
✗ Hardware responsibility is yours
✗ No managed services

Best for: Cost-conscious operators who can
manage their own hardware. Excellent value.

Verdict: Hetzner offers the best price/performance ratio. Recommended for operators comfortable with server administration.

Relevant Options:

• 8 dedicated vCPUs

• 64 GB RAM

• 200 GB NVMe SSD

• 7 TB transfer

• Base: $504/month

• Additional storage: $0.10/GB/month

• Bandwidth overage: $0.01/GB

• Total: ~$510-560/month

• 8 vCPUs (shared)

• 32 GB RAM

• 100 GB SSD

• 6 TB transfer

• Base: $168/month

• Warning: Shared CPU may not sustain load

DigitalOcean Considerations:

Advantages:
✓ Simple, predictable pricing
✓ Good developer experience
✓ Reasonable network connectivity
✓ Multiple regions globally
✓ Managed databases, monitoring available

Disadvantages:
✗ Premium droplets are expensive
✗ Standard droplets have shared CPU
✗ Storage is network-attached (latency)
✗ Less raw performance than Hetzner
✗ Bandwidth limits can be reached

Best for: Developers familiar with DO
who value simplicity over cost optimization.

Verdict: DigitalOcean works but offers less value than Hetzner. Acceptable if you're already invested in their ecosystem.

Relevant Options:

• Intel Xeon E-2386G (6 cores @ 3.5GHz)

• 32 GB DDR4 RAM

• 2 × 512 GB NVMe SSD

• 500 Mbps unmetered

• Base: $90/month

• Total: ~$90-110/month

• Intel Xeon E-2388G (8 cores @ 3.2GHz)

• 64 GB DDR4 RAM

• 2 × 512 GB NVMe SSD

• 1 Gbps unmetered

• Base: $130/month

• Total: ~$130-150/month

OVH Considerations:

Advantages:
✓ Good price/performance
✓ Multiple global locations
✓ Unmetered bandwidth
✓ Real dedicated hardware
✓ DDoS protection included

Disadvantages:
✗ Mixed reputation for support
✗ Occasional availability issues
✗ Control panel can be confusing
✗ Provisioning can take days
✗ Fire incident history (2021)

Best for: Budget-conscious operators
wanting geographic diversity (OVH has
data centers in locations others don't).

Verdict: OVH offers good value with broader geographic options than Hetzner. Quality of experience varies.

Provider      | Monthly Cost | Performance | Ease of Use | Best For
--------------|--------------|-------------|-------------|------------------
AWS           | $550-650     | Excellent   | Good        | Enterprise, compliance
Hetzner       | $70-120      | Excellent   | Moderate    | Best value
DigitalOcean  | $500-560     | Good        | Excellent   | Developer familiarity  
OVH           | $90-150      | Good        | Moderate    | Geographic diversity

For organizations with existing data center relationships or long-term commitment, owning hardware can make economic sense.

Owned Hardware Costs:

• Dell PowerEdge R650 or similar

• Dual Xeon Silver (16+ cores total)

• 64-128 GB RAM

• 2 × 1 TB NVMe

• Redundant power supplies

• Cost: $4,000-8,000

• $4,000 server: $111/month

• $8,000 server: $222/month

• 1U space: $50-150/month

• Power: $30-100/month

• Bandwidth: $50-200/month

• Colocation total: $130-450/month

• Low end: $111 + $130 = $241/month

• High end: $222 + $450 = $672/month

• Hetzner: $100/month (managed for you)

• AWS: $600/month (managed for you)

Break-Even Analysis:

• Hetzner: $100/month = $3,600 over 3 years

• Owned (low): $241/month = $8,676 over 3 years

• Owned (high): $672/month = $24,192 over 3 years

• Result: Hetzner wins unless you have free colo

• AWS: $600/month = $21,600 over 3 years

• Owned (low): $241/month = $8,676 over 3 years

• Result: Owned wins if you can manage hardware

• Budget cloud (Hetzner) beats owned for most

• Owned beats premium cloud (AWS) on cost

• Owned adds operational complexity

Good reasons to own hardware:
✓ Existing data center with spare capacity
✓ Free/subsidized colocation (university, etc.)
✓ Specific compliance requirements
✓ Already have hardware team
✓ Running multiple validators/nodes
✓ Want full hardware control

Good reasons to avoid owned hardware:
✓ No existing infrastructure relationship
✓ No hardware management experience
✓ Single validator operation
✓ Want to start quickly
✓ Value operational simplicity
```

Some operators use hybrid approaches:

• Primary: Owned hardware in colo

• Backup: Cloud instance (cold standby)

• Switch to backup if primary fails

• Cloud cost only when needed

• Primary: Hetzner EU (cost-effective)

• Secondary: OVH US or Asia

• Provides both cost savings and diversity

• Production: Dedicated hardware

• Testnet: Budget cloud instance

• Reduces risk during testing

Where you place your validator matters for network latency, jurisdictional diversity, and regulatory considerations.

Validator effectiveness depends on timely communication:

- Consensus rounds are time-bounded
- Late votes may not be counted
- High latency = lower agreement percentage
- Lower agreement = reduced trust

- US East Coast (Virginia, New York)
- Western Europe (Germany, Netherlands, UK)
- Asia Pacific (Singapore, Tokyo)

- <50ms: Excellent
- 50-100ms: Good
- 100-150ms: Acceptable
- >150ms: May impact agreement

- Ping major XRPL public servers
- Check latency from potential locations
- Consider round-trip to multiple regions

Network health benefits from jurisdictional diversity:

- Many validators in US jurisdiction
- Significant presence in EU
- Growing presence in Asia
- Limited presence elsewhere

- Protects against single-jurisdiction action
- Different legal frameworks
- Different regulatory environments
- Distributed political risk

- Switzerland (regulatory clarity)
- Singapore (crypto-friendly)
- Japan (established crypto law)
- UAE (emerging hub)
- Less common jurisdictions add value

Decision factors (ranked):

1. Network connectivity quality

1. Latency to major hubs

1. Provider availability

1. Jurisdictional considerations

1. Cost

---

Production validators benefit from redundancy, though it adds complexity and cost.

Note: Active-active (multiple validators) is NOT
recommended—you should have ONE validator identity,
potentially with failover to backup infrastructure.
```

Budget-Conscious Operator:
Provider: Hetzner AX52 or AX102
Specs: 8-16 cores, 64-128 GB RAM, NVMe
Cost: $70-100/month
Location: Germany (FSN1 or HEL1)
Notes: Excellent value, requires server admin skills

Enterprise Operator:
Provider: AWS z1d.2xlarge
Specs: 8 vCPUs @ 4GHz, 64 GB RAM, NVMe instance store
Cost: $600-650/month
Location: US East (us-east-1)
Notes: Premium performance, familiar for AWS shops

Geographic Diversity Focus:
Provider: OVH Advance-2
Specs: 8 cores, 64 GB RAM, NVMe
Cost: $130-150/month
Location: Choose underserved region
Notes: Good for adding diversity value

Development/Learning:
Provider: Hetzner Cloud or DigitalOcean
Specs: 4-8 vCPUs, 16-32 GB RAM
Cost: $50-100/month
Location: Any
Notes: For testnet operation, not production
```

Common infrastructure mistakes:

✗ Using minimum specs for production
  Results in performance issues under load

✗ Using AWS EBS for storage
  Latency too high—officially unsupported

✗ Choosing location only on cost
  Poor connectivity defeats cost savings

✗ No consideration for bandwidth costs
  Metered bandwidth can surprise you

✗ Planning for 1 year when committing for 3+
  Infrastructure decisions are long-term

✗ Not testing before committing
  Always verify connectivity/performance first

✅ Official requirements are minimums, not recommendations - Production validators need headroom above documented minimums for reliable operation

✅ Storage latency is critical - AWS EBS and similar network-attached storage cause synchronization problems; local NVMe is essential

✅ Significant cost variation exists - Factor of 5-6× between Hetzner and AWS for equivalent specifications

✅ Geographic location affects validator effectiveness - Latency to network impacts agreement percentage and therefore reputation

⚠️ Future resource requirements - XRPL growth could increase CPU, memory, or storage needs

⚠️ Provider pricing stability - Cloud pricing changes; today's value leader may not be tomorrow's

⚠️ Optimal redundancy level - Depends on your specific availability requirements and budget

⚠️ Best geographic locations - Network topology evolves as validators join/leave

📌 Under-speccing to save money - Short-term savings create long-term performance problems

📌 Single point of failure without recovery plan - Hardware fails; having no plan means extended outages

📌 Choosing unfamiliar provider for minor savings - Operational comfort has value; provider expertise matters

📌 Ignoring bandwidth costs - Metered bandwidth at scale can significantly increase costs

For most operators, Hetzner dedicated servers offer the best value with excellent price/performance, adequate specifications, and good connectivity. The 5-6× cost difference compared to AWS is significant over a multi-year operation.

However, infrastructure choice should match your operational capabilities. If you're uncomfortable managing a dedicated server and your organization uses AWS, paying more for familiar infrastructure may be worthwhile. The best infrastructure is the one you can reliably operate.

Assignment: Create a complete infrastructure specification for your validator deployment.

Requirements:

• Selected provider and specific configuration

• Rationale for selection (cost, capability, familiarity)

• Alternative considered and why rejected

• Provider account setup status

• CPU specification with justification

• RAM specification with justification

• Storage specification with justification

• Network requirements and expected bandwidth

• Selected location/region

• Latency testing results (ping to s1.ripple.com, s2.ripple.com)

• Jurisdictional considerations if applicable

• Diversity value provided (if any)

• Monthly infrastructure cost breakdown

• Annual cost projection

• 3-year total cost projection

• Comparison to at least one alternative provider

• Current redundancy level (likely 0)

• Target redundancy level for Year 2

• Estimated additional cost for redundancy

• Failover procedure outline (even if manual)

• Timeline for infrastructure provisioning

• Account setup steps

• Expected provisioning time

• Verification steps before proceeding

• Appropriate specification for production operation (25%)

• Thorough cost analysis including alternatives (25%)

• Geographic and latency consideration (20%)

• Realistic redundancy planning (15%)

• Complete procurement plan (15%)

Time investment: 2-3 hours
Value: This document specifies exactly what you'll deploy and serves as reference for provisioning in Lesson 3

1. Hardware Requirements (Tests Technical Understanding):

Why does XRPL documentation explicitly warn against using AWS EBS for validator storage?

A) EBS is too expensive compared to alternatives
B) EBS network latency is too high for reliable ledger synchronization
C) EBS doesn't support the file formats rippled requires
D) EBS has insufficient storage capacity for ledger data

Correct Answer: B
Explanation: AWS EBS is network-attached storage with latency measured in milliseconds. rippled requires sustained high IOPS with sub-millisecond latency for database operations during consensus. EBS latency causes validators to fall behind the network and struggle to maintain synchronization. The documentation explicitly states: "Do not use Amazon Elastic Block Store (AWS EBS) because its latency is too high to sync reliably."

2. Cost Analysis (Tests Quantitative Reasoning):

A startup is choosing between Hetzner ($100/month) and AWS ($600/month) for a 3-year validator operation. Assuming equivalent reliability, what's the total cost difference over the deployment period?

A) $6,000
B) $12,000
C) $18,000
D) $21,600

Correct Answer: C
Explanation: Monthly difference: $600 - $100 = $500. Over 3 years (36 months): $500 × 36 = $18,000. This substantial difference makes provider selection a significant cost decision. However, "equivalent reliability" is an assumption—if your team is already expert in AWS, the operational risk of switching may partially justify the premium.

3. Geographic Considerations (Tests Practical Knowledge):

A validator operator is considering a data center in South America because "nobody has validators there." What's the most important factor they should verify before committing?

A) Whether the data center accepts cryptocurrency payments
B) Latency to major XRPL network hubs (US East, EU West, Asia)
C) The local regulatory environment for cryptocurrency
D) Whether the provider offers DDoS protection

Correct Answer: B
Explanation: While geographic diversity has value, network connectivity matters more. A validator with >150ms latency to all major network hubs will have lower agreement percentages because validation messages arrive late. Before choosing any location for diversity reasons, verify that latency to major hubs is acceptable (<150ms, preferably <100ms). Poor connectivity defeats the diversity benefit.

4. Specification Decisions (Tests Critical Thinking):

An operator asks whether they should use 32 GB RAM (minimum spec) to save money. What's the best guidance?

A) 32 GB is fine—official documentation lists it as acceptable
B) 32 GB works but leaves no headroom; 64 GB recommended to avoid memory pressure affecting performance
C) 32 GB is insufficient—rippled won't run with less than 64 GB
D) RAM doesn't significantly impact validator performance

Correct Answer: B
Explanation: 32 GB is the documented minimum, and rippled will run. However, typical memory usage is 25-40 GB, leaving minimal headroom at 32 GB. Under memory pressure, Linux may use swap, which dramatically degrades performance. At 64 GB, you have comfortable headroom for usage spikes and OS caching. The ~$20-40/month difference between 32 GB and 64 GB configurations is worthwhile insurance against performance issues.

5. Redundancy Planning (Tests Operational Judgment):

A new validator operator with a limited budget asks about redundancy. What's the most appropriate advice?

A) Redundancy is essential from day one—don't launch without it
B) Start without redundancy (Level 0), focus on primary reliability, and add redundancy as operation matures
C) Redundancy is only needed for UNL validators—non-UNL validators don't need it
D) Use active-active redundancy with two validators sharing the same identity

Correct Answer: B
Explanation: For new operators, starting with a single well-configured server (Level 0) is acceptable. Resources are better spent ensuring primary reliability than splitting attention across redundant infrastructure. As operations mature and UNL consideration becomes relevant, adding redundancy (Level 1-2) demonstrates professional operation. Active-active with shared identity is NOT recommended—you should have ONE validator, potentially with failover infrastructure.

For Next Lesson:
With your infrastructure specification complete, Lesson 3 will cover operating system setup and hardening. Provision your server (or at least create your provider account) before proceeding—we'll be working with a live system.

End of Lesson 2

Total words: ~5,600
Estimated completion time: 55 minutes reading + 2-3 hours for deliverable exercise