I'm so glad Fly exists. Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request.
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.
For a company that says it makes it super easy to deploy a container image and mentions that all you need to do "Write your code, package it into a Docker image, deploy it to Fly's platform"[0], they sure have a dearth of documentation on how to deploy an existing docker container.
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.
I really want to like this service, as we have (at $CURJOB) an app packaged as a docker image that it'd be awesome to set up to run on Fly.io, especially with the multi-region postgresql.
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?
You know, you're not really missing anything, we just don't connect the dots very well.
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.
I just did this with an application I haven't touch in years. The deployment worked on the first try. A few clicks and I had TLS certificates. I'm sold!
Out of curiosity, why target Phoenix users as your primary audience when you serve generic Docker users easily as well, given that they're likely a 10x or more segment? Are you just marketing to a tighter target audience to start, or is your platform/UI specifically optimized to support Phoenix?
We started with generic Docker! The Phoenix focus has been very helpful, though. Docker apps are incredibly broad, other than "it's really easy to launch a container", it's hard to define why we're especially good at Docker containers.
With Phoenix, we can say: run your fullstack Phoenix app on Fly and your users get sub 40ms responses from LiveView. When responses are that fast, you can write less code and still build really dynamic applications. And we can give those devs a really nice launch experience: https://twitter.com/chris_mccord/status/1468998944009166849
We're getting to the point where we can expand this focus. The infrastructure works great for many types of apps. The launch UX could be good for every full stack framework with enough people.
The Phoenix guy works for them, so I'm sure they have a lot of organic interest from Phoenix users. It's like how you don't have to use Next.js on Vercel, but…
If you have Docker running locally, it does a local build and pushes to our registry. If you don't have docker running locally, it launches Docker on our infrastructure, sends it the context, and does a remote build.
You can control this with "fly deploy --remote-only" and "fly deploy --local-only". Don't use both, it might cause a paradox.
I’d really recommend adding a section to this* page something like “existing Docker containers” ! I would not have found out that it’s possible based on your current docs layout.
Also, I noticed that the Speedrun page a) in step 3, doesn’t tell you to CD into your source code directory before running the launch command to autobuild, and b) is missing links to all the autobuild supported languages
We have no ARM plans, but a strong desire. The really good ARM stuff is locked up within Apple and Amazon, though. I'm really hoping an independent chip vendor ships a compelling and broadly available ARM platform we can use for servers. They all keep killing their products. :/
Are they killing their products due to lack of demand (which seems odd, given the cost/benefit), too much competition from Amazon, running out of money vs. ramping up sales, or??
I just googled and it looks like the Ampere Altra is shipping in some rackmount configs? (Vaporware?)
Any chance of getting autobuilder support for Rust? :)
What about same for .NET?
(and I suppose some people would care about Java,Kotlin,Swift ;)
I don’t have to deal with containers with my current infrastructure, and it would be nice if I didn’t just to be able to use Fly—I find containers to be a PITA.
Yes there's a good chance for all of these! You can post on community.fly.io if you'd like and get a headstart. People have prebuilt Dockerfiles laying around for everything (and we have lost of Rust stuff).
We use Dockerfiles kind of like make files. Once you have one that works, you don't need to think about it anymore.
You're right, they should make that much more clear. I'd expect it to be on the left side menu, just like they have all the "Run a [language] app".
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?
> Every other edge focused thing out there I'm aware of are "serverless" which these days basically means they charge per request.
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.
We don't bill for internal Postgres bandwidth anymore. Bandwidth in general is a good point though. No one _actually_ offers unlimited bandwidth. We haven't figured out how to be transparent about bandwidth costs AND check that box for people yet, though.
Cloud Flare's model is to give you "unlimited" bandwidth with restrictions on how you can use it. If you do any kind of volume you quickly get a call from a sales person who wants to sell you enterprise. And then you end up paying a relatively high per-GB price as one big enterprise contract.
They're reasonably transparent about this, and I think it's fair. It's just not how I prefer to buy services.
At no point will we call you up and try to get you to spend more money to keep doing what you're already doing.
We are pushing xxTBs every month at this point, and I haven't got the call yet. I'd have to spend $yyyy dollars on Fly.io for that kind of bandwidth. By simply moving to Unbound last month, we even halved our bills, and with some planned software changes, bills should go down another 30%. Besides, Matthew Prince says pushing higher bandwidth via Workers is fair game [0].
That said, I very much prefer Fly.io to AWS for workloads not suitable for Workers... and in just these past 3 months, we committed eng resources to make sure Workers workloads can run on Fly.io too, if and when the time comes for an instant migration.
We also run workloads on AWS AppRunner and Amazon Lightsail Containers and that's only because S3 <-> EC2 bandwidth is ~$0. We'd definitely move to R2 once Cloudflare opens it up, and we hope, eventually, Fly.io reaches the scale to peer directly with Cloudflare DCs for lower latencies, if nothing else.
Is pricing page updated according this news, seems not to me?
Can I please also know how PG clusters are run at the edge? Docs is not very informative about how things work under the hood(ie. infrastructure / deployment).
This is true, but we aren't going to bill per request. We really can't, since we support arbitrary UDP and TCP services.
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.
Docker also seems like the quickest option to come out of AWS (ie, ECS or friends) and try fly - so I'd continue chasing a bit of a docker story if you could (even just in docs -> getting going with Docker).
The nice thing about mapping peoples apps to overpowered hardware is that it flattens bursts. We need capacity for, say, 10% of apps to burst at any given time.
The nice thing about spreading hardware around the world is that we have excess capacity wherever it's dark. If you're doing latency insensitive work like batch jobs, we can schedule it somewhere that would otherwise be idle.
Aggregate capacity is smaller than the sum of the individual apps capacity requirements. So we both benefit.
Can you scale each region based on usage i.e. have a huge server in US or Europe and a tiny one in a market you don't have many users in? fly.io is really an incredible piece of work, I'll probably just default to it as I am a massive Elixir fanboy :-)
As others have said $50 seems a very low starting point but if you can make it cheaper why not, just means you've helped more people onto your service and they will grow with you.
Autoscaling and balancing regions is something we launched with, but it ended up not making much sense. Our load balance sends traffic to the next nearest region when an app is too busy. It's usually better to spread capacity around to lower latency for users, and then eat the additional latency when a region gets overloaded.
In most cases "the next nearest region" is less than 15ms away.
I don't fault you guys for being a growing startup (we have all been there), but it would be awesome to have a way to flag an issue as "email me when this is fixed so I can come back."
You're not crazy! We still don't do v6 UDP (there's no good reason for us not to, but it'll be a week of rebuilding a BPF engine while the plane's still in the air, so this task never hits the top of our stack and won't until someone really pressures us on it). Full honesty! That's how we roll on HN. :)
> it's really hard to operate a predictably sustainable (i.e. profitable) business [... with other providers]. 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
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".
We ended up shipping a "cap your costs" feature, we just did it with prepaid credits. If you buy prepaid credits instead of adding a credit card to your account, we can't bill you more than you've prepaid. The downside is that you have to prepay $25 to use anything at all.
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.
Serverless pricing model doesn't have to be transferred to your customers.
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.
Kubernetes on DigitalOcean scales pretty well.. fixed monthly cost. If I run out of capacity I just add an extra node or switch to more powerful nodes. Kubernetes takes care of provisioning the nodes.
Google APIs OTOH... I went from $0/month to $450 the next because of their stupid per-unit pricing and hidden API calls.
If your server administrator doubles as your sales person maybe but for most companies these are different roles and you need someone to manage your fly.io account/docker image or your aws account. Sales, customer support, legal, marketing should be affected. If you are a one man show that's a different conversation.
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.
We're betting the same, and Fly.io doesn't know it yet, but part of our solution will eventually be made possible (much easier) thanks to their architecture. :)
Fly isn’t really edge in the sense that they are colocating with lots of ISPs like Netflix might for video at the edge.
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.
We should do better documenting security across the board, but I keep getting drawn into i.e. months-long DNS optimization problems. This'll get done this year, though.
It's an interesting idea to assume GETs will do no writes, as opposed to POST/PUT/DELETE and route them via middleware, but as an app developer, you need to be very mindful of any updates I suppose... replication delay can also create some weird scenarios I imagine...
That's all solved. We catch readonly errors from Postgres and issue the replay. Preemptively sending a POST to the primary region is an optimization, it works fine without doing that!
Replication lag is handled too in the Ruby library we pin requests to the for a few seconds. In our Elixir library, we actually monitor the read replica directly and reroute writes until it's caught up.
I understand roughly what the gem does, but you still need to be aware of it with your app. For example, if every request updates some activity stat, or the last page the user was on (which happens with some apps), you instantly lose pretty much all the benefits, right?
Ah I see what you're saying! You're basically describing our experience trying to run Discourse. Weirdly, naive, less complicated Rails apps work better multi-region on Fly than mature grownup Rails apps.
We use sidekiq + Fly in a single region with the primary database, and then write to the Redis from other regions asynchronously. It's a good time in Ruby world, I think Ruby 3 will simplify a lot of the weird background work people do.
Ruby 3 will definitely help us solve the problem of gets that do writes for stats or history, since those things can be done async. You can do a little of it now just by spawning a thread and writing the the writable Postgres in the background.
> We've had a free tier since we launched ten years ago (in 2020).
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.
This is a sort of content-free comment, but I'll say it anyways because it's been gnawing at me for months --- there is a lot of content queued up for us to write about; just a freaking avalanche of stuff we've been working on. I keep looking for places to break it off and start writing about it, and the work keeps growing and foiling our attempts.
I also like the frankness and simplicity of their communication style.
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.
Yeah, that's the important part for me. The "fun" part about the sandwich app is nice, but the part that differentiate it from other content is stuff like:
> 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.
Really enjoying watching Fly develop. Not sure if I have read the strategy right, but my read is that they are going for an edge 'OS' which is compatible with the way software is already built for the centralised deployment model, where other players are going with a strategy of inventing a new 'OS' and saying, pretty much, 'all this edge goodness is available, but you have to rewrite your software to run on our OS first'.
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!
It's not just miners, you also have people using your free or even cheap tiers for DDOS/PortScan/SSH Bruteforce. These ones burn your IP address so it's better to prevent it than to try to catch it later. A credit card check goes a long way as a barrier to entry.
As long as it is free miners will keep trying to get around it by for instance running tons of different free accounts each with a obfuscated mining system.
Even if you catch all just having them try will be a huge waste of resources.
Sure ... look for high CPU then anonymous miners cap their CPU usage. And a few legitimate users (and potential customers) get locked for reasons they don't understand.
Repeat with every other trick you use to detect abuse.
To the Fly.io team here, other than the "daily storage-based snapshots of each of your provisioned volumes"[0], is there a plan to offer something similar to Heroku WAL based restore system [1] where you can (from the control panel) restore a db to a moment in time?
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?
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.
I tried to deploy an application I currently have running on Digital Ocean App Platform (their Heroku competitor) also on fly.io. The app is using Python/Django and Postgres, ideal to test.
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).
> 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!
As a founder, there is no company the same age as mine I am more jealous of than fly.io. Looking forward to moving one of our products over to fly as soon as time allows :)
Oh goodness I love KubeSail. Before Fly.io, I really wanted to build a self hosted alternative to Google Photos. I think what you're doing is incredibly valuable.
I’ve been using Fly for my new startup that offers notifications as a service [1], and the whole setup is super easy and efficient.
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.
Recently, I gave Fly an honest go for a new multi-container project that seemed like a good fit. After digging in, I found that the pg clusters had some sort of system wide bug and couldn’t be attached to any of my apps.
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)
I'm sad this bug burned you. We had some brittle infrastructure for talking into a Postgres cluster, and it was a bit of a fire drill to rip it out and simplify. You would have a better experience if you tried today!
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.
> 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.
For comparison, note also that ElephantSQL offers 20MB databases on their free tier with 5 concurrent connections. They charge about $20/mo for the tier that Fly is offering here for free.
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 2021https://news.ycombinator.com/item?id=28652736)
The jumps in prices for Postgres seem pretty high. The next step up from $7 is $28(4x). After that it’s $154(5.5x), and the next step up from that is $1266(8x).
If I outgrow the $154 plan I have to jump to a ~$1300 plan.
Not quite, but pricing is a little complicated AND we haven't shipped multi-shared CPU VMs yet.
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.
I'm having trouble understanding the purpose of these edge services.
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?
Hiring a (good) DevOps or infrastructure engineer is harder and more expensive than you might think.
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.
I had not heard of fly.io but i really appreciate free for side projects! I have a docker setup for .NET core psql app on digital ocean so will be fun to see if i can get a that working with you. Also pricing at a quick glance seems good. Are you running your own servers or using another cloud as the basis?
We run our own servers. It took a lot of work but it's really making life easier now. I'm not sure we could offer a free tier like this on top of another cloud.
Thanks I just signed up. Just my opinion but asking for a CC off the bat is friction.
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".
Free tier of CloudFlare Pages/functions runs the app at the edge by default. For Fly.io, this scaling has to be manually configured for both the app and the DB. Are there any plans to offer it by default for the free tier? It is hard to evaluate the benefits of having the data center near the end user when it is not offered out of the box, especially since all the Fly.io blog posts talk about how great their service is for HTML-over-the-wire UIs like Phoenix live view and Rails Hotwire.
You can squeeze a hell of a lot more perf out of general purpose compute that is maybe an extra 15 ms away than one-shot workers lacking any in-RAM persistence, or ability to do much more than limited local k/v lookups. The equation is totally different.
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.
We'd like to automate this! We've made it nearly transparent for Rails apps, and almost as transparent for Phoenix apps, but there's a lot of work to do. Right now with Rails you:
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.
CLOUD ACT is the problem. Even for data stored outside the US, authorities can demand access to data. This is why for example in the EU you are a customer of AWS SARL in Luxembourg instead of AWS Inc.
This is huge! Kudos to the team for their commitment.
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 reminds me of the days where every popular PHP+MySQL application had an option for a table prefix, so multiple applications could live in the one databse provided by your classic hosting provider.
We are going to migrate to Fly.io very soon. We are very excited about the prospect of Elixir, Phoenix and Liveview running close to our users with NONE of the javascript headaches. I've hit the eject button on javascript and won't be coming back.
This free tier of database will make it easier for everyone to test the waters at Fly.
IMO, small projects most often do not need a database. It is much simpler to serialize to a binary encoding and read/write to disk. I have several small projects, even some with > 100GB of data, that use this approach and it is very nice. I even have login/out without storing user data at all (yes, it is possible).
..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.
Someone give this writer a raise :D "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."
> 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.
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?
The real problem here is just abuse, and Stripe has abuse detection products. We have a lot of 2022 goals, but any list we've made in the last quarter would have included "get rid of the credit card prompt" in the top 3. So, yeah, something's going to happen here. We hate the fucking credit card prompt.
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.
I don't think we lose much sleep thinking about how hard we're making things for OVH, which booked over 600MM $EU last year. But we're flattered that you'd think that. :)
Curious as to the motivation for this. I've never heard of this company, but the pricing page says the cheapest PG cluster is $6.88 per month. Is that enough to keep their target customers from using their service?
It's an attempt to reduce friction. Developers try services like ours out for fun before they use them in anger. Putting a price on the fun stuff keeps people from trying it. It's not that $6.88/mo is too much, it's that >$0/mo is too much for developers who are used to their side projects being subsidized by monopolies or VCs.
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.
> 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?
For _our particular service_ this happens, but that's partially because the service is designed to scale to very large customers and the market has set a price for cloud computing resources. Companies already spend money on infrastructure, we're not having to convince them to do that from scratch. We do have to convince them to point that firehose our direction.
What you're doing is more difficult. In general, big companies will spend $10k per month as easily as they'll spend $2.4k per month. It's equally difficult to convince them to do either.
Does filestash get used by multiple people in an organization? If I were trying to price this, I'd invent a "per user" price and target $500/mo for small organizations (like $50/user). Enterprises don't love per user prices that scale, so it gives you a story for "we'll give you unlimited users for $10k per month".
I am more than happy to talk more about this if you want to send me an email, but I'm mostly guessing about OSS licensing. I haven't done the work for real.
> 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.
The infrastructure to manage and distribute certificates is pretty complicated, and doing support for certificate issues is expensive. This is why we bill for them. More details here: https://news.ycombinator.com/item?id=22624262
For people who need a whole bunch of certificates, the price hasn't been an issue.
The problem with services that are free at any scale is that there's never an incentive to make them any good. Most of our certificate infrastructure improvements have been done because people who were trying to give us money were having a hard time of it.
Fair enough. Indeed I didn't consider support costs. Thank you for your answer!
Actually let me ask another thing. Your FAQ mentions you're considering hosting CockroachDB as a drop-in distributed replacement for PostgreSQL [0], and also you currently offer a distributed, eventually consistent PostgreSQL replication solution [1].
Is either Tikv [2] (distributed key-value store) or Tidb [3] (distributed database with a mysql interface, built on top of Tikv) on your radar?
You already offer Redis as a key-value store, but Tikv has an amazing property: it ensures strong consistency globally (not eventual consistency). Tidb, being built on top of Tikv, also has strong consistency.
I just deployed a side-project to fly.io. I cannot really say anything about the multi-region capabilities since it is single-region so far, but I must say the domain setup and certificates is really smooths
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.
We do not! You have full administrative access to your postgres. You can create offsite replicas, or even fork the Postgres app we use and deploy over your Fly.io installed postgres: https://github.com/fly-apps/postgres-ha
RDS preventing external streaming replicas is the most annoying thing ever.
You can run a bare Postgres (or any other db for that matter) app on fly with any settings you want. It won’t be wrapped in their nice cli command but it will work.
Fly's developer experience is really sweet.
Do you have plans to open up your API for provisioning on the fly?
We've use-cases which require dynamic provisioning of new deployments as well as mutating existing deployments based on APIs we offer to our customers.
Very cool, I've always recommended Heroku's free postgres to people looking for a good hosted db to start with for small projects - nice to have competition in this space. A flat 3gb is very generous compared to 1gb/10k rows that Heroku offers.
Including free storage in the free plan is a good strategy. Aside from small projects, I bet it'll make it much easier for people looking to host their production workloads to try before buy. Love this!
> 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.
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.
so when i say app deployment platforms, maybe im not wording it right . like vercel. you dont worry about deployment - u just push nextjs code. that kinda thing.
AWS has some of the most secure data centers on the planet, so I'd hesitate to draw comparisons, but we're mostly at Equinix, which is no slouch on physical security.
AND you actually get sole control of all the data, all without the need for a credit card!
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.
We're different, but only because we were builtin 2020 instead of 2008. Notably:
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.
Though as part of the signup I'm asked for a credit card. So it's not really "free". It's for credit card users only that need to trust they won't charge you.
I believe they address this on the last sentence of the blog as a measure to prevent abuse on the free-tier they ask for credit card info, they specifically complain about cypto mining
Sure, if you want to install it on a machine that you are already paying for and managing, and then operate the thing yourself. That's obviously a very different product than any [IPS]aaS.
Tangentially related: I really dig this “soft” serif font that seems to be making the rounds (including on fly.io). I can't figure out if I like it because it is making the rounds, or if it's just easy on the eyes. Either way, I dig it.
You might find this overview of Windsor [1] interesting then. It was a classic typeface that many others (including Mackinac, used on Fly.io) were inspired by.
Hey, just letting you know that almost all your comments are shadowbanned, in error it seems. You can use the contact link at the bottom of this page to contact HN staff to sort it out.
Lovely! "Your credit card number is the thin plastic line between us and chaos".
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!
I was blind-robbed by a German company because of that. I paid a full year, was never given access,I "opened" a ticket and they answered a full week later asking me to fill 2 forms with lots PIID+ national ID card + Credit card, I told them to get lost. For being a supposedly modern, democratic society Germany seems very backward regarding online things, it is not surprised that for a economy of its size and influence the number of truly innovative "modern" online companies is rather low.
BTW, if someone knows of an HONEST company that provides online fax US numbers (Damn you IRS) I am all ears.
Yes, see what they wrote after fully charging me and refusing a charge back:
> There are some security issues with your account. We need to verify the
> account holder in order to unlock your account again.
> Please send us a scanned photo ID of the account holder and also a Letter of
> authority (LOA). It is required that the entered account information are
> also shown on the proof.
> We will then enable your PamFax account immediately.
No, i mean, what's wrong with having a webui? Digitalocean, Linode, Vultr, Upcloud, nothing requires you to have something installed. Why is Fly io different?
i don't work for fly so i'm not exactly an authority but as someone with quite a bit of cli experience i can get something done 50x quicker than with a webui. there's added bonuses too, you can use cli programs in ci build tasks.
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.