As of k3d v4.0.0, released in January 2021, k3d ships with configuration file support for the `k3d cluster create` command.
This allows you to define all the things that you defined with CLI flags before in a nice and tidy YAML (as a Kubernetes user, we know you love it ;) ).
!!! info "Syntax & Semantics"
The options defined in the config file are not 100% the same as the CLI flags.
This concerns naming and style/usage/structure, e.g.
-`--api-port` is split up into a field named `kubeAPI` that has 3 different "child fields" (`host`, `hostIP` and `hostPort`)
- k3d options are bundled in a scope named `options.k3d`, where `--no-rollback` is defined as `options.k3d.disableRollback`
- repeatable flags (like `--port`) are reflected as YAML lists
As of the time of writing this documentation, the config file only **requires** you to define two fields:
-`apiVersion` to match the version of the config file that you want to use (at this time it would be `apiVersion: k3d.io/v1alpha2`)
-`kind` to define the kind of config file that you want to use (currently we only have the `Simple` config)
So this would be the minimal config file, which configures absolutely nothing:
```yaml
apiVersion: k3d.io/v1alpha2
kind: Simple
```
## Config Options
The configuration options for k3d are continuously evolving and so is the config file (syntax) itself.
Currently, the config file is still in an Alpha-State, meaning, that it is subject to change anytime (though we try to keep breaking changes low).
!!! info "Validation via JSON-Schema"
k3d uses a [JSON-Schema](https://json-schema.org/) to describe the expected format and fields of the configuration file.
This schema is also used to [validate](https://github.com/xeipuuv/gojsonschema#validation) a user-given config file.
This JSON-Schema can be found in the specific config version sub-directory in the repository (e.g. [here for `v1alpha2`](https://github.com/rancher/k3d/blob/main/pkg/config/v1alpha2/schema.json)) and could be used to lookup supported fields or by linters to validate the config file, e.g. in yur code editor.
Since the config options and the config file are changing quite a bit, it's hard to keep track of all the supported config file settings, so here's an example showing all of them as of the time of writing:
This means, that you can define e.g. a "base configuration file" with settings that you share across different clusters and override only the fields that differ between those clusters in your CLI flags/arguments.
For example, you use the same config file to create three clusters which only have different names and `kubeAPI` (`--api-port`) settings.