7 ms·

This is a problem. And a bit of an own goal on our part. I hate services that don't put a price on things like bandwidth (because there's always a price!). So

by mrkurt 4y ago

This is a problem. And a bit of an own goal on our part. I hate services that don't put a price on things like bandwidth (because there's always a price!). So we priced bandwidth and made it transparent. You can put an app on Fly.io and server petabytes of data every month, if you want. We'll never complain that you're serving the wrong content type. But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site. We're not doing ourselves any favors with scary pricing for that kind of app.

brundolf 4y ago
I think it's also fine to just say "that's not our primary target market". Just thought it was worth pointing out as a (perhaps small?) segment of Heroku's market, if we're comparing apples to apples
- mrkurt 4y ago
  Oh but you are! And it won't even cost you anything. I'd bet money your blog fits in our free tier, we just don't (a) tell you that and (b) solve the "what happens if there's a bandwidth burst" problem.
  - brundolf 4y ago
    Yeah, I also supposed that it would probably mostly fit in the free tier, which is great. But I'd lose a small amount of sleep over the possibility of getting a huge bandwidth burst (DDOS or otherwise) that goes straight to my bank account A feature that could help would be giving people the option to set a cost limit, where if their site surpasses that limit in a given month you just pull it offline instead of charging more money. That's what I'd want for my blog site, and I've heard others request such a feature from other cloud providers
ignoramous 4y ago
> We'll never complain that you're serving the wrong content type. Cloudflare shouldn't restrict media (video, images, and audio) from its unlimited bandwidth promise for Workers and R2 (though, ToS doesn't yet reflect that). https://news.ycombinator.com/item?id=28682885 https://news.ycombinator.com/item?id=28682885 > But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site I think, an auto flyctl pause -a <myapp> when myapp exceeds $x in charges (with an auto-resume when the billing rolls over) may serve as a viable interim solution. May be this is already possible with fly.io's graphql api?
- TJSomething 4y ago
  Yup. Not too hard. This outputs the current bandwidth in gigabytes when you pass your app name. #!/usr/bin/env bash set -euo pipefail QUERY=$(cat <<EOF { "variables":{ "app":"$1", "start":"$(date +%Y-%m)", "end":"$(date -d "$(date +%Y%m01) +1 month -1 day" +%Y-%m-%d)" }, "query":"query (\$app: String!, \$start: ISO8601DateTime!, \$end: ISO8601DateTime!) { app(name: \$app) { organization { billables(startDate: \$start, endDate: \$end) { edges { node { app { id } category quantity } } } } } } " } EOF ) curl https://api.fly.io/graphql \ -H "Authorization: Bearer $(fly auth token)" \ -H 'content-type: application/json' \ --compressed \ -X POST \ --data-raw "$QUERY" \ --silent | jq '[.data.app.organization.billables.edges[].node | select(.app.id == "'"$1"'" and .category == "data_out") | .quantity] | add'
EnKopVand 4y ago
I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small app, blog or whatever, that you’re not sure where is heading. I don’t think anything I’ve build on my own time has ever ended up breaking my bank, but signing up my credit card is a risk I’m never going to take, and I’m fairly certain I’m not alone in that. Of course I have no idea if there are enough of us to make small scale fixed prices products profitable at scale.
- mrkurt 4y ago
  We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird because we have to pay for it (as does every other provider). We aren't yet in a position where we can just make it free without limits. Maybe next year. :)
  - brundolf 4y ago
    I can't speak for your whole market, but I know for me the pre-loading flow sounds really clunky because I'd have to go and manually add funds each month (right?) It's understandable if your usage data showed the fee-capping feature just wasn't popular enough to be worth maintaining, though that would surprise me based on this thread (but possibly HN just isn't representative of the whole market)
    - ceejayoz 4y ago
      I’d be happy with a “refill if under $10 up to $x/month”. If they can cut off when you’re out of credit they can presumably do it for other criteria, too.
bsder 4y ago
> And a bit of an own goal on our part. More than a bit. Simply give people the option to put a charge limit and let the app be offline when that limit gets hit. Don't make it the default, but do allow people to do it. This would resolve 99% of the fear people have. And most people wouldn't set the limit anyway. However, your knowledgable people might set it, and those are the ones you're most trying to attract.
ryantgtg 4y ago
I might be in the minority here, but I don’t have the slightest clue what my monthly bandwidth currently is on heroku, and so I can’t estimate what Fly will cost. Um, how do I find this out? Preferably historical usage.
- flurdy 4y ago
  I only found out my bandwidth after putting cloudflare infront of my apps as they email a monthly bandwidth saved report.
JohnBooty 4y ago
I don't want unlimited bandwidth (I mean, it'd be nice - but I realize it costs money) -- I want predictable pricing and spending caps for my personal projects. If I can't have that, then I just can't take the risk of my site getting hammered (by attackers, getting linked on HN, whatever) and racking up some kind of bill I can't pay. I realize the chances of that are small but that's scary. I realize that, obviously, "stay up at all costs" is what a business needs and that's where the money is. Fly.io won't get rich off of personal projects. But, I do think they serve to get developers onto the platform. Your bandwidth allocations and rates seem very fair and generous, btw. I do really want to check out your platform.
phamilton 4y ago
When I worked in adtech (Brightroll) we hosted a segment mapping server on heroku. All it did was look at a url query for the target url, append a value from a cookie to it, and 302 to that url. The value in adtech is that I can tell you which segment a user is in by taking the data in my cookie and appending it to your url. We launched it on Heroku using Nodejs and sent billions of requests a day to it. The thing ran on like a few dozen dynos, but it was responsible for like 20-30% of all of Heroku's bandwidth. Fantastic value for us. Immediate headache for Heroku.
weird-eye-issue 4y ago
Do you hate Cloudflare?

