The big pricing project: a chance to share an opinion

1

We launched with metered everything pricing, primarily because it makes it really easy to offer every feature to individual dev. Like “Custom SSL”, which certain CDNs like to charge thousands of dollars per month for.

However, pricing like this is very unpredictable and opaque. It causes a handful of surprise invoices each month. We don’t like surprise invoices!

To complicate this, we give people free credits every month, and it’s very non obvious when peoples’ usage exceeds their free credits.

And, our bandwidth is expensive. Everyone’s is, but that’s silly. We’ve managed to get our bandwidth costs down to the point where most apps shouldn’t need to pay for bandwidth usage. This is almost an entire topic by itself.

We’re going to update our pricing to solve all this. Before I tell you what we’re thinking, do you all use any services that have especially good pricing models?

Our current vague plan is to create fixed price tiers that include a bunch of bandwidth, SSL certificates, micro-1x/2x vm time, etc. This gives us a lot of room to play around, as an example we think a $10/mo plan might include:

  • Exec time for 5 micro-1x VMs
  • 100GB bandwidth
  • 20 certificates

It feels like people would be fine just paying 10 bucks per month to cover a handful of side projects, or one production project. And then when apps need hundreds of certificates the metered pricing goes up as they grow and is “predictable” in a good way.

Bonus Topic: free tier

We’re thinking about replacing the “free tier” with a $3/mo paid plan. We deal with an awful lot of abuse (torrent servers, attempts to send spam) from free tier users. The intent of the free tier is to make it easy to use Fly for side projects, development work, etc. All in the hopes that serious projects make enough money to cover those costs.

How would you feel about $3/mo instead of free?

3 Likes
2

$3 per month for the lowest tier is more than fair. Heck, I’m paying $5 a month to be able to just use Cloudflare Workers with KV.

I don’t know about others but I’d be totally fine with that during development considering all the features you offer (serverless docker, SSL API, multi-region, Redis, etc).

2 Likes
3

For me, that moves away from the “serverless” idea of pay-as-you-go which would be a shame.

Since as I see it, the fly niche is to fit between Lambda and a pay-monthly rival. The pricing of serverless (down to zero) but the speed of a pay-monthly server ie no cold starts.

As for bandwidth, totally agree cloud bandwidth is mad. All the big names seem to have settled on $0.08/GB. Even Cloudflare wants $0.08 for their new Workers offering.

As for abuse, could an idea be to limit the free tier’s capability? So like for free you only get port 80, 443. No SMTP, exotic ports etc.

1 Like
4

For small startups like mine, predictable pricing is a big bonus.

My favourite presentation for cloud pricing that I’ve found so far has been Firebase. I think they’ve managed to find a good way to offer discoverability of monthly costs for both small projects and apps at scale, esp. how they preset the various calculator sliders to the max value that would still keep you in the free tier. https://firebase.google.com/pricing#blaze-calculator

Google Cloud (and others) also has a useful “budget alert” system which can notify you when the actual costs you’ve incurred are approaching a budget amount you’ve set.

As far as free plans go, I think you should get rid of it. I would 100% be happy with paying $3 per month to spin up and test out a small project. A low-priced plan with usage limitations geared towards small apps would be perfect, and when I hit those ceilings I might have a better idea what upgrading to a “pay-as-you-go” plan might cost me per month. Personally, I might also want to use this low-priced plan for staging and QA environments, and know that my costs aren’t going to run away from me for some unknown reason.

To summarize these ideas:

  • one “low-priced” plan with capped usage
  • one “pay-as-you-go” plan without caps, and perhaps a “budget” feature

Edit: For the low-price plan I’d be disappointed if the feature set were different from the pay-as-you-go plan; (reducing the effectiveness in using it for staging/QA environments)

2 Likes
5

What if it saved you money? I think most people using us would spend less money with some reasonable plans, and then be able to pay as you go beyond them.

6

Oh yes, we’re strongly in favor of giving all the features to people. If we ever get to the point where we only have “Enterprise” features, they’ll like be things specifically for big orgs that individual devs won’t care about.

7

Unless I’m missing something you’d still pay-as-you-go once you went over the limits of your base plan. $10 is a pretty low ceiling.

8

BTW @kurt do you have a bandwidth pricing in mind once an account went over those 100GB?

I’m building a blogging platform of sorts with Fly and that is critical for me. Bandwidth will be probably 90% of my infrastructure cost.

9

Let’s get the free tier out, and I think $5 a month for the “free” stuff is good.

The way I approach pricing checks depends on one major factor — whether the project is a cost center or a profit center.

Type 1 is a cost center, it means my Fly bill increasing is a problem. Things like free blogs, social media sites pre-revenue, side projects, free / portfolio apps etc. For these I want worry-free pricing thats fixed, like the digital ocean single droplet @ $5/mo or Heroku hobby dyno @ $7/mo. I know exactly what I’m paying, and there’s some reasonable bandwidth allocation that I don’t care about too much. Bill shock is a problem here, but I’m never going to get billed more than $5 or $7 so I’m fine. Temporary usage spikes (front page HN for a blog) are absorbed and do not increase my bill, while service still continues, but if I hit high usage everyday I expect a call from sales and an increased bill after a long period of sustained overage.

The $5 “free” tier is actually fine for this, let me just pay that and get something like 3 micro-1xs, or one micro-2x and one micro-1x, with each 1x unit giving me 100GB a month or something included. If I have a lot of side projects I’d like to buy two of these “packs”. But we do need sidecars… I’d like to fit nginx, app server and pgbouncer (3 containers) on the same micro 1x or 2x.

