Sorry you are right. I mean repair and infrastructure costs are missing.
How much difference in costs is S3 vs native?
That one I don’t know. Especially not after all the recent cost reductions.
It seems like people thinking S3 is a significant part of costs. I do not but I might be wrong.
if it selfhosted now, then it is fix expenses for connection and electricity.
But if it on provider server, then traffic cost money.
Really? I see plenty of unlimited traffic server offers. 
I think the discussion has now clarified several points on which there is more agreement than disagreement:
- Storj has not generated enough paying demand.
- Price matters, but it is not the only adoption barrier.
- Central infrastructure and operating costs must be reduced.
- “Free egress” is not actually free; it is a pricing and packaging decision.
- The actual cost difference between hosted S3 access and native access is currently unknown to us.
- Neither my proposed $12 customer price nor GreenGrinch’s proposed $3.50 price has been validated by the market.
The remaining disagreement is about what conclusions can legitimately be drawn from those facts.
GreenGrinch’s latest calculation does not support a node payout reduction
You originally argued for “drastic price cuts for nodes.”
Your latest model proposes paying nodes approximately $1.59–$1.60 per physical TB-month.
The current storage rate discussed throughout this thread is $1.50 per physical TB-month.
Your proposal is therefore not a drastic SNO reduction. It is an increase of approximately 6–7%.
Using your own assumed expansion factor of 2.2:
- At $1.60 per physical TB, node storage costs are $3.52 per logical customer TB.
- At a customer price of $3.50, Storj loses $0.02 before paying any other expense.
- At $1.59 per physical TB, node storage costs are $3.498.
- That leaves $0.002 per logical TB-month.
I am using the 2.2 factor here only to evaluate your own calculation. Whether that is the correct current effective expansion factor is a separate question that should be answered with actual Storj data.
As @littleskunk correctly clarified, your calculation still excludes repair and infrastructure costs.
It also excludes, among other things:
- metadata infrastructure;
- audits and reputation management;
- repair coordination;
- billing and payment processing;
- customer account management;
- abuse handling;
- security operations;
- support;
- and development and maintenance.
Your model therefore does not demonstrate that Storj can sustainably charge $3.50.
It demonstrates that $3.50 produces approximately zero or negative storage margin before the network is operated.
That is especially important for a backup-focused service. Backup customers may store data for years and rarely restore it. Recurring storage infrastructure cannot safely depend on frequent egress revenue from customers whose objective is to avoid needing a restore.
We do not know that S3 costs $5 per TB
@alpharabbit asked the important question:
How much difference in costs is S3 vs native?
The honest answer from the discussion was that we do not currently know, particularly after the recent cost reductions.
That means we should not proceed immediately from:
Hosted S3 traffic creates additional cost
to:
S3 costs approximately $5 per TB and must be abolished.
Those are not equivalent statements.
There are three different components that should not be mixed together:
-
The hosted S3 gateway
Customer data passes through infrastructure operated for the gateway. This can create bandwidth, compute and operational expense.
-
Native Uplink or a customer-operated gateway
Data can travel directly between the client and storage nodes. That can move gateway compute and bandwidth away from Storj’s centrally hosted infrastructure.
-
The Satellite
Native access does not remove the Satellite. The Satellite still handles metadata, authorization, node selection, reputation, audits, repair, accounting, billing and SNO payments.
Removing Storj-hosted S3 gateway traffic may reduce one category of expense.
It does not eliminate Satellite infrastructure, repair, billing or network operation.
S3 compatibility can also be retained through customer-operated gateways, local sidecars or integrations that use Native Uplink internally. Therefore, the choice is not limited to:
- operate every S3 request through an expensive central gateway; or
- remove S3 compatibility entirely.
That would be another false dilemma.
@alpharabbit’s observation about servers with included or unmetered traffic further demonstrates why no universal $5-per-TB assumption should be treated as established fact. The relevant numbers depend on Storj’s actual hosting contracts, locations, port capacity, traffic patterns and infrastructure design.
Before making an architectural decision, Storj should publish:
| Required figure | Question |
|---|---|
| Hosted S3 gateway fixed cost | What does the gateway fleet cost per month before traffic? |
| Hosted S3 variable cost | What additional cost is created per TB uploaded and downloaded? |
| Native Uplink cost | What central cost remains per TB using direct node communication? |
| Satellite cost | Which costs are fixed and which scale with objects, segments, requests or data? |
| Repair cost | What is the actual repair expense per logical TB-month? |
| Effective expansion | What is the current production expansion factor by workload and placement? |
Until those figures exist, neither “S3 is insignificant” nor “S3 must be removed” has been demonstrated.
Open source does not make operating costs zero
I agree that open source can reduce some costs.
It can:
- allow outside contributions;
- avoid proprietary licensing;
- enable customer-operated components;
- reduce dependence on one development organization;
- and potentially create a community-maintained product.
But it does not automatically make most costs zero.
Someone still has to operate or fund:
- production databases;
- network services;
- monitoring;
- security response;
- software releases;
- code review;
- repair systems;
- accounting;
- customer billing;
- node payments;
- legal compliance;
- support;
- and incident response.
Even volunteers need an operational model. Customer data cannot be maintained through the assumption that a qualified person will always volunteer at the necessary moment.
Your proposed reciprocal community backup network may nevertheless be an interesting idea:
- native protocol;
- community-operated Satellites;
- reciprocal storage;
- possibly a separate token or accounting mechanism;
- low-cost backup rather than general-purpose object storage.
But that would be a new community network.
It would not automatically:
- continue existing Storj customer contracts;
- preserve current customer data and access;
- resolve the Chapter 11 claims;
- repay or refinance the DIP;
- satisfy tax and creditor obligations;
- or provide commercial accountability.
It should therefore be evaluated as a separate fork or successor project, not presented as evidence that the operating costs of the existing Storj service can simply be reduced to zero.
The lack of customers does not prove that price was the only cause
I agree with your central criticism that years of talking about georedundancy, security and performance did not produce sufficient paying demand.
Storj is in Chapter 11. Whatever marketing story existed was not commercially successful enough.
But that does not establish that the customer price was the only cause.
You yourself identify one of the largest problems:
There is no proper native Synology or TrueNAS implementation.
That is precisely the integration problem discussed throughout this thread.
A customer comparing Storj with Backblaze does not compare only:
- $3.50 versus $7.
The customer also compares:
- whether the application already supports it;
- whether setup takes five minutes or several hours;
- whether Docker, Rclone or custom scripts are required;
- whether migration is automated;
- whether restore is simple;
- whether support documentation works;
- and whether the provider appears likely to remain available.
Your proposed solution removes the widely supported S3 interface and then assumes customers will adopt a Storj-specific native workflow because the price is 50% lower.
That may work for a technically capable niche.
It has not been shown to work for a mass market.
A lower price does not automatically compensate for a more difficult product.
This is why the more realistic initial target discussed in the thread is not “all cloud storage users.” It is secondary backup, disaster recovery and replicated data, introduced through one or two validated integrations and paying design partners.
The first product should be tested before a broad portfolio is built.
Possible initial channels include:
- NAS backup;
- server and virtualization backup;
- hosting and MSP backup;
- or another workload for which Storj is initially not the customer’s only copy.
If customers will not purchase even a simple, properly integrated backup product at a positive contribution margin, then we have learned that the proposed market does not work.
But removing compatibility, setting an arbitrary 50% discount and assigning virtually no revenue to network operations is not a market test.
Free egress does not require one compulsory tariff
@Pentium100 is correct that a provider can include egress in the storage price.
The delivery company still gets paid when a shop advertises “free shipping.” The cost is simply recovered elsewhere.
@littleskunk and @Vadim are also correct that compulsory bundled egress can be unfair:
- low-egress customers subsidize high-egress customers;
- high-egress customers may become unprofitable;
- and the provider gains an incentive to avoid customers who use the allowance fully.
The practical answer is optional packaging.
Storj could offer both:
Pay as you go
- storage billed separately;
- egress billed separately;
- customers pay for actual consumption.
Backup bundle
- higher storage price;
- limited restore allowance included;
- additional egress billed separately.
For backup, an annual restore allowance may make more sense than a monthly allowance. For example, a plan could include one full logical restore per year rather than one full egress multiple every month.
Customers who value strict usage pricing can keep it.
Customers who fear an unpredictable restore bill can choose a bundle.
In either case, node egress must still be paid. “Free egress” changes the customer invoice, not the underlying cost.
What the discussion has actually established
We should not pretend that my proposed $12 price has already been accepted by the market.
It has not.
It is a restructuring scenario that must be tested against customer cohorts, contracts, churn and contribution margins.
But your proposed $3.50 price has an additional problem: it fails its own unit economics before the test begins.
Under your assumptions it leaves approximately zero or negative storage margin, excludes repair and infrastructure, and proposes a node rate slightly above the current rate while simultaneously arguing that node compensation must be cut drastically.
The next useful step is therefore not another petrol-station analogy.
It is actual data:
- What does each access method really cost?
- What is the current effective expansion factor?
- What do repairs cost?
- Which customer cohorts currently generate positive contribution margin?
- Which customers choose Storj, and why?
- What customer price produces sustainable demand after integration friction is removed?
- What SNO compensation retains the required occupied capacity and operator diversity?
Until those numbers are available, several strategies remain hypotheses.
But one conclusion already follows from your own table:
A $3.50 customer storage price that allocates essentially all storage revenue to node storage is not a sustainable operating model for Storj.
It is not evidence that SNO compensation should be reduced.
It is evidence that the selected customer price is too low.
It varies quite a bit in my case, but I also use servers where traffic is charged separately — Servitro, for example. One TB is included, and every additional TB costs $1, regardless of whether it is upload or download traffic. If Storj does not compensate me for these additional traffic costs, I have to throttle the bandwidth significantly, even before the included 1 TB has been used up.
They are usualy on 1-4 cores VPS servers, have you seen free traffic on Dedicated server?
I also run some nodes on dedicated servers. Servdiscount/WIIT is one example: traffic is limited after a certain amount has been used, and you have to explicitly pay to have the bandwidth restriction removed.
Velohost is even stricter: they do not merely throttle the connection; they shut down the entire server once the traffic limit is exceeded.
Hetzner usualy want money for every TB over 20 spended.
Adding to this that removing S3 will limit eaxctly this type of customer acceptance.
The potential customers have a working backup solution via S3. Now a Chapter 11 company asks them to be their second backup but to be able to be used they first have to implement some arbitrary code to their applications to handle that.
The answer I can imagine. So no, S3 guarantees that company can switch to Storj as additional provider by changing the S3 gateway address.
I would not remove that.
Exactly. Removing S3 would undermine the very market segment that appears most realistic for Storj.
Companies looking for a secondary backup, disaster-recovery target or additional replicated copy usually already have software that supports S3. In many cases, testing Storj could be as simple as adding another S3 endpoint and changing a few configuration values.
If Storj instead required them to integrate a proprietary protocol, deploy additional software or modify their applications, the adoption barrier would increase dramatically. That would be especially difficult for a company currently in Chapter 11, because potential customers will already be more cautious about investing engineering time into a provider-specific integration.
S3 compatibility allows customers to test Storj with limited commitment and retain the ability to switch providers later. That portability is not merely a technical feature; it reduces the perceived business risk of adopting Storj.
The centrally hosted S3 gateway may need to be operated more efficiently or redesigned to reduce its infrastructure costs, as much as possible. Native Uplink and self-hosted gateways may also be useful alternatives. But removing S3 compatibility itself would make customer acquisition harder precisely where Storj has the clearest potential use case.
So I agree: I would not remove it. Just to clarify what I originally meant in the passage you quoted: I was arguing for a narrower initial customer segment, not for removing S3.
My point was that Storj should first focus on secondary backups, disaster recovery and replicated data instead of trying to compete for every possible cloud-storage workload at once. For exactly those use cases, S3 compatibility is likely essential because it allows companies to test Storj with their existing backup software and without developing a Storj-specific integration.
So yes, removing S3 would work against the strategy I was proposing.
Yes, but there is always some kind of limit tbh. If the traffic is “unmetered” the (virtual) nic speed is the limit.
What about asking the big customers, which maybe are running their own servers anyway, to run a private S3 gateway. This could reduce at least some of traffic.
I think Storj are already Selfhosted it, so they dont pay anymore for traffic.
There is no such thing as a free lunch 
But seriously, 5$ per TB traffic is pretty much the norm.
That one is not entirely true.
We had S3 & 7$ per TB = no customers
So what makes you think that 12$ = customers?
Do you think some users get attracted by a higher price and chapter 11?
I would argue your 12$ have been validated by the market and it was a big NO.
IMHO we have tried your 12$, by trying an even better number that is 7$. It did not work. But we have not given 3.5$ a try.
Fair point, and I agree. The thing is, these calculations were all based on a very generous assumption: that 3.5$ is a sexy deal. It could also be that the price needs to sink to 2$ or even 1$. Than the payout needs to be smaller. Imagine that 2$ is the sexy price that attracts customers and storj needs 1$ for the satellite that keeps track of where what is stored (without S3). That would bring down the profit 1$, which devided by 2.2 would mean that a node would get 45cents per TB.
Your putting the chart before the horse, again and again.
It does not matter what “is sustainable for Storj”. I don’t care how much it costs my gas station to get gas or how much they pay for employees, or how much they pay for electricity.
S3 is 7$ per TB.
Hetzner storage box (smb, sftp, borgbackup, restic, rclone, webdav, ssh) is 4.4$ per month. And that is probably the better comparison.
What else was the problem if not pricing?
Nope. That is not gonna fly. There always was a S3 option for free. So that can’t be the reason that we don’t have customers. It has to be something else. Make a guess.
Currect. Probably 50% isn’t even enough. Make it 50% of a hetzner storage box with way more features. So 2.2$. Yeah, that sounds like a good deal for a customer.
Correct again.
Just because you selfhost it, does not mean you don’t pay for traffic. Peering is not free. Never has been, never will be. A small 10 GBit/s connection to DE-CIX is 400$ a month. Somebody has to foot that bill, no matter if you are in a colocation or rent a VPS.
And that’s the fundamental problem, or one of them.
Storj was built on the assumption that customers would use the native uplink. The whole “decentralized and end-to-end encrypted” part relies on the customer using the native uplink and connecting directly to nodes.
S3 was the temporary measure, which was expensive to host, but, you know, temporary, until a customer figured out how to use the native protocol.
It turned out that customers do not want the native protocol, they just want S3, even though they lose both the decentralization (uploading/downloading from multiple nodes at the same time) and end-to-end encryption (of course you can encrypt the data separately, but encryption was one of the advertised features).
So the whole network turns from the “decentralized, we use lots of node operators with home connections that are cheaper to achieve fast speeds and cheaper hard drives” into “all data goes through our expensive servers” with only the storage part still on nodes. I wonder if it would not be cheaper for Storj to just buy servers and host the data itself (using standard RAID and such with lower expansion).
As there is no additional charge to use S3 (even a small one like $0.1/TB or even $0.01/TB), customers have no incentive to switch, they just continue to use the temporary solution, which is easier.
What RAID? US1 expansion factor is 1.4 atm…
Is it 54/29?