Automatically start and stop internal services

I’ve enabled auto start and stop of my api app through the http_service as described here: Automatically Stop and Start Machines · Fly Docs.
In addition to the api I have another Fly app that serves as a database. The api and db apps communicate over the internal network. As far as I can tell there is no way to automatically start and stop internal services (without ports facing external through [http_service] or [service]). So to also start and stop the database automatically, I’ve added an http_service to it and connect the api to the db through the public IP instead. I think that’s fine but it would be great to have auto start&stop on internal services as well - any way to achieve this currently?
I guess another option would be to simply run the api and db processes on one app. But since volumes can be mounted by only one machine at a time that would add complexity of keeping databases in sync when adding more api machines.

That works if you have services and a flycast address

1 Like

@lubien, thank you for the link! Using Flycast with a private IP sounds like exactly what I’m looking for to use auto start&stop feature and have the db behind a private IP (docs).

Regarding making the db-app publicly accessible and auto start&stopping, I’ve tried accessing it through [db-app].fly.dev from the api-app but this does not seem to start the db automatically. It does start when I send a GET request from my browser to [db-app].fly.dev though. Is [db-app].fly.dev automatically routed to [db-app].internal when accessed from a Fly app and therefore does not pass the Fly proxy that auto starts&stops?

is your public DB working through http_service or services? I believe if you use services could just work, but I haven’t tested that scenario myself so I don’t know how the proxy responds to that.

The DB app is configured through http_service like this:

[http_service]
internal_port = 8000
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0

Try to use services instead, should behave better

I ssh’ed into the API app and did some experimenting by curling the DB app:

$ curl [db-app].fly.dev            # does not auto-start db-app
$ curl http://[db-app].fly.dev     # does not auto-start db-app (db-app has force_https enabled)
$ curl https://[db-app].fly.dev    # does auto start db-app ✅

I believe that’s because curl doesn’t follow redirects by default. curl -L [db-app].fly.dev should autostart the app.

1 Like

That makes sense, @ben-io!
I’ve ran into another issue when I use https://[db-app].fly.dev from the api-app it doesn’t start the db-app but gives Connection reset by peer (errno: 104) and the request fails but since curling works, not sure where this issue comes from.

Are you running postgres? If you want to use postgres via flycast (i.e. via our proxy), you need to use the pg_tls handler:

[[services]]
  protocol = "tcp"
  internal_port = 5432

  [[services.ports]]
    port = 5432
    handlers = ["pg_tls"]

No, I’m running surrealdb. It already includes a HTTP API, so I think the handler should be find :thinking:

EDIT: my bad, I was using the wrong port :man_facepalming:, since http_service routes through 80/443 of course.

I’ve set it up with a private IP through Flycast now and everything works nicely over [db-app].flycast:80 :raised_hands: - thanks for the help!

1 Like

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