81–90 of 268 posts
One question: when I ran "flyctl deploy" it said "Docker daemon available, performing local build..."
If I turn off my local Docker, would it instead just upload the Dockerfile somewhere and perform the build for me?
If so, is there a way to force it to do that? I'd much rather upload a few hundred bytes of Dockerfile than build and push 100s of MBs of compiled image from my laptop.
I'm trying this out now. One question: when I ran "flyctl deploy" it said "Docker daemon available, performing local build..." If I turn off my local Docker, would it instead just upload the Dockerfile somewhere and perform the build for me? If so, is there a way to force it to do that? I'd much rather upload a few hundred bytes of Dockerfile than build and push 100s of MBs of compiled image from my laptop.
It would make sense to be able to force that. Right now you'd have to stop Docker.
(Also I'm a huge fan of Django)
Very impressive work. Just curious if you are worried about the big guys (AWS, GCP, etc) coming in and offering a similar service? If so, are you hoping DX will help act as moat?
I'm trying this out now. One question: when I ran "flyctl deploy" it said "Docker daemon available, performing local build..." If I turn off my local Docker, would it instead just upload the Dockerfile somewhere and perform the build for me? If so, is there a way to force it to do that? I'd much rather upload a few hundred bytes of Dockerfile than build and push 100s of MBs of compiled image from my laptop.
If one API request makes on average 5-10 round trips to the database, and the database is in Virginia, this only makes the problem (much) worse. How do you solve this problem for this use case?
“fly.io is really a way to run Docker images on servers in different cities and a global router to connect users to the nearest available instance. We convert your Docker image into a root filesystem, boot tiny VMs using an Amazon project called Firecracker, and then proxy connections to it. As your app gets more traffic, we add VMs in the most popular locations.”
Exciting stuff! My best to you!
I had to read these parts in the doc to get how Fly solves the problem differently:
> Think of a world where your application appears in the location where it is needed. When a user connects to a Fly application, the system determines the nearest location for the lowest latency and starts the application there.
> Compare those Fly features with a traditional non-Fly global cloud. There you create instances of your application at every location where you want low latency. Then, as demand grows, you'll end up scaling-up each location because scaling down is tricky and would involve a lot of automation. The likelihood is that you'll end up paying 24/7 for that scaled-up cloud version. Repeat that at every location and it’s a lot to pay for.
Just a feedback: the landing page doesn't explain at all what's the difference with AWS, Google Cloud, Azure, etc. I had to read these parts in the doc to get how Fly solves the problem differently: > Think of a world where your application appears in the location where it is needed. When a user connects to a Fly application, the system determines the nearest location for the lowest latency and starts the application…