Domains, certificates and the public-or-not decision
Every application in the catalogue carries metadata on how it authenticates and how it is published. It is not a description: it decides whether the application ends up on the internet.
In the catalogue index, applications carry three kinds of metadata: authentication, publication and dependencies. The first two directly affect what happens at install time.
Why publication is a separate field
Because “install an application” and “expose an application to the internet” are two different decisions, and they are constantly confused.
A monitoring dashboard installed with one command that turns out to be reachable from outside is the classic way to give away your infrastructure. Especially when the application ships with authentication off by default, which happens more often than one would like.
So the publication method is part of the application’s description in the catalogue, not a side effect of installing it.
What the automation does
DNS records and TLS certificates are handled automatically, renewal included. An expired certificate as a cause of downtime is removed by design: not with a reminder, but by renewal running without a human.
This is the boring part, and it should be boring. A certificate is the most predictable of all infrastructure problems: the expiry date is known in advance to the day. A problem with a known date should not cause downtime.
What the automation does not do
It does not decide for you whether an application needs a public address. It does not switch on authentication the application does not have. It does not turn a service without an access model into a service with one.
The last point is worth stressing, because the opposite expectation exists. A reverse proxy with TLS in front of an application without authorisation gives you a secure channel to an unsecured service. The channel is encrypted; access is open.
Dependency metadata
The third kind of metadata is what the application needs to run. We store it and show it, but we do not silently create it.
The reason is that a dependency almost always has options: its own database or a shared one, its own cache or a shared one, built-in file storage or external. An automatic choice here means a default, and a default stays for years.
The practical order
Look at the catalogue list with statuses. Look at the metadata of the specific application: how it authenticates, how it is published, what it needs. Run the install as a dry run. Install.
Four steps instead of one. Three of them change nothing and take minutes.
The general principle
Everything related to opening access to the outside is built to require an explicit decision. Everything related to hygiene, such as certificate renewal and DNS, is built to require no attention at all.
This split is not accidental. Human attention is a limited resource, and it should be spent on decisions, not on calendar reminders.