This means that there is no way to perform a seamless migration without downtime on the ipv4 space?
I’m actually thinking, there is a way to perform a migration without downtime (if your app doesn’t need internal inbound networking or is some kind of cluster - most web apps will be fine):
Create a new app without a dedicated IP, copy all the env vars and configure it the same way as the original app;
Deploy the new app;
In certificates add the same domain/hostname from the previous app;
Point the acme challenge CNAMEs to the new app and wait for certificates to get issued;
Point the traffic to the new app, both IPV4 and V6 (A and AAAA);
Wait for propagation and for the traffic on the old app to go silent;
An update: We now allow having both a shared IPv4 and dedicated IPv4. This change should make it possible to switch to a shared IPv4 without downtime.
The produce looks like this:
Add shared ipv4 via flyctl ips allocate-v4 --shared
(Optional: add the shared ipv4 as an A record for your hostname if you don’t use a CNAME to .fly.dev)
Confirm your app works via shared IP: curl -Iv http://<your-hostname> --resolve <your-hostname>:80:<shared ipv4 you got> (should respond with a 301 redirect)
Wait for DNS caches to clear… probably 5 minutes but that varies wildly, this should be the biggest value between your DNS record’s TTL and our <your-app>.fly.dev record (300 I believe).
Remove the dedicated IPv4 from Fly (and optionally remove from your DNS if you set it manually as an A record)
Can you give a bit more info about the tradeoffs of using a shared vs dedicated IP?
In particular, how this applies to outbound traffic from machines. If my application calls out to APIs that apply rate limits by IP address and I switch from a dedicated to a shared ipv4, am I now essentially sharing rate limit quota with other fly customers sharing the same IP that call out to that same API?
Same story as the above for me too, an unexpected credit card charge on 2 applications which had happily been sat on the free tier for over 12 months. I didn’t receive any communications on my email address associated with the account to let me know this would be the case.
I’ve let it go and paid it as it’s a very small sum in my case, and I have a lot of respect for fly as an organisation in general, but something definitely seems to have been missed here!
I want to end this contract, how can I do that? I no longer need your service and I don’t want payments/invoices anymore. Can someone please help me to do this?
I have a lot of idle apps which have zero Machines deployed. It turns out each of those apps still has a dedicated IPv4 assigned. At least based on the unexpected bill today.
I use the CLI and that doesn’t make clear that an IPv4 is dedicated and will be billed e.g flyctl ips list --app name lists the IPv4’s type as simply "public’. I’m not sure if there’s another command to show it.
I think a lot of people on the free/hobby plan are affected because their apps were created with default settings and were just humming along. I think the intent of the majority of those users were: “keep me on the free plan until I need more”, as opposed to “i need a dedicated ipv4 no matter what”.
By coincidence I signed in to check my billing status mid-december. The billing page did include these charges but also said “preview - we’re not charging yet”. I immediately transitioned to shared-ips anyway because I don’t need dedicated. Although minor and preventable, it still feel like a surprise charge.
To be clear, I think it’s absolutely fair to charge for dedicated ipv4, and I’m happy to do so. But many users are now charged for a service they (a) don’t need and (b) they didn’t explicitly opt into. This billing change could certainly have benefited from an email to affected users, or maybe even an auto-migration to shared-ips(?).
For those of you who weren’t following this thread: we’re sorry we weren’t more explicit about this New Years surprise.
We neglected to take into account the number of apps that might be affected by this change, and also neglected to send an email, knowing that not everybody reads these forums.
We’ll take a closer look at this and post more on this thread this week.
That said, if your current bill is less than $5, you won’t be charged at the end of the month. So you have time to migrate to shared IPs, cancel your account, etc.
@greg makes a good point about it not being clear whether an IP is dedicated in flyctl ips list output - noted!
Perhaps I’ve missed it somewhere in this thread, but the announcement states billing won’t start until January 1st and I’ve received a bill for usage in December (2 distinct IPv4 - $4.13)
Additionally, @joshua-fly, I was charged $4.13… Invoice 1BE37564-0015 if you’d like to take a look.
All in all, it’s a small charge and I’m quite happy with fly.io, but unexpected none the less.
Sorry for the confusion. What I mean is: we should be automatically waiving invoices that come in under $5. Are you saying your card was charged for 4 USD?
In any case, it’s clear we made a mistake here and we’ll look into a way to rectify the charges that went out. We’ll just need a bit of time to work it out.
And, we’ll email affected users about whatever we end up doing. Thanks for your confidence and patience!
@joshua-fly I heard about the payment for the fee yesterday, and today I finally switched from a dedicated IP to a shared IP. However, I received a message that I need to pay for the incomplete IPv4 transition for my app. So I have already been charged $2.06 on my credit card and received a payment completion invoice. Since the amount charged is less than $5, will it be automatically refunded before the end of the month? (Now i’m using shared IP) Please let me know.
