[lewisl9029]

I'm so glad Fly exists. Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request.

That's fine for a lot of use cases, but the unit economics of the per request pricing model means it's really hard to operate a predictably sustainable (i.e. profitable) business without also charging our customers on a usage basis, or enforcing limits on usage, neither of which is ideal for maximizing engagement as incentives are no longer aligned.

Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute.

This provides much better unit economics for many kinds of applications, at the cost of having to manage the scaling ourselves. But because the option exists, we can make this tradeoff on a case-by-case basis, which is so much better than if all we had was "serverless" stuff at the edge and had to choose between just low latency across the globe vs good unit economics.

[mooreds]

For a company that says it makes it super easy to deploy a container image and mentions that all you need to do "Write your code, package it into a Docker image, deploy it to Fly's platform"[0], they sure have a dearth of documentation on how to deploy an existing docker container.

I am not sure if I'm missing something or what, but here's where I looked:

   * googled 'docker fly' and a blog post that references docker but as far as I can see doesn't have instructions on deploying docker images shows up[1].
   * their getting started guide[2], called a 'speed run' which has all kinds of CLI commands but doesn't actually show how I'd pick a docker image.
   * their quickstart docs[3], which outline how to deploy all manner of applications, except for, you guessed it, an existing docker image.
   * scanned the menu of their docs, and didn't see anything.

I really want to like this service, as we have (at $CURJOB) an app packaged as a docker image that it'd be awesome to set up to run on Fly.io, especially with the multi-region postgresql.

What the heck am I missing? Can I just not read? Do I just need to install the CLI and all shall be made clear?

0: https://fly.io/docs/introduction/

1: https://fly.io/blog/docker-without-docker/

2: https://fly.io/docs/speedrun/

3: https://fly.io/docs/getting-started/

[mrkurt]

You know, you're not really missing anything, we just don't connect the dots very well.

Install CLI, run `fly launch` in a directory with a Dockerfile, and it should just work.

Most of our users don't start with a Docker image though, they start with Phoenix. What you're seeing is a little bit of indecisiveness in how we target the docs.

[HellsMaddy]

I just did this with an application I haven't touch in years. The deployment worked on the first try. A few clicks and I had TLS certificates. I'm sold!

[HellsMaddy]

I can’t live with this typo. s/touch/touched

[cornel_io]

Out of curiosity, why target Phoenix users as your primary audience when you serve generic Docker users easily as well, given that they're likely a 10x or more segment? Are you just marketing to a tighter target audience to start, or is your platform/UI specifically optimized to support Phoenix?

[mrkurt]

We started with generic Docker! The Phoenix focus has been very helpful, though. Docker apps are incredibly broad, other than "it's really easy to launch a container", it's hard to define why we're especially good at Docker containers.

With Phoenix, we can say: run your fullstack Phoenix app on Fly and your users get sub 40ms responses from LiveView. When responses are that fast, you can write less code and still build really dynamic applications. And we can give those devs a really nice launch experience: https://twitter.com/chris_mccord/status/1468998944009166849

We're getting to the point where we can expand this focus. The infrastructure works great for many types of apps. The launch UX could be good for every full stack framework with enough people.

[earthboundkid]

The Phoenix guy works for them, so I'm sure they have a lot of organic interest from Phoenix users. It's like how you don't have to use Next.js on Vercel, but…

[tyingq]

This type of humble and helpful answer from a vendor is refreshing.

[piaste]

> Install CLI, run `fly launch` in a directory with a Dockerfile, and it should just work.

Does this build the Docker image locally and send it to Fly.io, or does it send the whole build context to Fly.io and build the image remotely?

[mrkurt]

If you have Docker running locally, it does a local build and pushes to our registry. If you don't have docker running locally, it launches Docker on our infrastructure, sends it the context, and does a remote build.

You can control this with "fly deploy --remote-only" and "fly deploy --local-only". Don't use both, it might cause a paradox.

[piaste]

Very sensible, thanks.

[Serow225]

I’d really recommend adding a section to this* page something like “existing Docker containers” ! I would not have found out that it’s possible based on your current docs layout.

* https://fly.io/docs/getting-started/

Also, I noticed that the Speedrun page a) in step 3, doesn’t tell you to CD into your source code directory before running the launch command to autobuild, and b) is missing links to all the autobuild supported languages

[mooreds]

Thanks! I'd rather run with a defined image, is there a way to do that?

Here's the image: https://hub.docker.com/r/fusionauth/fusionauth-app/tags (supports ARM or x86).

Edit: https://news.ycombinator.com/item?id=30019258 shows, I think, how to do that.

[mrkurt]

Ah, for this you want "fly launch", it'll tell you it's going to generate a config file for you.

Edit the config so the `internal_port` is right for the app you're running, then `fly deploy -i fusionauth/fusionauth-app` and you should be good.

