A Follow-up on the New Minimum Usage Fee – and a Request for Feedback

Announcements
1

Dear Storj Community,

Thank you for the thoughtful feedback you’ve shared over the past 24 hours. While we anticipated that some users—particularly smaller ones—might be frustrated, we clearly underestimated the depth and breadth of concern across the community, especially among our node operators. You’ve helped us understand that the frustration centers around the following areas:

  1. Insufficient notice – Many users felt the notice period was too short, especially given the complexity of closing an account. Some also misunderstood the timeline, believing they had only 1–2 days to take action. To clarify: the $5 minimum monthly usage fee will go into effect on July 1, and will first appear on August invoices.
  2. Lack of early engagement – Several of you expressed that this change was introduced without enough advance discussion or transparency. We understand that community input is critical, especially for changes that impact usage and trust.
  3. No STORJ token exemption – Many long-time supporters who transact using STORJ tokens have requested an exemption. We recognize that these users have contributed meaningfully to the ecosystem from the beginning.

We want to explain more openly where we are as a company, why we made this change, and what we’re doing to improve it.

Also, given the feedback we’ve received, we are actively considering two changes:

  • Extending the implementation period to 60 days
  • Introducing a reduced $0.50 minimum monthly usage fee for users who pay in STORJ tokens

We welcome your feedback on this proposal and want to work with the community to find the best path forward.

Why We Introduced a Minimum Usage Fee

Storj began nearly a decade ago, fueled by a vision of creating a decentralized, community-powered alternative to traditional cloud storage. That vision was brought to life by thousands of contributors and early believers through the launch of the STORJ token. Because of you, this project didn’t just survive—it evolved into a high-performance, enterprise-grade platform that real businesses now depend on.

This is a huge success. In order to make sure we can continue to provide these services in the long-term, we need to make sure it’s economically sustainable. While we are working toward profitability, we are facing challenges in balancing costs across all customer segments, especially our smaller customers. These adjustments will help on our way toward becoming profitable, allowing us to independently fund the business, and also remove any reliance on the Storj token to fund business operations.

We’re not in crisis, but we are being more disciplined. We are actively raising capital in today’s market, which—thankfully—is more open to businesses like ours than it has been in recent years. However, that scrutiny also forces us to make tough but necessary changes that position us for long-term sustainability.

These include:

  • Ending the free tier and introducing a free trial
  • Cleaning up dormant and abusive frozen accounts
  • And now, the introduction of a minimum monthly usage fee, which is intended to ensure that every account using our infrastructure contributes at least a baseline amount toward maintaining it.

Why Small Accounts Aren’t Economically Sustainable

Let’s share the data:

  • Roughly 80% of paying customers currently pay less than $5/month
  • These customers account for less than 5% of the data stored on the network
  • They generate less than 2% of total revenue
  • Yet they cost us much more than what we earn from them—even before accounting for any people-related costs like customer support or finance operations

In short: these users aren’t just unprofitable, they are materially dragging on the business.

One thing that might not be fully appreciated is that the money we pay to SNOs is only about half of what it costs us to support product usage.

Beyond storage and bandwidth payouts, we incur substantial infrastructure costs to store customer data:

  • Satellites, which maintain metadata, coordinate uploads and downloads, manage repairs, and handle deletions—essentially the brain of the network generate meaningful costs
  • The S3 gateway, which is essential for usability and adoption, is also costly to maintain and scale
  • Operational services around account provisioning, API usage, billing, logging, and more all add cost.

These are not just theoretical costs—there’s a reason Amazon charges for API operations and metadata requests. Each of these actions consumes compute and storage resources. And for small accounts, the operational cost per GB stored is significantly higher than for large accounts, simply because the overhead is spread over such a small footprint.

Without sufficient scale per account, even a few gigabytes of data stored can generate a loss once satellite operations, API calls, and gateway maintenance are factored in.
For one specific example we have a customer that is storing about 100 GB of data and paying us about $0.70 per month but costing us almost $160 every month. This customer is not an outlier but is demonstrative of what we see with very small customers.

