Pricing Update · Nov 2022 · Request for feedback

Hello Robertmx, Service Grouping and Read-Only accounts (both anticipated in early 2023) would definitely be options you can use to manage the costs associated with a use case like the one you’re describing.

These changes feel like they fundamentally misalign the value that I’m getting as a consumer and the price that I’m paying. I feel good paying you more when I get more value, whether that be additional bandwidth, compute, storage, etc. Those are also things that cost you money, and that’s easy to understand. It’s also easy to understand that you add value on top of the hard resources that you provide with the feature set covered above. I expect that I’ll pay more per unit of each of those resources to cover your development costs and need for profit.

However, charging me based on the number of team members feels arbitrary. What do I get for that? My service doesn’t consume more bandwidth just because there’s a second person on the team. Maybe that second person results in more builds, maybe they don’t. Paying for those additional build hours makes sense, so charge me for them. The additional team member just amounts to a row in a table though, which is why it feels arbitrary. Similarly, why do I have to buy a 100GB block of bandwidth? Again, arbitrary. The whole market has moved to consumption-based pricing, and this feels like a move in the opposite direction.

8 Likes

i am deploy my website backend on render when i am testing website its stop working and not gives any response …i don’t know why its stop working…please help me for solve my problem…
thanks

I’d reiterate what many others said here. Charging extra for shared account / team functionality is a big mistake. As a freelancer I use shared accounts with my clients to give them account ownership and privacy with their billing information. Charging extra for this seems like a mistake and would make force me to look elsewhere unfortunately.

Could the ability to share accounts be separated from the other paid “Team Plan” features like extra bandwidth, build hours, etc?

4 Likes

There aren’t many reasons to not go with heroku at this price point. Heroku teams are free <= 5 users. Would you consider matching this?

6 Likes

In the billing section of your dashboard https://dashboard.render.com/billing and then under the plan name it should show build hours for you

Yikes. This is, quite frankly, an awful change. You’ve gone from competitive to prohibitively expensive for small teams. We will now have to start thinking about migrating to fly or railway

6 Likes

Honestly, I don’t enjoy these changes and I would prefer if you just increased prices of products that stopped being profitable for you. I’m mostly annoyed by the fact that I spent more than a full workday setting up pull request previews and now I’ll have to pay additional $19 per month to be able to continue using them (as otherwise I’m well within Individual plan limits).

2 Likes

Pull request previews for a single server are still available on the Individual plan. Only full stack Preview Environments are moving to the Team plan and above.

The team option is a brutal change. I suggest that the first 3 seats in teams should be included in the $20.

I’m moving from heroku but I’m seriously considering going back there, because they include 5 seats.

4 Likes

Yeah this is rough. Agree on including some free seats to reduce the burden on early stage startups. At the very least pricing should remain competitive with Heroku who includes 5 seats.

4 Likes

Besides what the others in this thread have already said, I am surprised to see that for a GDPR DPA you have to have an Organization or Enterprise plan. That means basically each of your EU customers has to pay 29$/user/month to comply with the law.
GDPR DPA should be available for all plans, or at the very least beginning with the Team plan.

3 Likes

I have a small project that is not in development, and I just needed multiple people to have access, and this is no longer a use-case for me I think I will be migrating of of it

3 Likes

We’ve been using Render for two years and have mostly been happy with it. This change will likely lead us to start all new projects on more competitive alternatives that don’t have this arbitrary pricing model.

In our usage we usually create accounts for our clients, but agree to maintain it for them, which means their services do not have any active development for months or years. Most our team members are passive, and many are just backups in case a request comes in and the first contact person is on vacation. This change easily triples or quadruples the monthly invoice for many of our clients as it is now and we just have to remove access from everyone and start juggling with access whenever a sporadic troubleshooting request comes in.

I’ll stop recommending Render for this same reason. Pricing based on single database rows, when those extra users are completely passive 99 or 100% of the time seems completely arbitrary.

8 Likes

So, was there enough feedback? Are we still expecting this racket to appear on our bill at the end of the month?

Clearly this is an immensely unpopular decision- this platform positioned itself under a much different guise and this feels like you are taking advantage of those who trusted you. You presented yourself as a platform for small devs with great pricing tiers, and loads of people moved over for those reasons. Paying for resources AND users is not something even the major players have ever implemented (GCS, AWS etc.)- because in this context it doesn’t make any sense. I hope the feedback here makes you reconsider this extremely misguided decision.

2 Likes

I just realized that I can’t make a private project on render, since I have setup render with my work email for my workplace and connected my github account and render doesn’t allow to connect a github account to multiple render accounts (see this feature request from 2020).

That means for me to start a project that is not connected to my work, I would have to make a team in my work account, to somewhat separete them and therefore pay 19$/month (again). So I have to pay arbitrary amounts of money for arbitrary reasons, to be able to put a project where it doesn’t even belong in the first place because I can’t put it anywhere else.

Also this pricing changes mean that small/indie devs are paying for the bigger companies on here. Please reconsider this changes and use a pricing model that is bound to the actual usage of resources.

1 Like

Charging $19 for ‘a team’ is ridiculously high by itself, let alone per team member.

Render used to be a great recommendation, but not anymore.

If we have to pay 57 bucks per month for our 3 team members (of which only 1 is actually active), we’ll be gone, we will stop recommending Render to our partners and remove the integrations from our site and github.


Might want to tell the C-level folks that greed is not the best way forward, or show them this thread if they really care.

Reminder: this is from Heroku, the platform you so eagerly like to compare yourself against as a ‘better alternative’ :face_holding_back_tears:

Free for 1-5 users, then it’s just $10 per month for up to 25 users.

1 Like

Same here, Heroku is interesting again for any professional team.

I’m not seeing that when I view their pricing page. It looks like $25+ for a production app. Then a database starts at $43 per month on top of that? Heroku has always seemed a ridiculously expensive option for entrepreneurs who launch a lot of projects.

I’m talking about the team price specifically, check here: Team collaboration platform | Heroku Teams | Heroku

Paying costs for services that you’re actually running, fine - compete with that.

Almost 20 bucks for a record in the database is just nuts.