[pmarreck]

What are your ARM plans, if any?

[mrkurt]

We have no ARM plans, but a strong desire. The really good ARM stuff is locked up within Apple and Amazon, though. I'm really hoping an independent chip vendor ships a compelling and broadly available ARM platform we can use for servers. They all keep killing their products. :/

[Serow225]

Any chance of getting autobuilder support for Rust? :)

What about same for .NET? (and I suppose some people would care about Java,Kotlin,Swift ;)

I don’t have to deal with containers with my current infrastructure, and it would be nice if I didn’t just to be able to use Fly—I find containers to be a PITA.

Thanks! I’m super jazzed about Fly :D

[mrkurt]

Yes there's a good chance for all of these! You can post on community.fly.io if you'd like and get a headstart. People have prebuilt Dockerfiles laying around for everything (and we have lost of Rust stuff).

We use Dockerfiles kind of like make files. Once you have one that works, you don't need to think about it anymore.

[mwcampbell]

> I don’t have to deal with containers with my current infrastructure

Just curious, which infrastructure is that, and does it have built-in build support for Rust?

[0x0000000]

You're right, they should make that much more clear. I'd expect it to be on the left side menu, just like they have all the "Run a [language] app".

Based on your first link [0], I saw,

> You can run most applications with a Dockerfile using the flyctl command.

With that, I looked over the left-side menu, and clicked `flyctl`[1], since it seems that's what you'd need to use to deploy an existing app with Docker. After that, I clicked on "Launch an App" [2], which shows help for the `flyctl launch` subcommand, including a parameter `--dockerfile`. I think that's how you would deploy an existing app with docker?

[0] https://fly.io/docs/introduction/ [1] https://fly.io/docs/flyctl/ [2] https://fly.io/docs/flyctl/launch/

[mooreds]

Thanks! As mentioned in sibling comment, I want to use an existing docker image, so probably `flyctl launch --image $NAME`.

[onphonenow]

I agree - could be clearer!

[ignoramous]

> Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request.

Workers Unbound is $1 for ~6.6M requests (+ runtime at $0.0000015 per sec / $12.5 for 1M GB-sec). That's super cheap considering free egress, which brings me to...

> Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests...

Fly.io may not meter requests anymore, but they continue to meter egress, even between your VMs in the same region [0]. Usage-based price model is everywhere, like it or not.

[0] https://community.fly.io/t/do-traffic-over-6pn-within-the-sa...

[mrkurt]

We don't bill for internal Postgres bandwidth anymore. Bandwidth in general is a good point though. No one _actually_ offers unlimited bandwidth. We haven't figured out how to be transparent about bandwidth costs AND check that box for people yet, though.

[gfd]

> No one _actually_ offers unlimited bandwidth.

Isn't cloudflare's whole shtick about not having egress fees? https://blog.cloudflare.com/workers-now-even-more-unbound/

[mrkurt]

Cloud Flare's model is to give you "unlimited" bandwidth with restrictions on how you can use it. If you do any kind of volume you quickly get a call from a sales person who wants to sell you enterprise. And then you end up paying a relatively high per-GB price as one big enterprise contract.

They're reasonably transparent about this, and I think it's fair. It's just not how I prefer to buy services.

At no point will we call you up and try to get you to spend more money to keep doing what you're already doing.

[ignoramous]

We are pushing xxTBs every month at this point, and I haven't got the call yet. I'd have to spend $yyyy dollars on Fly.io for that kind of bandwidth. By simply moving to Unbound last month, we even halved our bills, and with some planned software changes, bills should go down another 30%. Besides, Matthew Prince says pushing higher bandwidth via Workers is fair game [0].

That said, I very much prefer Fly.io to AWS for workloads not suitable for Workers... and in just these past 3 months, we committed eng resources to make sure Workers workloads can run on Fly.io too, if and when the time comes for an instant migration.

We also run workloads on AWS AppRunner and Amazon Lightsail Containers and that's only because S3 <-> EC2 bandwidth is ~$0. We'd definitely move to R2 once Cloudflare opens it up, and we hope, eventually, Fly.io reaches the scale to peer directly with Cloudflare DCs for lower latencies, if nothing else.

[0] https://news.ycombinator.com/item?id=20791660

[nerdyadventurer]

Is pricing page updated according this news, seems not to me?

Can I please also know how PG clusters are run at the edge? Docs is not very informative about how things work under the hood(ie. infrastructure / deployment).

[leerob]

Sounds like Fly is moving to usage-based pricing: https://twitter.com/mrkurt/status/1475310487864848391

[mrkurt]

This is true, but we aren't going to bill per request. We really can't, since we support arbitrary UDP and TCP services.

I don't really want to promise anything we haven't shipped yet. But my perfect cloud service (a) charges me when VMs are alive and (b) gives me the tools I need to create/remove/stop/start/suspend/resume VMs based on either network activity or metrics.