Outside of infrastructure costs there are also many less obvious costs. And we see that small customers account for an outsized portion of these, including credit card transaction fees, account abuse mitigation and management, keeping malware and illegal content out of linkshare, free trial abuse, credit card fraud etc.

It is a combination of these factors which has led us to the decision to require small accounts to pay a minimum fee.

A Strategy That Didn’t Pan Out

Related to this decision is a pivot in strategy. As a company, we invested heavily in the idea that we could grow through mass consumer or at least technical consumer adoption: offering low-cost or free access to individuals who would fall in love with the platform, use it for personal projects, and then introduce it to their employers, colleagues, and friends.

Unfortunately, this hypothesis has not borne out.

Despite years of investment in this strategy, we do not have a single demonstrable case where this pathway led to a meaningful, long-term customer. So while we remain committed to being developer-friendly, we are also being honest with ourselves about what’s working and what’s not.

This is why we are pivoting the platform more squarely toward direct B2B adoption, where we are seeing significant traction. But in doing so, we moved too quickly. We should have carved out an exception for those paying in STORJ—people who helped fund and build this platform, and who remain some of our strongest supporters.

Moving Forward—Together

One final point of reassurance: we are not abandoning the public network in favor of the select network. The public network remains central to our vision and operations. Many of our B2B customers do not have the strict compliance constraints of certain enterprises and are extremely satisfied with the performance, security, and decentralization of the public network. In fact, many of these customers are storing tens of petabytes of data on the public network today and using it for mission-critical enterprise workloads. We are also in the early stages of onboarding another meaningful multi-petabyte customer, which we expect will grow the total data stored in a measurable, meaningful, and noticeable way. This is a sign of the public network’s maturity and strength—and our commitment to continue building on it.

We understand the decision to change to a minimum monthly fee has been upsetting—especially to those who have supported us from the beginning, or who help run the network as SNOs. We also understand that change is hard, particularly when it comes without enough notice or explanation.

We hope this post helps fill in the gaps and opens the door for better dialogue moving forward.

Again, we are seriously considering the following adjustments based on your feedback:

  • 60-day implementation period
  • $0.50 minimum for users paying with STORJ

We welcome your thoughts, your ideas, and your criticisms. We are listening, and we are learning. Thank you for being part of this journey.

UPDATE:
Based on the feedback from the community we have decided to move forward with two adjustments

  1. Go forward with the 60 day implementation period instead of 30
  2. We will be completely removing the minimum fee for users paying in STORJ. This of course will not address many of the issues discussed in the post above but we want to do this as a commitment to the community and those who have supported this project.

Official communication about these changes will be coming in the next day or two via email to account holders.

—The Storj Team

26 Likes
2

Is your 100GB customer doing something common that many users do? Is he cycling out the 100GB daily? This is obviously an area of concern, and as you mentioned “not an outlier”. I would be curious to know if these customers are using a common toolset for backup, and if they are unknowingly, inefficiently, committing redundant changes causing unnecessary load.

As a customer that funds the account with STORJ, I would stay, and will easily be able to find 125GB to backup to maintain my account. In fact, I have an efficient ZFS dataset now from proxmox backup server at 170GB with over 11x data de-dupe factor. That’s almost 2TB of storage saved, and I would only need to commit small changes every week.

As an example, with this use-case, would i be one of your excessively demanding common users that cost you significantly more than I pay?

8 Likes
3

It’s understandable to find sustainable ways to operate, especially especially when facing the nuanced operational costs of numerous small accounts. As a “small” customer myself, who’s always minded my own business and never needed support, the new minimum usage fee feels a bit like collateral damage. I’ve been a long time user, since the early days, as a SNO and user.

The concern here isn’t just about the fee itself, but the signal it sends for me. For those of us who have quietly used the service without ever drawing on support or other resource costs, this change feels like a blanket measure that impacts everyone to address a specific issue. It inadvertently penalizes low-impact users alongside those who might be generating higher transactional or operational costs.

