What's preventing you from upgrading your plan?

The Bike Shed
,
1

:wave: from the Growth Team at Fly.io!

We’re a small, new-ish team here, and we’re focused on how to help you all expand your use of the platform. We think this expanded use helps you (who probably want to know about all the cool things you could be doing) and it helps Fly.io (more revenue means we can continue to pay our employees fair wages and build stuff we all care about).

One thing we believe on the growth team is: folks are more successful on the platform if they upgrade their plans, because our upgraded plans come with elements like email support and access to premium regions.

We’ve noticed that a whole lot of folks could, essentially, upgrade for free. That is, their org is on the Hobby plan, and is regularly spending more than $29/month in usage. That means they can upgrade to Launch and not pay anything extra.

So, we sent emails to some users who could upgrade “for free,” and made the suggestion in the dashboard. And, a very few folks did upgrade their orgs. But… not that many? We’re not exactly sure what’s going on. We have some thoughts, but we figured it might be best to just ask you directly! :thinking:

Can you share your thoughts with us about Fly.io’s plans? Here are some questions we’re thinking of, but we’d love to hear any thoughts you have!

  • How are you thinking about our plans? Do they make sense to you? Is there something weird or unexpected?
  • What might motivate you to upgrade (from Hobby → Launch, or Launch → Scale)?
  • If you’re on the Launch or Scale plan, when and why did you choose to upgrade?
  • If you’re on the hobby plan spending and $29+/month on usage, what’s preventing you from upgrading?
1 Like
2

There’s no reason to upgrade, and if I upgraded I’d be locked in at paying at least $29 a month.

I don’t need access to higher-demand regions, and the email support I’ve received from Fly in the past has been… less than stellar.

5 Likes
3

What do you think about directly upgrading those customers’ rights for the next month after exceeding their current plans’ spending limit? It could be a way to build their loyalty.

I like the pay-by-usage “plan” for my current use case. I don’t tend to pay.

I’m considering updating to contribute to the company because you are doing great work. I don’t tend to pay, as I usually don’t reach the $5 bill.

2 Likes
4

First, I want to mention that I truly appreciate the value of the Fly.io platform and understand that upgrading plans can provide access to more support and resources. I’m willing to upgrade my plan at the appropriate time to better utilize the platform’s features.

However, I find that the current pricing strategy on the Fly.io website is not very intuitive. As a Hobby plan user, it’s not clear to me whether my resource usage has exceeded the current plan’s limits and if I’m eligible for a free upgrade to the Launch plan. This information is not prominently displayed on the website.

I believe it would be incredibly helpful if the website clearly showed users their current resource usage and how it compares to their plan’s limits. When a user’s usage approaches or exceeds their current plan’s quota, a prominent notification could inform them that they can upgrade to a higher-tier plan at no additional cost. This would help users understand their needs and make informed decisions about upgrading.

Furthermore, I suggest explicitly stating on the pricing page that upgrading to a higher-tier plan will not incur additional charges within the plan’s limits. This can alleviate any concerns users may have about potential extra costs associated with upgrading, encouraging them to upgrade when appropriate.

Overall, I think Fly.io’s pricing plans themselves are reasonable, but there is room for improvement in the website’s design and communication of information. I hope this feedback is helpful, and I look forward to seeing Fly.io implement a more user-friendly pricing strategy and interface in the future.

2 Likes
5

I’m at a position where I’ve switched my go-to hosting option to fly, and my monthly will probably continue to increase and will end up in the bracket of people you are referring to.

Personally, the value of upgrading from hobby to launch doesn’t feel much, and very difficult to explain to my team. At the very least, currently I don’t feel this is an overall “upgrade”, rather, it just unlocks a few features, which I may or may not need. (direct email, and 2 regions of deployment if i understand correctly?)

For example, direct email support doesn’t feel like a direct upgrade. Community support has been fast enough, and had additional value of getting outside take on the issue. Even if i had direct email support line, I imagine the community post would still remain as my first point of contact.

1 Like
6

It would be a lot easier to understand if the docs said “minimum spend of $X per org” rather than the convoluted free resources + plan per org + free trial + whatever else. And if you’re doing a minimum spend of $X anyway, why would you need to subscribe to the plan? Include the features.

I upgraded at roughly $20-$25 spend for email support last year.

The support is polite, however, on several separate occasions I felt that I was doing blackbox debugging after running into some edge cases. The last one, periodically machines would stop running and they would not restart as there was binary data in /etc/hosts.

To have a service running fine for months and then break with no deploys is just disconcerting. I left one machine in a bad state for a few days at least, and no one went and looked at it. Problem kept happening and different machines would die. I had to time the fly scp command to be able to pull down the garbled file and send it to support…and I’m not sure if the issue has been fixed or even looked at.

Since the last unresolved ticket, I’ve had to prioritized a DR plan. Now that I’ve reflected about it, maybe I should be doing pay as you go. :rofl:

