Skip to content
All tools
Tool

Calculate the cost of self-hosting shred delivery

Add transit, ingest infrastructure, servers, engineering, operations, and failure exposure on the same 30-day basis as a feed subscription.

Cash out the door

$506

Money that leaves the company.

People

$2,300

Real, but arguably already paid for.

Fully loaded

$2,806

Against $100 for one destination here.

Transit
$6
The cheapest line, and the one people assume dominates.
Hardware
$450
Ingest close to validators is the expensive half.
Ongoing engineering
$1,800
Shred formats change with the network. This never goes to zero.
Build, amortised
$500
Spread over how long you expect to keep running it.

Our own numbers, for symmetry. Serving one destination costs us roughly $12 to $17 a month against a $100 price. We publish that because a price this far below the market invites the question, and because the honest reason self-hosting rarely pays is not bandwidth, it is that somebody has to keep the ingest working every week forever. If you were going to run that infrastructure anyway for other reasons, the arithmetic changes and it may well favour you.

9 cost lines replace one server price

The self-hosting calculator compares a complete 30-day operating model with a subscription. It includes traffic, ingest servers, receiver servers, storage, monitoring, engineering, on-call work, amortized setup, and expected failure cost.

Subscription comparison starts with a $100 raw UDP destination lasting 30 days at one IP and port. Under stated transit and amortized-ingest assumptions, published marginal serving cost ranges from about $12 through $17. It does not claim a buyer can build independent ingestion for $17.

Method

Let V be monthly traffic in TB, T be transit cost per TB, H be engineering hours, R be loaded hourly rate, O be on-call hours, A be amortized setup per month, and F be expected failure cost. Fixed monthly infrastructure categories are I.

text

traffic_cost = V * Tlabor_cost = H * R + O * Rmonthly_cost = traffic_cost + sum(I) + labor_cost + A + F

Expected failure cost is probability times impact across named failure classes:

text

expected_failure_cost = sum(probability_i * impact_i)

The tool reports cash infrastructure, allocated labor, expected risk, and total separately. It also reports the break-even engineering hours against a subscription price:

text

break_even_hours = max(0, subscription_price - nonlabor_cost) / hourly_rate

That value is an arithmetic threshold, not a forecast of how much work self-hosting requires.

Example relay arithmetic

Suppose a reader supplies a traffic estimate of 20 TB over 30 days and a transit assumption of $0.40 per TB:

text

transit = 20 * 0.40 = $8.00amortised ingest = $5 to $10total = $13.00 to $18.00

This is the marginal serving view for one subscriber on an already operating relay. It excludes the customer's receiver and does not represent the cost to establish network position, develop ingestion, run an organization, or absorb all shared failure risk.

The service price minus that rounded range is not pure profit. Gross margin and complete company profit are different accounting levels. The product source publishes an 85 percent gross-margin figure under its defined model.

Worked self-hosting example

Assume a team estimates these hypothetical monthly inputs:

text

ingest server and network services = $300receiver and storage = $180monitoring = $70engineering = 8 hours * $120 = $960on-call allocation = 2 hours * $120 = $240setup amortisation = $100expected failure cost = $150traffic = 20 TB * $0.40 = $8.00

Total 30-day cost is $2,008. Cash infrastructure before labor and expected failure is $658 in this example. Labor is $1,200. The $100 setup allocation and $150 risk value complete the total.

These are user-entered example values, not claims about a particular cloud, engineer, or Solana network position. Replacing the hourly rate with zero because an employee is salaried would omit an opportunity cost. Replacing it with the employee's entire salary would overallocate work.

Define self-hosting scope

Three scopes are often mixed. Receiver self-hosting means operating the UDP consumer after a provider sends data. Relay self-hosting means maintaining an upstream feed and forwarding it. Independent network ingestion means obtaining and sustaining a position from which useful shreds arrive.

The $100 product already requires a customer receiver. A fair build-versus-buy comparison adds only costs that differ. If both options need the same decoder and storage, place those in a shared section rather than charging them to one side.

If a provider includes decoding, replay, several regions, or submission, its scope differs from raw delivery. Compare capabilities before totals.

Labor needs dated estimates

Separate initial implementation from recurring operations. Amortize setup over the expected useful period. Count upgrades, incident response, capacity review, security patches, key or credential work, and testing as recurring categories when applicable.

Use loaded hourly cost, not take-home pay. Loaded cost can include employer taxes, benefits, equipment, management, and overhead. The exact method depends on the organization, so the tool accepts the value rather than declaring one universal rate.

Record estimate owner and date. An integration that needed little work in a quiet month can require concentrated effort during a protocol or kernel change.

Failure cost needs a range

Some outages only delay research. Others miss trading opportunities or corrupt an index. Enter low, base, and high impact rather than one precise number. Keep revenue loss separate from speculative gross opportunity.

A raw UDP system can fail through upstream path loss, firewall changes, NIC drops, kernel overflow, application backlog, decoder changes, storage exhaustion, clock error, and missing monitoring. Redundancy changes probabilities and adds infrastructure.

Expected value does not describe worst-case tolerance. A rare loss can remain unacceptable under custody, oracle, or protocol duties even when its monthly expected dollar value is small.

Limitations

The calculator uses entered estimates and cannot price engineering quality, institutional knowledge, vendor support, contracts, regulatory duties, or strategic control. A team may self-host for research freedom even when arithmetic cost is higher.

Traffic volume is a user-supplied estimate, not a future maximum. Transit prices vary by provider and path. Ingress can be free while downstream services are metered.

Expected failure cost is especially uncertain and should remain visible as an assumption. The tool does not claim that subscribing removes receiver failures or that self-hosting guarantees independence.

Use sensitivity ranges. If the decision changes when engineering moves from four to six hours per month, the estimate needs better evidence before a long-term commitment.

How it works out the answer

Compute monthly_cost = traffic_TB × transit_rate + ingest_servers + receiver_servers + storage + monitoring + engineering_hours × loaded_hourly_rate + on_call_hours × loaded_hourly_rate + amortised_setup + expected_failure_cost. Show cash cost and labor cost separately. Model relay serving cost with user-supplied traffic, transit, and amortised-ingest inputs.

Questions

Why is the published $12 to $17 cost not a self-hosting quote?
That range is a marginal cost estimate for serving one destination from an already operating relay. Building and operating independent ingestion adds infrastructure, engineering, monitoring, failure exposure, and network-position work that the marginal figure does not include.
Should salaried engineering time be entered as zero?
No. Every salaried hour assigned here displaces another engineering task. Use a documented loaded hourly allocation for initial and recurring work. Avoid assigning an entire salary to the system. The calculator keeps hours and rate separate so reviewers can replace either assumption.
Does subscribing remove the need for receiver operations?
No. Subscribers operate their own destination machine, including its firewall, UDP socket, buffers, decoder, queues, monitoring, and reconciliation. A fair comparison charges this shared receiver work to both choices and isolates differences such as upstream ingestion and delivery operations.