Perhaps there could be more nuanced approaches. If the core issue is indeed the cost of these small, frequent operations, then strategies like per-request or per-operation fees (per million or some amount) – could be more targeted solutions. This way, the users who truly incur higher overhead, even with low data volume, would contribute directly to those costs, rather than spreading the burden across all small accounts.

In my opinion, this update still broadly disincentivizes loyal, low-maintenance users. Just my two cents, but it feels like there’s a win-win solution out there that supports both the business and its quiet, consistent users.

7 Likes
4
  • $0.50 minimum for users paying with STORJ
    I’m on board with this change. As a long time SNO, I felt like like $5 minimum to me as a SNO was a gut punch. This exception for those of us who pay with STORJ token is a welcome change to this new policy.
8 Likes
5

The 50c minimum fee is fair. I have never had to contact Storj and my usage is only increasing, especially egress.

I was shocked initially to see the $5 because on all the storj townhalls, we’re told how revenue is increasing so quickly.

5 Likes
6

You have a serious billing issue, an issue that alienating 80% of you user base (even if they only make up 5% of your revenue [or are costing you money]) will not fix.

10 Likes
7

Can you please elaborate on this?

If the customer is uploading millions of small files and instantly deleting them – yes, they will be putting a massive load on the system and paying nothing – but that’s the risk you are taking not charging for api calls, ingress traffic, etc.

@Bryanm, Is this a typo, and did you mean they are an outlier? Or not an outlier?

In the formet case – yes, you will have some outliers with any pricing policy other than charging for everyting, like amazon. But even amazon does not charge for ingress, so even they can have customers stressing the system without paying; that’s fine, pricing must work on most users, but not necessarily every user.

In the latter case – it’s a problem that needs to be fixed. How can users wiht 100GB cost $160? Please elaboarate. And if that’s the case – how will $5 help?!

So, you are saying processing credit card transactions for under $5 cost you $4.50 !? I don’t beleive you. Find better processing company.

If you are indeed paying 35 cents per credit card transaction, and such a “discount” is to encourage use of storj tokens – why not turn that $.50 zero? It’s almost zero anyway.

Remember amazon experience where they say massive changes in customer behaviour between 1 cent shipping vs free shipping. Customers are irrational.

And lastly, small customers who are sensitive to price will just switch to paying with tokens, and continue stressing your system just the same. Nobody will be paying $5. So… the whole ordeal is pointless? It now becomes: Small customers, start using tokens, or we punish you. Large customers, you are good.

9 Likes
8

What!? We really need elaboration on this. This demonstrates a severe issue in how costs are calculated. If AWS charges for API calls, maybe you should too; just be cheaper than AWS

4 Likes
9

$160 - $0.70 - $5 = $154.30 loss

This means that about 30 other customers who pay $5 each have to subsidize this one special customer.

$0.50 do not help in any way and it is just another bad signal that can be interpreted as greed.

The minimum charge could even bring an additional effect: This $0.70 customer who has to pay $5.00 could start (ab)using the service even more excessively to get his money’s worth.

This would then “require” a minimum fee for token-only accounts as well.

2 Likes
10

Actually we don’t know (yet) what this customer is using in such an excessive way.
But yes, maybe separate plans are needed. Like personal accounts with limitations and fair use policy and pro accounts with monthly payment and surge payment for excessive resource usage (whatever resource that is).

11

It turns out that I use Storj instead of something like cloudflare R2 because using Storj allows me to learn a bit of crypto knowledge, and the storage fees are very cheap, so it can be used as a backup.

But $5 per mon is just so expansive for me, I will return storj if I have such large data, but now it’s time to close my account for a while.

4 Likes
12

Hopefully they tell us :joy:

13

No I mean we as community. I am sure Storj knows but haven’t told us (yet).

15

Sorry, my mistake, I thought you were the OP. It’s late and I’m tired.

3 Likes
16

I appreciate the request for customer feedback and the willingness to make some changes based on that feedback, though I’m very disappointed by the minimum usage fee and am in the process of preparing to close my small(ish) account.

