I’m looking for ways to minimize the costs of running my app, especially during periods of inactivity. My app doesn’t need to run 24/7, and I’d like to shut it down or scale it down when it’s not being used, similar to how Heroku’s free dynos would sleep after 30 minutes of inactivity.
Here’s my fly.toml:
# fly.toml app configuration file generated for appname on 2025-02-12T10:03:56+01:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#
app = 'appname'
primary_region = 'arn'
kill_signal = 'SIGINT'
kill_timeout = '5s'
[experimental]
auto_rollback = true
[build]
builder = 'heroku/builder:22'
[env]
PORT = '8080'
[[services]]
protocol = 'tcp'
internal_port = 8080
processes = ['app']
[[services.ports]]
port = 80
handlers = ['http']
force_https = true
[[services.ports]]
port = 443
handlers = ['tls', 'http']
[services.concurrency]
type = 'connections'
hard_limit = 10
soft_limit = 5
[[services.tcp_checks]]
interval = '60s'
timeout = '2s'
grace_period = '1s'
[[vm]]
memory = '256mb'
cpu_kind = 'shared'
cpus = 1
Any advice, tips, or examples would be greatly appreciated! Thanks in advance for your help.
I’m working on integrating Fly devops stuff at my app level. So when I need a machine, I will spin one up, and it will auto-exit when it is done. Depending on what “in use” means to you, you might be able to periodically scan for machines that are alive, and scale them down (even to zero) if your metrics reach a particular floor.
Not all applications behave well with suspend. Something that is guaranteed to work is stop. The difference is that suspended apps start basically instantly, stopped apps may take a second or two, depending on your app’s startup.
I ended up just adding those two properties inside my [[services]] block instead of replacing the whole configuration, and it seems to be working (I checked this morning and my machine was actually suspended)