The big pricing project: a chance to share an opinion

@greg I edited to clarify, that’s 3000 hours of the new micro type (like the old one, but with more RAM). Enough to run 4 VMs full time. 4 apps, a little over 730 hours of VM time each.

IPv4 are assigned to apps right now, we don’t have shared IPv4 yet. New IP addresses will likely be <$4/mo each, sharing one just means running nginx or haproxy on one IP and routing to other apps IPv6 right now.

Ah, ok.

Does the only-billed-during-a-connection still apply, so that is 730 hours of being-used time?

Not entirely clear how the new IPv4 plan affects things when using CNAMEs, if at all, rather than A records. If I make 8 apps, app1.fly.dev to app8.fly.dev, and CNAME using a custom domain to each, does that change anything from now?

VMs are only billed during “alive” time. When you use auto scaling, it will add and remove them (down to a minimum of 1) which roughly works like billing while connections are alive.

Extra micro VMs will cost approximately $3.15 per month.

Right now, when you create an app you get a dedicated IPv4 address. Your 8 apps would have 8 IPs unless you removed them (using flyctl ips). We’ve held off on billing for IPs until we get shared IP support going, though, we’ll probably keep doing that. They cost us money to use but we don’t ever expect to make much profit from them. :slight_smile:

Ah, so the costs do add up then, if I understand that correctly.

As I previously mentioned, personally I like the “serverless” style mainly because test apps etc can sit idle at night and so are free. Zero usage. Zero cost. Whether a pay-per-request Lambda-style, or a drop-to-zero CloudRun-style). Yet apps actually in use are paid for. Rightly :slight_smile:

It sounds like without manual intervention (suspend, delete app or whatever each morning and again each evening) each one costs first, $3.15 a month for the VM, then another $4 for the IP (maybe, since not entirely clear still whether an app can get by without an IPv4 by using the CNAME).

$7.15 is fine. But then you multiply that by say a staging and production app, and by say five little apps rather than one monolith app … and it adds up. When they all may get zero traffic. That $70 or whatever could cover 50 million requests with that pesky rival company and $0 with 0 requests.

I get you want to stop the people who abuse the free service, like sending a billion log lines though. Hmm.

We have been surprised how many of our users want VMs that run forever, and even more than their actual capacity requires. We’d like to make the product better for bursty apps but it’ll be a while, right now it feels like we should build something as valuable as we can and then optimize for cheap.

I understand. For me the attraction was it being serverless without the cold starts or keep-warm hackery. Since a VM was there but only paid for when connected to. That was the definition of active. Unless I imagined that :slight_smile: Rather than pay for a VM that is idle.

This has been a problem! The only way to avoid cold starts entirely is to keep server resources dedicated to VMs. Turns out, if you keep a VM alive people find clever ways to make them keep working even if they’re not “active”.

We have some ideas on how to handle this but it’s a lot of development work that keeps seeming less important. We’re better off just trying to make things as cheap as possible for everyone (hence, 4 VMs full time for $3/mo). We’re also completely open to suggestions on how to make hobby work economical. I do think attracting hobby/side projects is important for marketing and awareness.

1 Like

Makes sense. I guess it’s similar to how people figured out that you could use keep-warm Lambda requests. And so AWS launched a paid product to keep a Lambda warm to extract that money. And round we go.

If it’s 4 VMs for $3, that is quite a bit less than $19 for hobby projects. Especially if they don’t need an IPv4. Wasn’t quite clear on how the ‘with discounts’ bit worked.

I’m guessing the with discounts is pure self selected price differentiation? Customers who don’t care about money will pay full rate, and customers who care enough to ask / cut coupons / actively participate in the forum (hint, hint) will get the discounted rate? There’s no feature differences, right?

Oh that’s good to know, and part of why we’re floating this stuff here! Discounts will get you down to $3/mo. We’re going to introduce a “frequent flyer” program to get them, just by posting on the community site this early you’re in. We’re working on those specifics now.

2 Likes

:point_up:

Yep! That’ll come in a future pricing update. I imagine we’ll be adding / tweaking this for the next decade or so.

1 Like

Hey @kurt any news on the pricing of the global Redis offering you mentioned in some other thread?

The plan is to keep the one we have free for lightweight usage, and then have people move to dedicated Redis (billed like any other app) when that gets to be too much. We’re working on VMs with more RAM specifically for this.

Sounds good!

Hey! Sorry we’re a bit late to this discussion. Lots of great ideas though. Our notes:

  • 100% agree with eliminating the free plan - I wondered how y’all were handling abuse. In fact, having the free plan did not play into our decision to go with Fly (and we’re a cash-strapped startup). It even made us feel a bit cautious: we picked fly for SSL certificates and were a bit flummoxed by and distrustful of the free plan, especially when trusting security-critical pieces of our app to you
  • We picked fly because the pricing is fair and predictably scales (we need to be able to offer services and predict how much each costs)
  • Most of all things, having predictable, per certificate SSL pricing is important for us - it’s a cost that’s linear with our revenue (each of our customers gets 3 certificates, @, www and cdn). We’re hoping you can keep a similar pricing structure here.
  • We don’t want to have to manually scale fixed resources. If we need more certificates, just bill us more incrementally, please.
  • We expect to move more of our stack to Fly over time (we need Postgres for ActiveRecord with near-0-rated bandwidth between the db and our write-heavy Rails app - although we don’t need geo-distribution as much). We need zero-rated bandwidth between internal services much more than we need cheaper egress bandwidth - again, in this case, we’re okay with not having geo-distrubution.
  • Please keep great PAYG plans available on top of a fixed-monthly fee. We need to be able to know our monthly bill will never be more than (cost of resources per customer) * (customers) for pricing our services, but reasonable fixed-rate fees are okay, so are volume discounts. Please avoid arbitrary “step” plans where overage > the cost of the base plan and overage > the cost of the next plan (looks glaringly at email services). These suck to put in spreadsheets, and make unit cost analysis very hard.

We’re happier paying higher prices if the unit-cost analysis is easier. Per-resource pricing, at least for overages, is a large want.

1 Like

A post was split to a new topic: What happens when you remove a dedicated IP?

As an update here, we’ve simplified new pricing and aren’t going to release plans yet. Instead, we’re going to ship new VM types, lower bandwidth pricing, add “upgrade your memory” as a feature, and basically keep metered pricing in place.

Some of our products will include a free tier (like bandwidth, certs, DNS, and tiny VMs). Some will be paid from the get go (like volumes, larger VMs).

I still like free services so we’re going to try this out, then experiment with trial periods, different types of free tiers, etc.

We are going to require a credit card on file for everyone at some point, which we expect to prevent lots of abuse.

We’re happier paying higher prices if the unit-cost analysis is easier. Per-resource pricing, at least for overages, is a large want.

@ben this will always be the case. When we finally do plans, it’ll be a bundle of discounted services, and extra usage metered at normal rates. We want every product we sell to be accessible for side projects, and metered prices are the way to go for that.

2 Likes

@kurt, is there an ETA when details of the new pricing will be published?

No ETA on actually enabling new pricing yet, but here is what we’re planning. You may not hold me to these if something changes. :wink:

VMs are either going to be shared CPU or dedicated CPU. Dedicated CPU VMs won’t share hardware threads, shared CPU VMs will.

  • Shared CPU VM with 256MB RAM: ~$3/mo
  • 2x Shared CPU VM with 4GB RAM: ~$25/mo
  • Dedicated CPU VM with 2GB RAM: ~$33/mo
  • 8x Dedicated CPU VM with 32GB RAM: ~$350/mo

There will be a way to add RAM to these (with some constraints). You can plan on about $5/mo per 1GB of RAM.

Bandwidth should be:

  • ~$0.02/GB for North America and Europe
  • ~$0.04/GB for Asia Pacific, Oceania, South America
1 Like