That's fine for a lot of use cases, but the unit economics of the per request pricing model means it's really hard to operate a predictably sustainable (i.e. profitable) business without also charging our customers on a usage basis, or enforcing limits on usage, neither of which is ideal for maximizing engagement as incentives are no longer aligned.
Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests, and gives us freedom to serve as much traffic as we can min-max onto those resources, like we could with traditional cloud compute.
This provides much better unit economics for many kinds of applications, at the cost of having to manage the scaling ourselves. But because the option exists, we can make this tradeoff on a case-by-case basis, which is so much better than if all we had was "serverless" stuff at the edge and had to choose between just low latency across the globe vs good unit economics.
I am not sure if I'm missing something or what, but here's where I looked:
* googled 'docker fly' and a blog post that references docker but as far as I can see doesn't have instructions on deploying docker images shows up[1].
* their getting started guide[2], called a 'speed run' which has all kinds of CLI commands but doesn't actually show how I'd pick a docker image.
* their quickstart docs[3], which outline how to deploy all manner of applications, except for, you guessed it, an existing docker image.
* scanned the menu of their docs, and didn't see anything.
What the heck am I missing? Can I just not read? Do I just need to install the CLI and all shall be made clear?
0: https://fly.io/docs/introduction/
1: https://fly.io/blog/docker-without-docker/
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.
Based on your first link [0], I saw,
> You can run most applications with a Dockerfile using the flyctl command.
With that, I looked over the left-side menu, and clicked `flyctl`[1], since it seems that's what you'd need to use to deploy an existing app with Docker. After that, I clicked on "Launch an App" [2], which shows help for the `flyctl launch` subcommand, including a parameter `--dockerfile`. I think that's how you would deploy an existing app with docker?
[0] https://fly.io/docs/introduction/ [1] https://fly.io/docs/flyctl/ [2] https://fly.io/docs/flyctl/launch/
Workers Unbound is $1 for ~6.6M requests (+ runtime at $0.0000015 per sec / $12.5 for 1M GB-sec). That's super cheap considering free egress, which brings me to...
> Fly just gives us compute at the edge for a predictable price per unit of actual compute resources as opposed to requests...
Fly.io may not meter requests anymore, but they continue to meter egress, even between your VMs in the same region [0]. Usage-based price model is everywhere, like it or not.
[0] https://community.fly.io/t/do-traffic-over-6pn-within-the-sa...
I don't really want to promise anything we haven't shipped yet. But my perfect cloud service (a) charges me when VMs are alive and (b) gives me the tools I need to create/remove/stop/start/suspend/resume VMs based on either network activity or metrics.
One flaw of Fly.io right now is that it's relatively expensive to run a side project in 10+ regions. Most apps benefit from 10+ regions, but $50/mo to try it out is prohibitive. We want to make this more accessible.
The praise on the subject of predictability is interesting, given perennial concerns about uncapped vs capped usage charges (with any cloud provider), but esp. in light of past Fly-specific comments that "putting work into features specifically to minimize how much people spend seems like a good way to fail a company".
My comment could have been better. Our business model is predicated on making it cheap to use services and easy to incrementally scale up. We probably won't build features to cap usage of things directly, but it makes total sense to deactivate apps when credits run out.
If you know them well and their usage patterns, you can predict with confidence how much each customer will cost you. With granularity to the level of a feature or even a particular action.
This allows for extremely precise and safe unit economics planning. I couldn't be happier with this benefit from serverless.
In a server-based infra you have many fixed costs: servers themselves, unused capacity, and your time to maintain it, which is certainly expensive, since it competes with attention to the product or maybe sales and customer support.
Google APIs OTOH... I went from $0/month to $450 the next because of their stupid per-unit pricing and hidden API calls.
They’ve got Chris McCord there, who has already improved their Elixir deployment story. I tweeted a few weeks ago about improving the default Rails deployment experience to not require DB provisioning and configuration of env vars like SECRET_BASE_KEY and they said it would likely ship within the next 3 months.
My hot take is they’re setting themselves up to ride the server-side rendered HTML renaissance we are experiencing with LiveView and Hotwire. It will become much more important to deploy applications geographically closer to customers to lower latency, which Fly makes sane for the rest of us.
But we aren't yet ready for that piece.
Fly.io was still very beta when My startup was launching. if we were creating out deployment now, fly.io would be top of my list.
Is some shady ISP colocation as safe as highly secured AWS and Azure data centers?
Fly is edge in the sense they have hosts in N regions and manage the anycast for you so traffic seamlessly routes to those regions. They don’t publish which data centers they operate in only the regions (https://fly.io/docs/reference/regions/) but most of those regions line up with equinix data centers which are all physically secured professional facilities.
It’s a great question though and one they should have a document about.
Would love to understand better how to deploy Rails with fly and still benefit from multi-region/failover/scaling
p.s. horrible nitpick, but I think it’s SECRET_KEY_BASE :)
We have a Gem to make it almost transparent: https://github.com/superfly/fly-ruby
I’m not a Fly.io customer (although more and more I am thinking I should be), but I eagerly read every new blog post because I’m so entertained by their tone. These people are clearly having fun at work.
Have you thought of hiring a technical writer? Think of it as a work-stealing algorithm if that helps :-)
No fancy buzzwords, to the point and speaks to things we all know are true but are typically not addressed or are wrapped up in spin. The first and last paragraphs are great examples.
The authenticity of it leaves me with a strong sense of trust and respect.
> The free VMs themselves are just a bit of memory and some idling CPU, but the state is obnoxious for us to manage.
> But here's what happens if you give people freemium full access to a hosting platform: lots and lots of free VMs mining for cryptocurrencies.
If I had to put words on it, I would call it "transparency" and "treating their public as adults/with respect". I know that free storage is hard to find because disk space is harder than CPU and RAM to manage for them. I know that I need to put my credit card because people will abuse the free tiers for crypto if they don't ask for a credit card (sourcehut had the same problem with their free CI). I don't feel like they're trying to hide something from me, even if they still wrap it in some fun. This is the behavior I would expect from a good collegue.
2010?
I'm so glad to be seeing someone do this, because for a while it was looking like nobody would - and as long as nobody is doing it, nobody would have to.
Now with Fly increasing in popularity, you have to expect that others, Cloudflare in particular, must be seriously looking at integrating more 'centralised deployment' tools like postgres into their edge platform too (if, to be fair, they didn't already have this on their roadmap), providing more options and competition.
> Even for our free services, we require a credit card number. We know that's the worst and it gives you heartburn. It's not because we plan to charge you.
> But here's what happens if you give people freemium full access to a hosting platform: lots and lots of free VMs mining for cryptocurrencies.
> We could tell you we want to prevent crypto mining because we care about the planet, and that would be true. We also have a capitalism nerve that hurts when people spend our money gambling. Your credit card number is the thin plastic line between us and chaos.
I don't really have another alternative to offer here, but i appreciate the transparency and honesty of saying this, regardless of whether they're right or not.
I wish more companies out there actually explained their reasoning behind decisions, instead of essentially just going like: "We're doing this because of undisclosed reasons, please accept that this is how things are going to be."
Of course, in many cases you can come up with a few feasible reasons for why companies make many of their decisions, but being given first hand context for these things feels nice!
Even if you catch all just having them try will be a huge waste of resources.
Repeat with every other trick you use to detect abuse.
Very earnest.
Also do you have any plans for a managed upgrading/patching of Postgres, again similar to Heroku?
For me personally the fully managed nature of Postgress on Heroku is brilliant and what I would love to see on Fly.io. It seems that on Fly its a little more hands on or am I missing something?
0: https://fly.io/docs/getting-started/multi-region-databases/#...
1: https://devcenter.heroku.com/articles/heroku-postgres-data-s...
We will be able to do a WAL backup / point in time restore feature when we ship object storage.
Managed upgrades are almost in. If you run `fly image show` it'll tell you if you need one, then `fly image update` will upgrade your Postgres. We don't do this automatically yet. It won't be difficult though.
Brilliant! I have only had to use it once on Heroku, but that one time has me convinced that I couldn't live without it.
I must say the deployment experience was great, stuff just worked, brilliant.
One question in case someone tried that: How can you customize the postgres config? I want to enable pg_stat_statements, and one needs to add `shared_preload_libraries = 'pg_stat_statements'` to the config for this. One could also make this the default maybe? It is the default on most cloud providers (AWS RDS, Digital Ocean).
Check this out:
> Fly Postgres clusters are just regular Fly applications. If you need to customize Postgres in any way, you may fork this repo and deploy using normal Fly deployment procedures. You won't be able to use fly postgres commands with custom clusters. But it's a great way to experiment and potentially contribute back useful features!
Since fly deploys at the edge closer to the users, our response times for notifications are 20ms on average which is mind blowing since I haven’t spent more than 1 hour on infrastructure setup.
It was a bummer. Everything seemed great, I just literally couldn’t use it.
I’d love to hear others experiences with the PG features. I could see it replacing Digital ocean for my use cases (if it works reliably)
We know this because we have metrics on how many people created and then destroyed Postgres DBs without successfully connecting an app to them. When we show this to investors we'll explain that the improvement was a big win for our "go to market efforts". But you should know it was really just a bug fix for something we disappointed you with.
That made me chuckle :)
I encountered some of those same postgres issues and so far have been only running a staging database on Fly. This comment is motivation for me to finish moving my real DB over from google.
P.S. I was running my own fork of your postgres container so I could include postgis, and this probably made management even more brittle -- I'm really happy to see https://github.com/fly-apps/postgres-ha/pull/44#issuecomment... landed!
<Picture of a large desk fan>
https://www.cockroachlabs.com/pricing - 5GB, 250M "request units"/month (distributed, PostgreSQL-ish https://www.cockroachlabs.com/docs/stable/postgresql-compati...)
I was not aware of the other portions of the free compute tier from Fly.io, was looking into Oracle Cloud. (Ask HN: What cool stuff do you run free-tier? Sep 2021 https://news.ycombinator.com/item?id=28652736)
We want people to try a read replica. We only provision volumes down to 1GB. 3GB sounds better than 2GB.
Sometime soon we'll cross the threshold of relevance and you'll just use Supabase or Cockroach on Fly. They're great f'n products.
If I outgrow the $154 plan I have to jump to a ~$1300 plan.
Is this right?
Postgres prices are a function of the underlying resources. There are a bunch of steps between $7 and $28, you can put any size volume you want on your Postgres cluster and run 512MB or 1GB of RAM. 1GB RAM + 10GB volumes would be $14.40, for example.
Dedicated CPU VM types are much more powerful than the shared CPU. So the jump from $27 to $154 gets you, like, 20x the CPU power. I would like to have shared-cpu-2x, 4x, and 8x to give us a better cost gradient. So far it hasn't been an issue, though, people seem to want the extra CPU for a beefier DB.
Granted, I've only handled small - medium sized infrastructures, and never really experienced the issues at scale, but if I were to get to that point, wouldn't it be easier to just hire a Infrastructure Engineer who could deal with the replication / sharding, not to mention having that engineer also deal with site reliability and dev ops?
If a user wants to hit my service, and then that service has to hit fly.io's postgres, isn't that an increase in latency? sure I could probably have it pretty darn close, but 20-100ms is still 20-100ms. I could manage my own (or hire someone), and have the db live in the same container (if i have a big enough box), or have it within the same data center.
And if it is the case that I do need to replicate across data centers, at that point, I should have the financial capabilities to hire an infra engineer.
Can anyone enlighten me why I would ever need this?
That said, you can go very far with stateless apps at the edge with regional read replicas and a single write instance that's half way across the globe.
You can replicate across datacenters on Fly.io for free. No infra engineer required. And very little code change required: https://fly.io/blog/run-ordinary-rails-apps-globally/
If you need to do that at least have a way to limit spending (by closing services when overspend occurs) and tell me that exists when I sign up.
Hobbiest nightmare is to owe $10k because of a silly mistake. It is why I closed my AWS account (as well as it being too enterprisey to use for hobby).
EDIT: I just read [0] you ask for CC because of crypto miners. Why we can't have 'nice things' I guess :-). I suggest a way to limit spend then, or say "only free services for now".
[0] https://fly.io/blog/free-postgres/#a-note-about-credit-cards
Many workers I've seen (or written) start by reaching out over the Internet to another backend. There goes most of your edge benefit almost immediately.
1. Provision your DB
2. Add regions
3. Add our Ruby gem to your Rails app
4. Deploy Rails
5. Set the same regions for the Rails app
And it just works. Phoenix is close but we haven't quite polished up the Hex library yet.
I think being transparent about regions is a feature! We can definitely automate most of those steps away, but the region you're running in will never be obfuscated. CDNs are _notorious_ for placing content and features where it's cheapest for them and I think that's gross.
Whether we can make it free or not is an open question. Ultimately there's a cost to storing a bunch of redundant data. We have ideas for suspending and resuming read replicas, it's just complicated!
At the moment we're a pretty good place to deploy your full stack app for free. And we're a very good place to cheaply run a full stack app in multiple regions.
Is it because you need to be able to defer responsibility to a legal entity of the EU?
But, is there a reason why the minimum size of a storage that can be provisioned is 1GB? Last I checked, a provisioned storage cannot be shared by multiple apps, so I had to always create an overprovisioned storage when creating a small app, leading to a waste of money. Is it possible to share a PostgreSQL instance instead?
This free tier of database will make it easier for everyone to test the waters at Fly.
Where do you store user uploaded content?
..The primary exception to this being if you absolutely have to normalize your data (with key constraints), or need the transactional guarantees of a database.
Could a payments platform like Stripe build a one-click "Freemium powered by Stripe" button ala OpenID, so that these services may free-tier in a friction-free way?
This article is about providing IaaS for free, and isn't that anti-competitive? The big cloud providers and Heroku do it, and I think it makes it a bit harder for OVH, vultr, hetzner and others who don't provide freebies like this.
People spend a lot of money on infrastructure when they use it in anger. Free apps cost us ~$0.50/mo. If we can sift through 1,000 free users and find one who converts to $25k per month, we're delighted.
Does this ever happen? I was contacted by a F500 who needed some custom version of my open source project (https://github.com/mickael-kerjean/filestash). 25k sounds unreal but hey I have no experience in purchasing enterprise grade software and it's not simple to find actual figures so I was aiming at making an offer at 2.4k/month. Is it a rock bottom figure in enterprise grade software?
> Managed SSL certificates
> We use Lets Encrypt to issue certificates, and donate half of our SSL fees to them at the end of each calendar year.
> Single hostname certificates > Free for the first 10 > $0.10/mo for additional certificates
> Wildcard certificates: $2/mo
So, if my pet project needs a wildcard certificate from the get go, I go from $0/month to $2/month before writing a single line of code... can I at least run acme on my own to cut this expense, or this is prohibited?
Actually, to think about it.. Let's Encrypt is free. Is charging for it a significant revenue stream? I would love to see the rationale for that, because it seems to me that this hits small customers disproportionately.
One genuine question from someone with no context into their product: does Fly lock me in by barring access to WAL replication? This is something Heroku does that is extremely annoying as you'll grow and grow with them and one day you realize migrating the data will be a massive hassle.
RDS preventing external streaming replicas is the most annoying thing ever.
> But here's what happens if you give people freemium full access to a hosting platform: lots and lots of free VMs mining for cryptocurrencies.
You could also permit people to make a cryptocurrency bond deposit to get a free account, which is forfeit if their account gets terminated by you for abuse. Payment cards are strongly linked to government ID in the USA, sadly, which means that presently someone has to effectively dox themselves to you to get a free account.
PS: Please increase the contrast of your body copy. Light grey on white is hard to read even with good eyesight.
In any case, an extremely generous free tier.
Hmmm
Even vercel doesn't have a database layer. Fly.io again gives VM - not an managed app layer.
Are we not counting the major public clouds as “app deployment platforms” now?
Is our business data as safe in some shitty ISP colocation as it is in highly secured AWS and Azure data centers?
sudo apt-get install postgres
Seriously though, who is this for? Any backend hosting platform offers a database. It's just a standard at this point. For people hosting static gihub pages (and storing all the database connection credentials in frontend js?!), don't make me laugh. Or you've already got your own vm? Then literally just install postgres right there.
It brings them, more or less, to feature-parity with Heroku. If you cared about the differentiators for Fly (which, at a glance, seem to be better support for global reach and Docker, and less fiddling with Postgres) but were kept away by their lack of database on the free tier, now you probably want to give it a spin.
If you don't care for Heroku-style deployments, because you're happy managing your own infra, then this is not for you.
"fly launch" on a Phoenix app, for example, gets your entire app + DB deployed in about 60s for free.
I hate it when time travelers pollute my news feed.
1. You get your own Postgres proces and disk, no shared database instances 2. Private networking is baked in. Your app talks to postgres over an encrypted private network 3. You can provision persistent disks and run basically anything you want 4. We support arbitrary TCP and UDP services, not just HTTP.
We're also substantially cheaper.
I like cryptomining, so it doesn't help my adoption of them.
Thanks for the free services.
I agree I'm thinking also making people pay for stuff is important. It's hardly like fly.io don't have a good reputation, I trust them and it does seem reasonable requirement to help them stop people destroying their platform with crypto mining!
BTW, if someone knows of an HONEST company that provides online fax US numbers (Damn you IRS) I am all ears.
Hmm.. not sure if I want to install something to use this.