I store a few hundred gigabytes of a combination of “cold” archival data (mostly for redundancy for critical data stored on another provider) and a few “hot” backups. I very much like Storj due to the geographical distribution of nodes (which beats putting all my “eggs” in a single geographical “basket” with other providers) and the relatively low cost of storage. I spend a few dollars a month, generally under $5/month.

I understand that small users can impose costs disproportionate to their stored data charges, but ideally the pricing structure should account for that. Several competitors charge for API usage to ensure that users can’t abuse the service by causing unbilled costs. I know of at least one that charges two different costs for differing classes of API calls depending on the resources consumed by that class of query. That would be a very reasonable thing for Storj to do.

Other competitors charge for a minimum amount of data stored (e.g. they charge for a minimum of 90 days of storage even if the file is stored for less than 90 days). (Personally, I’d prefer if Storj didn’t do this, as my backup software “thins” out archives over time (e.g. hourly backups for a few days, daily backups for two weeks, weekly backups for two weeks, etc.) and this involves periodic deletions of data that would still be charged for, but I’m mentioning it simply for the sake of completeness.))

Other non-storage providers offer various tiers of support. For example, a “baseline” user gets support in the forum which fellow customers and support staff read. If an issue involves something private (like billing information), the support staff will send the customer a private message to assist. Customers can also pay $5/month for individual, direct support from staff to offset the cost of providing that service. Paying customers who rarely contact support get priority responses over “frequent fliers”. This seems like it’d be a good fit for Storj.

Passing along credit card processing fees for users (either for all users, or for those below a certain limit) seems reasonable to me. An extra $0.35 + 2% or whatever isn’t terrible.

In short, there’s several options Storj could implement to minimize the ability of small users to impose unbilled costs, and to offset any unavoidable costs.

As a small albeit low-cost (at least I hope so) user, I’d much prefer options that directly address the high-cost behavior rather than throwing the baby out with the bathwater.

Edit: I didn’t name the other companies I described so as not to appear to be shilling or advertising for them, but am happy to provide links privately if requested. I have no affiliation with any such company other than being a paying customer.

6 Likes
17

A similar idea was hinted in the past:

This is something that could be forbidden by the provider. E.g. Paypal has a policy that a vendor must not pass the transaction cost to buyers.
However what some do to circumvent that is to declare those cost as arbitrary payment gateway usage ( :joy:) and make the buyer pay the full charge anyway. Not nice but ok…
But as I understand the OP it is not just about payment processing charges, it is the overall costs that small customers are accounting for and that they don’t bear their share.

1 Like
18

Minimum 50 Cent with Storj Token is an great idea.

Maybe an Idea is also that SNOs can convert sone payout into Storage also.

2 Likes
19

Well, you should have started with this. Now we understand the situation.

4 Likes
20

Frankly this is very scary. Imagine Storj had 100 customers like that.
Storj needs to move such a customer to a different tier where they pay according to their excessive resource consumption. Alternatively Storj has to boot such a customer.

Isn’t it ironic that your decision might force small customers, who don’t incur significant costs, to leave the Storj platform in fury, while customers with abusive usage patterns get to stay and happily pay a nominal $5, which barely covers a fraction of the costs they generate? I think it should be the other way around.

10 Likes
21

Somewhat tangetially relevant anecdote from Backblaze’s Reddit AMA blogpost, I’ll just leave it here (not posting link, it’s easiry searchable):

We currently have one customer backing up 430 terabytes for $6 a month. At that price, we are clearly losing money on that customer. However, most of our customers have much less data. So, while we are losing money on that one customer, we are profitable on average. There are other reasons to support the outliers — those customers demonstrate that we are truly unlimited. No service that was throttling or selectively backing up files would enable 430 TB to get backed up. Yes, that ends up being a business cost, but those outlier customers become big evangelists as well. You don’t get that much data without being somewhat of a storage enthusiast. Our CTO, Brian, brought up another great reason: when the product works for the really big outliers, then “it will work really smoothly for the average customer.”

Whether to boot “abusers” or let them use the service within agree-upon terms is somethign Storj needs to decide, but these types of factors may or may not carry significant weight.

4 Likes