Can I use fly for free for very small projects?

,
1

I’m a first time user, and have read about free tier having gone, but have colleagues who talk about it being free in some circumstances anyway.

I set up as server before xmas and then never used it. Now i have bill for $5.xx.
Was there any way I could have avoided this - see my config below

primary_region = 'ams'

[build]

[http_service]
  internal_port = 8000
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 1
  processes = ['app']

[mounts]
  source = "mixer_db"
  destination = "/dbs"
  initial_size = "5gb" 

[[vm]]
  memory = '1gb'
  cpu_kind = 'shared'
  cpus = 1

image
image794×315 27.1 KB

2

Hi… This doesn’t seem like a small configuration, actually—with a 5GB volume and 1GB RAM per Machine. (By default, you get two Machines.)

Fly.io tends to waive invoices that come out to be less than $5, but you’re not supposed to count on this happening. (Rather, be “pleasantly surprised” each time.)

Having said that, you could probably reduce your current cost by removing min_machines_running, assuming that you don’t always need one to be alive. If you’re not seeing much network traffic, then the Machines would spend most of their time sleeping—thus mostly eliminating the two largest parts of your bill ($3.58 +$1.86).

(auto_start_machines will wake it up on incoming HTTP requests.)

Hope this helps a little!

2 Likes
4

Thanks. That is useful. I will reduce the volume as its way way more than I actually need, and try to reduce the RAM.

How can I have 1 machine only? If I remove auto_start_machines does that mean I have to start manually from the console?

(I basically need it to run while testing and on the Sundays of the events I am helping with)

5

I would first check both volumes to verify that they do have the same files. The platform itself doesn’t synchronize them.

You can use fly m stop to ensure that at least one Machine is stopped and then (a few seconds later) fly m destroy on 1 of the 2. And finally fly vol destroy, since the volume isn’t automatically removed when the associated Machine is. (I always forget that part.)

The platform will nag about having only one volume, and this generally is sage advice. The reason is that a failure of the underlying physical host machine will eventually occur someday, causing you to lose the last 1–2 days of changes, :fried_egg:. (Or even the entirety, if you don’t notice soon enough.)

In this case, though, I think you might be broadly ok with just taking a manual volume snapshot after each Sunday. (Only you know the tradeoff in full.)

Basically. The Web UI dashboard can also do that now, which is more convenient sometimes.

1 Like
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.