[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. :/

[pmarreck]

Are they killing their products due to lack of demand (which seems odd, given the cost/benefit), too much competition from Amazon, running out of money vs. ramping up sales, or??

I just googled and it looks like the Ampere Altra is shipping in some rackmount configs? (Vaporware?)

https://www.gigabyte.com/Enterprise/Rack-Server?fid=2326,222...

https://www.avantek.co.uk/ such as https://store.avantek.co.uk/ampere-altra-mt-jade.html

https://amperecomputing.com/reference-platforms/

[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?