Another time, an issue got escalated and resolved on the community forums rather than thru email support…where I was in a discussion for a long time. So with a response time of 24-48 hours, I’m not what the benefit of email support is.

Anyway, I’m going to go look at those really nice grafana graphs of traffic being served from 9 regions rather than wonder if the infrastructure is going to be stable.

2 Likes
7

I’ve been experimenting with fly over some time. I like its capabilities, developer experience and the innovation I have seen in this time.

Broken use case

As you’ve grown, pricing has changed a number of times. As someone that began with an idea of how I wanted to use fly, its 6PNs and anycast, pricing changes have now broken my use case.

My goal was to manage one or more orgs per customer, using each orgs private network for absolute isolation for environments, access and cost control. I would run or expose solutions within these based on flycast and other features. Costs are easier rolled per org than to have multiple customers in a single org, and the way to segment apps within the same organization for isolation does not float my boat. Fly’s current networking uses the org id in routing requests and because it is structurally baked in, I require multiple orgs per customer.

As it currently stands, I would have a base cost of between $29 and $180 USD ($250 CAD) with up to 6 private networks per customer. It’s completely out of the question at this point.

Built in service pricing is weird and harmful: Fly’s value is infrastructure

Pricing is always a difficult issue, but imposing a minimum cost per organization equates to an infrastructure tax for email support. You ought be able to use an org for the services it provides, scale resources of an org to zero if need be, and know that you are not going to be eaten alive by a consumption tax to support another fly customer’s service requests. I do believe it is fair to charge for the storage of filesystems of stopped instances, that you are in the process of introducing.

On the way I wished to use fly, operating at least an organization per customer provides no more value for support for a single org.

Coming from just about any other cloud, support is pretty much non existent aside from billing.
Developers are generally expected to work with APIs and documentation supplied to generate solutions. I believe the role of Fly in this context is to ensure that docs are current and infrastructure doesn’t break this contract. Ultimately, Fly customers are coming from some other cloud to consume your services. The value of Fly is infrastructure.

An alternative: obtain service credits on demand at market pricing

For organizations that require hand holding, perhaps an alternative is to sell consulting hours on demand so people can obtain service credits. That way, you can automate booking and charge an appropriate rate for contact and speed of service. You would quickly come to a place where you understood how many hours are needed to service those requests. It would also have the effect of rooting out higher volume, low quality requests that tie up valuable technical resources just because people feel support is already baked into their account. You don’t need to be Heroku. Just be Fly and great at pushing on the infrastructure you’ve been building and work out the issues.

In that respect, I’ve seen more where an issue tracker is needed than service requests. It is often the case that several people have the same issue when a bug or behavior has been introduced. Email support and the community forum both suck compared to the visibility and transparency of issue tracking.

3 Likes
8

Are you aware of the ability to specify a network when you create an app? It potentially re-enables this use-case for you. There’s some info on it here. The corresponding flag in flyctl is fly apps create --network NETWORK_NAME. We don’t seem to have a lot of information on this feature, which I’ve raised internally - seems like it could be quite useful for a number of our users.

2 Likes
9

@jfrent, I don’t believe this addresses the issue. I rely on flycast to enable service exposure in another org. Each network must be accessible through wireguard and remain a functional VPN for management, and for identity and access control. Public tooling makes it simple to discover services within each org. It is not my desire to see apps or connectivity exposed that is not meant to be exposed. As an example of what can be accomplished with the approach I had planned and experimented with, a service can be connected to a proxy in one org, and the org the service is cast into will have no visibility of internal databases that I wish to protect. This is functionally analogous to a traditional DMZ which is the desired result.

2 Likes
10

Thank you all for for your thoughtful and insightful responses, I really appreciate them!

Some of these are not surprises for us (confusing pricing, for example :sweat_smile:), but there’s a lot of new interesting things to think about going forward.

11

This Does the unused ammount roll over? , I am curently paying for the hobby plan but looking into contacting billing regarding if I could have the organisation, but without the hobby plan and just do pay as you go.

12

Yah, I’m sure the discussion was organic and made sense to make small transitions and then you end up…who knows where. It happens to architecture all the time, but this is the first time I’ve seen it happen to pricing. Do you happen to have a bunch of architects in the room designing your pricing? :rofl:

I would suggest the following wording simplification:

  • there is a minimum $5 spend per org
  • there are some resources included for free
  • when you spend $X, Y is included.

Other alternatives:

  • minimum spend of $5 per org only if there is something deployed in the org. This is inline with what you have now, but with the deployment condition.
  • minimum spend of $5 per user only if there is something deployed in the personal org. Do not charge for multiple organizations. Also, a user could be part of multiple organizations, so why should they be charged for the personal org? I believe this still solves the fraud prevention problem and allows people to segregate projects per org, be a part of multiple orgs. I could go over the entire tree of cases and clean up the verbiage(and I think this could work nicely), but quite frankly, you’re not paying me enough for that. :rofl: