Coming soon: paid plans and support, oh my

1

Howdy! We’re working on something that might matter to you. Now’s your chance to give us feedback.

Fly services have always been billed on usage. The more you use, the more you pay. And if you don’t use much, you don’t pay anything.

There are a few guiding principles behind this:

  1. We want lots of people to use us.
  2. We want most small projects to be as close to free as possible.
  3. Pricing should be transparent and predictable for all projects, including larger ones.
  4. We don’t want to make money on bandwidth

The problem with only billing on usage is that if you use more, you probably want more things from the platform. Increased limits on things like Docker image sizes and proxy timeouts become more important. And as you use more platform features, you also may need help that is more specific to your organization. This might include email support, response time guarantees, or a BAA for HIPAA compliance.

We want to do these things! So we’re about to launch Fly Plus and Fly Premium plans.

Here’s what we’re thinking:

Fly Plus

  • For customers who need higher limits for features like proxy timeouts, docker image sizes, and builder concurrency. Also includes email support.
  • Cost: $99/month, added to monthly usage billing

Fly Premium

  • For customers who need even higher platform limits and more targeted support. Fly Premium will include email support with an org-specific 911 address for emergencies and response time guarantees.
  • Cost: $499/month, added to monthly usage billing

Plan Comparison

Standard Plus Premium
Monthly price (in addition to monthly usage) $0 $99 $499
Community support x x x
GDPR x x x
Increased platform limits (e.g., proxy timeouts, Docker image size, limit depends on tier) x x
Fast builders 1x 4x
Email support x x
Support Response times 24h 2h
Dedicated 911 email for emergencies x
HIPAA BAA x

Comments?

Do these plans sound useful? Are there other things you want that we can charge you for? Should we give them clever names like “Fly Solo” and “Fly Commercial”?

9 Likes
2

I think this is a great move. It enables low cost for hobby / personal / startup projects while providing more premium services to larger projects / businesses.

Is this pricing per organization or per business? E.g. if 1 business has 2 organizations, say a production org and a staging org, will the Fly Premium cost be $499 or $998?

Also, regarding other things to charge for, what about metrics? I’m thinking along the lines of higher priority or separate premium cluster to provide better guarantees around metrics collection and availability. Maybe also offering a out-of-the-box grafana-compatible system for metrics, logs, and traces.

A couple of other things, which might not be for this thread, is intra-region bandwidth pricing for traffic that doesn’t leave the region, and out-of-the-box s3-like storage that can be provisioned just as easily as volumes without having to manage any apps or instances that power the storage.

1 Like
3

Glad this is useful!

We will do aggregate billing someday, but it’s per organization right now. The higher limits are on the org with the paid plan, so you’d put production on that. But if you needed support on staging and your production org is on a paid plan, we’d still help you out.

Metrics is definitely something we’d include in paid plans.

On bandwidth, we will keep looking at ways to minimize costs, and intra-region is one possibility. On having S3 storage, that might be a different conversation, but something we can keep in mind.

4

In regards to the billing, it’s less about whether the billing is aggregate or not, but more of whether full price will need to be paid for each org to access some of the features listed (proxy timeouts, docker image sizes, builder concurrency).

Is it maybe worthwhile splitting those features from the support pricing, that way multiple orgs for testing, QA, etc can be setup with access to those features without needing to double up on support costs as you’d probably never need 911 response time guarantees for staging but you would probably need the same level of higher platform limits (especially if you want to get it as close to production configuration as possible).

Is there a timeline as to when you expect to rollout these changes?

5

Right - aggregate billing isn’t the problem we’re solving here, it’s getting features to people who want them. Currently, billing is per org, so paid plan features will be added per organization when this rolls out.

Breaking out features into platform vs support is interesting, although brings its own complexity. Which would be more helpful to you: 1) keeping dev, staging, and prod as separate orgs that each have their own granular plan, or 2) grouping dev/staging/prod apps into a single entity that gets one general plan?

I’m not sure how realistic either would be, but it would be useful to understand how one or the other (or yet another idea!) might make things easier for you.

Timeline is “soon”. No date yet, but it’s weeks, not months.

6

For our current needs, option 2 would probably be the best option as we don’t spin up many environments, we just have staging and production.

The reason we use separate orgs is to take advantage of the isolation, separate access rights, separate private network, etc but our staging and production environments are setup essentially the same so do require the same capabilities.

7

Got it - that makes a lot of sense.

Thanks for the feedback, it’s really helpful!

8

We would need plus for at least two of our orgs (timeout increase), trusselltrust and concordia so when you’re ready sign us up.

With regards to the plan names how about community, business, enterprise?

9

Dedicated 911 email for emergencies

What is your definition of an emergency?

I’d pay to have very fast response in case our service goes down and e.g. restart/deploy does not fix it or other and we can’t figure it out

10

This is a great example of an emergency! If your service is completely down and you need quick response to help figure out to get it back up, the 911 email would be the way to go.

11

I’m the economic buyer for Infrastructure/Fly (rather than a Dev).

My main concern here is that prices are going to creep up over time. We’re on the verge of deciding to be all in on Fly vs AWS infrastructure for a production SaaS service. What we want is consistency and reliability over a long time - we don’t want to have to change infrasture providers due to funky costs for years.

There’s nothing wrong with the plan approach but a couple of points.

  1. 911 email should be available to everyone who is paying you even 1cent. And there should be a phone number. What about considering this as a pay for usage thing if the customer is at fault. Your cost if you folks stuff up. From my POV if you want $500 mth, I’d want an account manager and phone number to contact if things go awry.

  2. For Premium you might want to look at some sort of SLA. That’s something our customers want from us - and so we want/need it from the infrastructure provider in turn - ditto Security Standards.

  3. It’s a big jump between Pro and Premium with not a lot of extra in Premium (considering my point 1 above).

  4. Can you explain what you plan for HIPAA BAA?

  5. You could consider bundling a certain amount of usage in the Plans.

My 2cents.

2 Likes
12

This is great feedback - thanks. Agree that changing providers is painful, so it’s definitely good to think this through early!

Consistency and reliability are important, although I might reorder them in terms of priority. We lose sleep over keeping the infrastructure up and running; support is there for the (hopefully rare) case that something goes sideways. If we’re focused on reliability – which we are! – consistency becomes much easier to maintain.

For these plans, we wanted to start with a base level of features that customers have been asking us for. If anything, we expect to add to them over time. We are also looking at an enterprise level tier that would go beyond Premium, and some advanced features might end up there. But I can’t see moving a feature from one tier to the next level up, and then forcing customers into the next level tier. That seems… not cool!

On your points:

The problems we want to solve here are making sure (all!) customers’ systems stay up, and getting them access to support beyond the forum if they want it. Pretty much everyone in the company works on system reliability in some way, and the plans include options for reaching someone who can help solve their problem. Account managers and a phone number may happen someday, but they come with some practical challenges, for lots of reasons. So we’re focused on this go-round with increased access through email (and possibly other channels); this may expand over time.

An SLA is a great point, and something we’re thinking about. We know security standards are a big deal, and we’re looking at this, too.

On top of the increased support levels, platform limits was kind of lumped into one tiny line item. These limits also account for some of the differentiation.

We’d work with customers going through their own HIPAA compliance process to make sure they have a BAA with us.

We’ve thought about building in usage! It includes its own complexity, though, so if we include it, we want to make sure we’re not also building in weird incentives that force customers into doing a lot of math to figure out whether they’re getting a good deal. We’d rather be transparent about pricing so customers know what they can expect to pay.

Thanks again for the detailed feedback - it’s super helpful!

13

A quick update here! A number of people have asked if they can buy these plans early, and the answer is “maybe”.

We are working on support. These plans promise email support response times we can’t currently deliver, so we have some work to do before we release them. If you are primarily interested in support options, you don’t want these yet. If you are interested in limit increases, HIPAA BAA, etc, you might and you should let us know.

2 Likes
14

Hi @kurt I am a huge fan but for my next startup, we absolutely need a BAA for hipaa compliance and would be happy to buy the plan plan early. Otherwise we’ll need to default to AWS :frowning: What’s the best way to discuss it ? support@fly.io ?

Thx

15

Hi Timothee – We should be able to help you with the BAA. Yes, shoot a note over to support@fly.io and we can figure it out!

16

What about additional Postgres database retention options, would love to see Point in time backups in the upper tier.

17

Point in time backups for Postgres dbs is something we’d like to do. Which tier it would land in, or whether retention options determine the tier, is something that we’d need to figure out. Thanks for bringing it up!

1 Like
18

I like this model; it cleanly separates usage costs from support enhancement costs.

As for the names, from a marketing perspective, I think being clear wins over being clever almost every time.

And having three tiers is a great place to start with these offerings, as it lets your users definitively choose a lane. So over time, you’ll be able to introduce other non-usage-related differences to the plans and have a good sense of how to tier them.

19

Honestly Pro / Premium feel like support plans only.

If you don’t bake usage in, or increase the number of included domains, etc, then it just supports.

Alternative to bake usage would be a slight decrease in the usage rates.

If you bake usage in, then you would expect to not be billed until you have hit an overage. If you charge a lower rate, you can largely keep the model you have now, but there is an incentive to pay the higher rate.

I agree with others on the SLAs. Though I think that would be hard to force since it’s not purely a managed service. I can write a bad docker file and it would look like a Fly problem, but maybe a foot gun.

20

Thanks for mentioning this. The paid plans will include increased limits on some platform features, and we are planning to include some amount of usage in them. Paid plans are intended for customers who expect to need more than what everyone gets out of the box – higher feature limits, more included usage, and more support.

We don’t really want people to get a paid plan just for the included usage, so the goal is to include enough, but not be the only reason to get the paid plan. Basically, we only want people to get paid plans if they really want the stuff in them. We’re happy to have everyone stay on the standard usage plans if that works for them!

1 Like