by mrkurt 4y ago

brundolf 4y ago

I think it's also fine to just say "that's not our primary target market". Just thought it was worth pointing out as a (perhaps small?) segment of Heroku's market, if we're comparing apples to apples

mrkurt 4y ago
Oh but you are! And it won't even cost you anything. I'd bet money your blog fits in our free tier, we just don't (a) tell you that and (b) solve the "what happens if there's a bandwidth burst" problem.
- brundolf 4y ago
  Yeah, I also supposed that it would probably mostly fit in the free tier, which is great. But I'd lose a small amount of sleep over the possibility of getting a huge bandwidth burst (DDOS or otherwise) that goes straight to my bank account A feature that could help would be giving people the option to set a cost limit, where if their site surpasses that limit in a given month you just pull it offline instead of charging more money. That's what I'd want for my blog site, and I've heard others request such a feature from other cloud providers

ignoramous 4y ago

> We'll never complain that you're serving the wrong content type. Cloudflare shouldn't restrict media (video, images, and audio) from its unlimited bandwidth promise for Workers and R2 (though, ToS doesn't yet reflect that). https://news.ycombinator.com/item?id=28682885 https://news.ycombinator.com/item?id=28682885 > But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site I think, an auto flyctl pause -a <myapp> when myapp exceeds $x in charges (with an auto-resume when the billing rolls over) may serve as a viable interim solution. May be this is already possible with fly.io's graphql api?

TJSomething 4y ago
Yup. Not too hard. This outputs the current bandwidth in gigabytes when you pass your app name. #!/usr/bin/env bash set -euo pipefail QUERY=$(cat <<EOF { "variables":{ "app":"$1", "start":"$(date +%Y-%m)", "end":"$(date -d "$(date +%Y%m01) +1 month -1 day" +%Y-%m-%d)" }, "query":"query (\$app: String!, \$start: ISO8601DateTime!, \$end: ISO8601DateTime!) { app(name: \$app) { organization { billables(startDate: \$start, endDate: \$end) { edges { node { app { id } category quantity } } } } } } " } EOF ) curl https://api.fly.io/graphql \ -H "Authorization: Bearer $(fly auth token)" \ -H 'content-type: application/json' \ --compressed \ -X POST \ --data-raw "$QUERY" \ --silent | jq '[.data.app.organization.billables.edges[].node | select(.app.id == "'"$1"'" and .category == "data_out") | .quantity] | add'

EnKopVand 4y ago

I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it. Things like alerts are fine, professionally, but not for things like running a small app, blog or whatever, that you’re not sure where is heading. I don’t think anything I’ve build on my own time has ever ended up breaking my bank, but signing up my credit card is a risk I’m never going to take, and I’m fairly certain I’m not alone in that. Of course I have no idea if there are enough of us to make small scale fixed prices products profitable at scale.

mrkurt 4y ago
We actually launched with that feature: https://news.ycombinator.com/item?id=22616857 https://news.ycombinator.com/item?id=22616857 No one took us up on it. What we found is that the majority of people want their stuff to stay up, and the right UX for "shut it down so you don't get billed" is not obvious. We ended up implementing prepayment instead. If you sign up and buy $25 in credit, we'll just suspend your apps when the credit runs out. Bandwidth is weird because we have to pay for it (as does every other provider). We aren't yet in a position where we can just make it free without limits. Maybe next year. :)
- brundolf 4y ago
  I can't speak for your whole market, but I know for me the pre-loading flow sounds really clunky because I'd have to go and manually add funds each month (right?) It's understandable if your usage data showed the fee-capping feature just wasn't popular enough to be worth maintaining, though that would surprise me based on this thread (but possibly HN just isn't representative of the whole market)
  - ceejayoz 4y ago
    I’d be happy with a “refill if under $10 up to $x/month”. If they can cut off when you’re out of credit they can presumably do it for other criteria, too.

bsder 4y ago

> And a bit of an own goal on our part. More than a bit. Simply give people the option to put a charge limit and let the app be offline when that limit gets hit. Don't make it the default, but do allow people to do it. This would resolve 99% of the fear people have. And most people wouldn't set the limit anyway. However, your knowledgable people might set it, and those are the ones you're most trying to attract.

ryantgtg 4y ago

I might be in the minority here, but I don’t have the slightest clue what my monthly bandwidth currently is on heroku, and so I can’t estimate what Fly will cost. Um, how do I find this out? Preferably historical usage.

flurdy 4y ago
I only found out my bandwidth after putting cloudflare infront of my apps as they email a monthly bandwidth saved report.

JohnBooty 4y ago

I don't want unlimited bandwidth (I mean, it'd be nice - but I realize it costs money) -- I want predictable pricing and spending caps for my personal projects. If I can't have that, then I just can't take the risk of my site getting hammered (by attackers, getting linked on HN, whatever) and racking up some kind of bill I can't pay. I realize the chances of that are small but that's scary. I realize that, obviously, "stay up at all costs" is what a business needs and that's where the money is. Fly.io won't get rich off of personal projects. But, I do think they serve to get developers onto the platform. Your bandwidth allocations and rates seem very fair and generous, btw. I do really want to check out your platform.

phamilton 4y ago

When I worked in adtech (Brightroll) we hosted a segment mapping server on heroku. All it did was look at a url query for the target url, append a value from a cookie to it, and 302 to that url. The value in adtech is that I can tell you which segment a user is in by taking the data in my cookie and appending it to your url. We launched it on Heroku using Nodejs and sent billions of requests a day to it. The thing ran on like a few dozen dynos, but it was responsible for like 20-30% of all of Heroku's bandwidth. Fantastic value for us. Immediate headache for Heroku.

weird-eye-issue 4y ago

Do you hate Cloudflare?