We already have the following command for performing app configuration validation: flyctl config validate -c fly.toml
This command performs checks like “does a [[services]]
section expose at least one port” or “is the deployment strategy one of the allowed values”, etc.
One thing it doesn’t do, and which seems to fairly often be a source of confusion, is check for any “unrecognised” sections and/or fields.
Sometimes when something isn’t working, you might try popping various bits of config all across your fly.toml
in the hopes that one of them does the right thing. Or you might simply have misspelt something and it’s being silently ignored.
Not knowing which field is actually being utilised by the Fly platform leaves your config in a brittle state, because you don’t know what’s important and what isn’t, and the feedback loop for finding out is a full deploy, which is tedious to say the least.
Enter: flyctl config validate --strict
All it’ll do is tell you if there’s config somewhere it shouldn’t be. But that alone might be enough to put you back on track.
Example
fly.toml:
app = "bla"
primary_region = "mia"
console_command = "bin/rails console"
[http_service]
processes = ["app"]
internal_port = 3000
auto_stop_machines = "suspend"
auto_start_machines = true
min_machines_running = 1
[http_service.concurrency]
# `processes` is not a valid field here
processes = ['app']
type = "requests"
soft_limit = 50
hard_limit = 70
# This should be `[[http_service.machine_checks]]`
[[http_machine.checks]]
processes = ['app']
grace_period = "30s"
image = "curlimages/curl"
entrypoint = ["/bin/sh", "-c"]
command = ["curl http://[$FLY_TEST_MACHINE_IP]/up | grep 'background-color: green'"]
kill_signal = "SIGKILL"
kill_timeout = "5s"
% fly config validate --strict -c fly.toml
Validating fly.toml
✓ Configuration is valid
Strict validation found unrecognised sections or keys:
- http_machine
- http_service.concurrency.processes
Error: strict validation failed