I, like many other developers, like to keep my config files minimal, relying on defaults as much as possible. I noticed that not setting:
[[services.ports]]
handlers = ["tls", "http"]
port = "443"
inside the fly.toml file causes the port 443 to not accept connections, even though the docs says that it’s the default behavior.
I’d like to know if there’s any way I can avoid setting this configuration.
These services are enabled by default when launching an app. By removing them from fly.toml - while keeping the [services] header - they will be unset. You can’t avoid setting them (yet) at launch time.
[services] header isn’t set.If your goal is to not have any ports open to the internet, just add a blank [services] header to your fly.toml and deploy.
No it’s not. Let me rephrase.
My goal is to have the two default ports (80 & 443) open.
But, since they’re the default, I want to omit them in the config file.
In other words, the config file should fall back to the default when something is omitted.
That’s usually what you can expect from a config file.
Right now, omitting:
[[services.ports]]
handlers = ["tls", "http"]
port = 443
causes the port to be not open, which is unexpected since, again, docs say it’s the default.
Maybe I’m reading this differently to you, but I’m not sure the docs do say that.
What the docs say is:
The default configuration, for example, contains two. We’ve already seen one above. The second one defines an external port 443 for secure connections, using the “tls” handler.
I read this as meaning: “the default fly.toml template (that we use to generate an initial fly.toml config file for your app when you run fly launch) has these entries in it by default”.
I don’t read that as meaning: “if you don’t specify any ports, we’ll automatically assume you want to listen on 80 & 443”
That said, I do agree that it would be nice not to have to specify these ports in every app config.
That’s my point.
I do agree that the docs are not erroneous, though they can be misinterpreted. With most hosting providers (e.g. Vercel), it is possible for you to provide 0 config (i.e. to have a completely empty config file or no file at all), relying exclusively on defaults, which, IMO, is pretty nice. I was expecting Fly to do the same.
The no or low-config approach is simple: if it’s the default, we shouldn’t be required to provide it.
Alternative viewpoint: Ideally, a platform will not expose ports to the Internet that you cannot tell will be exposed by reading the config file you use to deploy. Not all apps want to be exposed outside their organization’s private WireGuard network.
In that case, the docs should not say that those two ports are open by defaults.
I’m not against configuring things, I’m just in favor of having defaults we can predict and rely on. If those ports are better closed by default, then be it. But the docs should say: “by default, no ports are exposed”.