Non-service health checks

I’m deploying services that I don’t want publicly accessible like HashiCorp Vault.

My current process is to deploy Fly.io Apps with an empty services block.

services = []

However, I would like to retain health checks.
Dumping the config for one of the Postgres DB apps, I see an undocumented (AFAIK) [checks] block.

Is this something I could co-opt for checking service health for private services?

1 Like

That’s an interesting idea :thinking:

I hadn’t actually noticed those checks uses a different structure for their Postgres app. That would indeed be helpful to know if that’s available to all apps:

While you wait for someone to Fly to answer that question, you can simply not provide an external port. The docs don’t say that explicitly but I’ve done that e.g for a demo Fastify app using a TCP healthcheck. And I would assume given that no external port is specified, it must therefore be private. You could double-down on that by not assigning the app a public IP. Anyway, this was what I used, if you want to try something while waiting:

# fly.toml file generated for fastify-api on 2022-02-05T17:38:04Z

app = "fastify-api"

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

  [services.concurrency]
    hard_limit = 50
    soft_limit = 25

  [[services.tcp_checks]]
    interval = 5000
    timeout = 2000
2 Likes

The [checks] block is available for all apps. You do need to specify the port in the check.

I suppose we should document this!

6 Likes

Need to document the script_checks option, too.

1 Like

I take checks are supported for Machine apps now (pr)? If so:

  1. What is the behaviour when these checks start failing? Is the Machine restarted?
  2. Can restart_policy help control that behaviour?