Type 2 is the profit center services or APIs, where I’m charging customers or doing business with what I deploy on Fly. Here I want unlimited access on any dimension with no limits and per-dimension charges, because if I get a $10,000 Fly bill it means I sold $100,000 worth of API calls. Here I want clear pricing, with volume tiers, on every aspect, CPU, RAM, bandwidth, all separate. I need them separate so I can project my cost of goods sold on an excel sheet and figure out my profit margins. Vague and hand-wavy “we’ll do the right thing” or “reasonable” limits are horrible here, because they throw off all my calculations. With clear tiered pricing I can also measure optimizations correctly, because adding optimizations will give me immediate and measurable financial returns.

I don’t know if Fly will do a dual mode for pricing, but if I had to choose only one mode I’d choose the Type 2. But Type 1 is much more attractive for my blog / side projects, for which I currently use Netlify or Heroku. If Fly wants more Type 1 projects in, some kind of dual mode would be necessary, like AWS did with Lightsail. But we know that Fly’s internal metrics are all Type 2, and businesses and business-minded developers making a profit of the deployed services will want Type 2.

2 Likes
10

I guess that’s the balance: most people appreciate pay-as-you-go is always going to cost more when you do use it, but the balance is it costs nothing when you don’t. Like I have a phone on PAYG. If I make no calls or texts, costs nothing. When I do, each call/text costs more than it would if I was on a contract. That’s the trade-off. Personally I’d like the choice. Like DynamoDB. They actually went the other way: started with reserved pricing and then added a “serverless” pricing model.

11

Funny, I was just looking for info on pricing on my plan and didn’t see any in my dashboard!

For my use case here’s what I need:

  • Ability to scale well with surges in traffic, with a strong expectation that on non-peak hours that my pricing will go way down
  • Knowledge of pricing. Right now I have no idea what I’m going to pay come month’s end. I want some sort of prediction based on my usage.

What would be cool:

  • Set alerts when I go over certain projected limits
  • Set alerts when I hit billing thresholds
  • Get estimates when I add new instances, telling me what my new bill will be with plan changes.

I absolutely love Fly.io for the ability to run a scalable service near my users. Frankly, it would be a major pain in the ass to use anyone else.

PS. If there’s any way to see my estimated bill as of today I’d like to know.

1 Like
12

We’re working on that. For a blog platform, we’re hoping it’s not the biggest part of your cost.

It’s complicated because bandwidth in Sydney costs us a lot. Bandwidth in the US and Europe, not very much.

1 Like
13

Hosting and serving images ain’t cheap yo!

In all seriousness, I’m only serving HTML from Fly. But still, if I could I’d like to reduce my costs even further.

14

This does seem broadly appealing. There has been some unpredictability to my bandwidth costs with Fly. They’ve not been unreasonable or enough to complain, but if you had asked me my top “complaint” recently, I’d probably have said it was the bandwidth costs / the unpredictability of the bandwidth costs. Rational or not, I didn’t internalize that bandwidth costs are effectively priced in for other providers.

I do think having a free tier is wonderful, but I obviously can’t weight that against the volume of abuse and distraction that generates for you. I don’t envy you guys for having to deal with it. $3 / mo is better than $5 / mo, so :man_shrugging:.

One other thing to consider, and I’m sure this would be at least somewhat game-able, could you still offer the free tier to .edu users? While that doesn’t apply to me, it seems like it could allow you some of the upside of the free tier (allowing for tinkering) while at least limiting the scope of possible abuse by a bit.

15

Has there been a decision made on the pricing? I’m working out customer pricing for a new project I’m deploying on Fly, would be useful to know the rough plan so I can project expenses / profit-loss.

16

Not yet! There will definitely be cheaper bandwidth somehow, but we’re still figuring out how exactly to do that.

2 Likes
17

This is a very rough draft Hobby plan we’re considering. This (or something like it) will replace the free plan.

We are pricing it relatively high but introducing a discount program (you’ll all get the discount if you want it) to keep it cheap.

This includes a new instance type we’re just calling micro. These are shared CPU, 512MB RAM instances that are comparable to Heroku hobby dynos. They work exceptionally well in swarms. :smiley:

Hobby Plan

  • 3000 hours of micro VM time. Enough to run 4 micro VMs continuously (shared CPU, 512MB RAM)
  • 300GB outbound bandwidth
  • 1 anycast ipv4 address
  • 10 SSL certificates
  • Community support
  • $19/mo ($3/mo after discounts)

Bandwidth structure prices are changing when we roll this out. There is a quirk to our infrastructure, we pay bandwidth between all our machines. Which means people will frequently double up on bandwidth when traffic moves between VMs or between VMs and our load balancer.

Bandwidth overages should cost:

  • $0.02/GB in North America and Europe
  • $0.04/GB in Asia, Australia, South America
  • $0.12/GB in India (we’re working on getting this one cheaper)

This is a working draft plan so we’re happy to answer questions and really appreciate feedback.

2 Likes
18

The new bandwidth pricing is great!

Do you get discounts when you go over say 50TB?

This is like running a micro VM in 4 regions, right?

19

So … 3,000 hours of micro VM. Is that 12,000 hours of a 128mb? Does it scale like that? So e.g 4 apps: 3,000 hours of a 128mb each.

Also, can that one IPv4 be used across multiple apps? I assume when using the name.fly.dev CNAMEs, behind the scenes that same IP is used for them all, rather than have a new one per app as now?

20

Yep! That’s it. I typo’ed and put 3.