The pricing for CPU Type - Shared doesn’t look right
Can you also add a button to remove machine groups (when > 1)? If you add an additional machine group and later want to remove it you have to reload the page and lose all progress.
With the number of issues the calculator has maybe you should take it down temporarily while you fix it as it’s probably doing more harm than good.
@charsleysa I don’t see any reason to do that, but we’ll certainly keep iterating based on feedback—so please keep sending that through! We have a bunch of improvements coming down the pipe (including most of the things mentioned in this thread).
1 Like
I’ve been thinking of giving Fly a go and the 3 free instances sounded good for me. If I register now, do I not get 3 free instances? If not, feels like “any time soon” from the below quote came pretty soon.
The fact that we (Fly.io) require a credit card is evidence that we don’t plan to take the free plan away any time soon. [2022]
They killed the free hobby tier a few months ago. The pricing is still confusing, but I think if you’re consuming < $5/month, that should still be waived. You can use the suspend feature to limit your compute time to minimize costs to stay under that threshold.
Please correct me if I’m wrong w/ any of this.
Any plans to introduce a ticketing system for support? In my experience, including in the last week, email threads with your support team end have ended up unresolved, with no response on your end even after some initial engagement. I think you may just be using a shared inbox for now?
Hi… I haven’t used this before, myself, but perhaps the following was intended to be the first step in that?
Either way, that other thread might be a bit better for feedback, 
…
I’m doing this, as I have in the past:
And yes, you can still use your unique support email address to get in touch if you prefer!
Based on this, I believe there should be no difference in the way issues submitted via the portal or via email. The issue I submitted via email shows up there:
There’s no way to click into the issue to get a history or any more status.
Whether they call this a ticketing system or not, I suspect this is a pretty rudimentary homegrown system and may be missing features that ensure follow-up on their end.
The point is really more that I’ve had tickets, including this one, that have gone into a black hole and from experience, I expect not to receive any follow-up. And, given that this is now going to be a separate paid add-on, I think they need to improve things on their end.
As for my specific issue, I sent a response on Oct. 5 and then another on Oct. 8 asking “Should I expect any further follow up on this?”. And, crickets since then.
For the record, the issue I had is that Depot builders increased our build times by 4X vs. native remote builders, and seem to have a resource contention issue that fly’s own builders doesn’t have. We’ve disabled Depot builders but the last public statement is that they’ll stop supporting their own remote builders. On my email thread with support someone from fly said that they “may” not deprecate their own builders. Not very reassuring. I gave some details here. Again, no follow up in the public forum
I suspect that fly may have decided that I’m being a pain in the ass and just stopped responding. A “real” ticketing system should ensure that they follow up, even with customers they think are being difficult (and for the record: I think this is a legitimate issue and I’m quite frustrated with the lack of engagement).
1 Like
Hi @neil, sorry you’ve had a frustrating time. To clear up any confusion, we don’t use any sort of home-rolled or rudimentary support ticketing system—we use Plain—which is in part how we’ve been able to build out the features you see in the support portal. The portal will see many more iterations and improvements in the coming months!
You’re also correct that whether you email in or use the contact form, your request goes to the same place and is triaged in the same way by our team.
Onto your issue: I hadn’t seen your Depot ticket with us until now. Looks like you went the whole of las week without a followup—sorry about that. I suspect there was some confusion/ambiguity stemming from the parallel responses in the community forum thread. I am still not 100% clear what the ask is.
In skimming the ticket and forum post, my understanding is that the guidance is to scope app builds to their own builders to prevent resource contention (which is why you’re struggling with performance of those builds).
Have you tried that? Let’s discuss in your ticket.
Aside from scoping app builds to their own builders, there are two other workarounds that are available:
- Continue to use Fly builders by specifying
--depot-falsein your build step (which you’ve done) - Run your builds in CI using
--local-only
Worth noting too that you can always DIY your own builder as a standard Fly App using RCHAB—which is exactly what Fly builders use under the hood.
I’ll personally follow-up on your ticket tomorrow so we can try to work this out.
cc/ @joshua-fly
Thanks for following up. I appreciate your attention, but I believe there’s still some misunderstanding about the nature of the problem we’ve experienced with Depot builders. Let me clarify a few points:
-
Not just resource contention: While resource contention may exacerbate the issue, we experienced a consistent 4X slowdown with Depot builders even when running single builds. This indicates a fundamental performance difference between Depot and standard Fly builders. I’ve detailed this in my previous post. And resource contention is really a consequence of the slowdown as we’re far more likely to have parallel builds when things are 4X slower.
-
Systemic issue and framing: The performance degradation isn’t limited to specific steps in our CI process, as suggested in this earlier response. As I demonstrated, all steps of our build process are affected, with the overall build time increasing from about 9 minutes to over 34 minutes. This consistent slowdown across all steps indicates a systemic issue on Depot’s end, not a problem with our specific CI setup. Our pipeline has been working fine for years without significant changes. The sudden onset of a massive slowdown when switching to Depot builders is, by definition, an issue with the new system. The responses I’ve received seem to be premised on the idea that there’s an issue on our end, which is frustrating given the clear evidence that this is a Depot-specific problem. Even if it affects a small percentage of customers, when you’re the customer facing this, it’s quite disruptive.
-
Default behavior change: While
--depot-scope appmight help with resource contention, it doesn’t address the core performance issue. Moreover, I would suggest that the default behavior for Depot should match the previous non-Depot behavior to avoid disrupting existing workflows. I’ve also mentioned this concern in my forum post. -
Concern about future deprecation: The last official public statement indicated that Fly would “likely stop supporting the standard Fly remote builder.” While I understand this may not be immediate, it’s concerning for those of us who can’t currently use Depot due to these performance issues. As I mentioned, I was told via email support that you “may” continue to support the standard builder, but that’s not very reassuring.
I appreciate that you’re willing to investigate this further. I’d be willing to devote some time to helping, but with the understanding that you’re asking us to spend our time assisting you in identifying and resolving an issue with your new system, not that you’re helping to debug an issue on our end, as things are currently framed.
BTW regarding this:
I suspect there was some confusion/ambiguity stemming from the parallel responses in the community forum thread.
Right, I posted publicly after not getting any follow-up on the support thread. And then I didn’t receive a response to my forum post. Posting here is what finally got a response.
We can keep our future communication regarding this in the support ticket.
2 Likes
Hey I’m trying to get support, and it asked me to downgrade my current plan, so I did, but now it says I have to wait two weeks until the plan rolls over until I can get support. Is there any way I can get it sooner?
Hi, I manually pushed the plan change through, effective immediately. So your org is now on pay-as-you-go and you can purchase support.
1 Like
It’s a little bit off-topic, but speaking of pricing… Any idea if the “under 5$ invoices are not charged” thing is true or not? I’m a (med) student running a tiny deployment, and I’m kinda confused by the pricing schemes and the different answers all over the forums. Any help is appreciated : )
Yes, no, maybe?
We’re doing stuff with storage we’ll be talking about. But the performance/resiliency characteristics of Fly Volumes are a consequence of their design: they’re attached NVMe storage.
1 Like
Yes, if you’re under $5, your bill is waived. Fly can correct me if I’m wrong though.
That is good to hear. Would love to see something in between Fly Volumes and Tigris Object Storage with low latency, durability, and competitive pricing.