add self signed certificate to macOS version of Komga

[upstroke-version]

I'm using desktop macOS version of Komga from here, and I'm currently trying to setup self signed certificate to Komga using mkcert.
According to documentation, It seem like I need to use 'application.yml' to config this kind of stuff. But when I go to default Komga config directory for macOS, which is "~/Library/Application Support/Komga", I only see 'database.sqlite', 'tasks.sqlite', and 'lucene' folder, which don't have 'application.yml' file.

Do I have to manually make a application.yml file at "~/Library/Application Support/Komga/application.yml"?
If I do that, will Komga just use that config file right away when I restart it? Or do I have to set some additional thing so comgawill wuse that yml file.

[gotson]

Do I have to manually make a application.yml file at "~/Library/Application Support/Komga/application.yml"?

yes, as mentioned here https://komga.org/docs/installation/configuration:

The application.yml file does not exist by default, you need to create one if you want to customize the configuration.

If I do that, will Komga just use that config file right away when I restart it?

it should

[upstroke-version]

Thanks for the answer. But sadly I have more questions. Sorry to bother you.

I've wrote a yml file like this.
application.yml.zip

When I restart Komga, it ignores yml file and still opens in default port 25600 rather than specified port,
and https://localhost:25600 or https://localhost:8443 fails to access komga, as if komga does not know application.yml file exists in ~/Library/Application Support/Komga/application.yml.

Did I wrote the yml file in a wrong way? Or is it just because komga is not recognizing yml file for some reason?

I looked up the log file of Komga and when I searched "application.yml" there is no result in the log file, when I searched "config", I found this line that might be relevant.
"WARN 7565 --- [main] o.s.c.a.ConfigurationClassPostProcessor : Cannot enhance @configuration bean definition 'rar5Configuration' since its singleton instance has been created too early. The typical cause is a non-static @bean method with a BeanDefinitionRegistryPostProcessor return type: Consider declaring such methods as 'static' and/or marking the containing configuration class as 'proxyBeanMethods=false'."

[gotson]

  delete-empty-collections: true
  delete-empty-read-lists: true

those are deprecated and can be set in the UI directly.

Same for the port, you can change it from the UI.