One flaw of Fly.io right now is that it's relatively expensive to run a side project in 10+ regions. Most apps benefit from 10+ regions, but $50/mo to try it out is prohibitive. We want to make this more accessible.

[onphonenow]

I actually worry you are undervaluing yourselves. $50 is fine for 10 regions as a data point from where I sit though I wouldn’t object to less

[mrkurt]

Oh don't you worry. We can extract large sums of money from big companies.

[onphonenow]

Big places have bet pretty big on docker.

Docker also seems like the quickest option to come out of AWS (ie, ECS or friends) and try fly - so I'd continue chasing a bit of a docker story if you could (even just in docs -> getting going with Docker).

[xfer]

> charges me when VMs are alive and

You still need that capacity, don't you? You will have to adjust the pricing but i doubt it will cost either of us any less, whether you allocate it.

[mrkurt]

The nice thing about mapping peoples apps to overpowered hardware is that it flattens bursts. We need capacity for, say, 10% of apps to burst at any given time.

The nice thing about spreading hardware around the world is that we have excess capacity wherever it's dark. If you're doing latency insensitive work like batch jobs, we can schedule it somewhere that would otherwise be idle.

Aggregate capacity is smaller than the sum of the individual apps capacity requirements. So we both benefit.

[andy_ppp]

Can you scale each region based on usage i.e. have a huge server in US or Europe and a tiny one in a market you don't have many users in? fly.io is really an incredible piece of work, I'll probably just default to it as I am a massive Elixir fanboy :-)

As others have said $50 seems a very low starting point but if you can make it cheaper why not, just means you've helped more people onto your service and they will grow with you.

[mrkurt]

Autoscaling and balancing regions is something we launched with, but it ended up not making much sense. Our load balance sends traffic to the next nearest region when an app is too busy. It's usually better to spread capacity around to lower latency for users, and then eat the additional latency when a region gets overloaded.

In most cases "the next nearest region" is less than 15ms away.

[mike_d]

Is arbitrary UDP working now?

I don't fault you guys for being a growing startup (we have all been there), but it would be awesome to have a way to flag an issue as "email me when this is fixed so I can come back."

[tptacek]

Arbitrary UDP has worked since we launched UDP; it's never had a port filter or anything.

[mike_d]

My bad, it was v6 UDP I was thinking of?

I'm a big fan of Fly and have one medium-sized app deployed to it. Just waiting on this specific issue before deploying more: https://community.fly.io/t/allow-non-root-users-to-write-to-...

[tptacek]

You're not crazy! We still don't do v6 UDP (there's no good reason for us not to, but it'll be a week of rebuilding a BPF engine while the plane's still in the air, so this task never hits the top of our stack and won't until someone really pressures us on it). Full honesty! That's how we roll on HN. :)

[dmw_ng]

Would love to know what kind of approach you're taking for usage-based. Cold start every time, or some container/criu/VM suspend/resume magic?

[cxr]

> it's really hard to operate a predictably sustainable (i.e. profitable) business [... with other providers]. Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute

The praise on the subject of predictability is interesting, given perennial concerns about uncapped vs capped usage charges (with any cloud provider), but esp. in light of past Fly-specific comments that "putting work into features specifically to minimize how much people spend seems like a good way to fail a company".

<https://news.ycombinator.com/item?id=24699221>

[mrkurt]

We ended up shipping a "cap your costs" feature, we just did it with prepaid credits. If you buy prepaid credits instead of adding a credit card to your account, we can't bill you more than you've prepaid. The downside is that you have to prepay $25 to use anything at all.

My comment could have been better. Our business model is predicated on making it cheap to use services and easy to incrementally scale up. We probably won't build features to cap usage of things directly, but it makes total sense to deactivate apps when credits run out.

[rmbyrro]

Serverless pricing model doesn't have to be transferred to your customers.

If you know them well and their usage patterns, you can predict with confidence how much each customer will cost you. With granularity to the level of a feature or even a particular action.

This allows for extremely precise and safe unit economics planning. I couldn't be happier with this benefit from serverless.

In a server-based infra you have many fixed costs: servers themselves, unused capacity, and your time to maintain it, which is certainly expensive, since it competes with attention to the product or maybe sales and customer support.

[hdjrudni]

Kubernetes on DigitalOcean scales pretty well.. fixed monthly cost. If I run out of capacity I just add an extra node or switch to more powerful nodes. Kubernetes takes care of provisioning the nodes.

Google APIs OTOH... I went from $0/month to $450 the next because of their stupid per-unit pricing and hidden API calls.

[ipaddr]

If your server administrator doubles as your sales person maybe but for most companies these are different roles and you need someone to manage your fly.io account/docker image or your aws account. Sales, customer support, legal, marketing should be affected. If you are a one man show that's a different conversation.