Features and configuration

The config seed, the designer, MCP, chat, launch validation, git and ytt

Variable	Choices/Defaults	Comments
CONFIG_SEED_PATH string added in version 6.3.0	Default:	Config seed file a valid file path Path to a declarative config seed. When set, the yaml file it points to is applied at startup and the admin objects it declares become read-only in the interface, so a whole instance can be rebuilt from git on an empty database. Secrets are referenced as ${ENV_VAR} and resolved from the environment, so the file itself holds none. Unrelated to CONFIG_PATH, which holds the forms configuration. An invalid seed makes the server refuse to start. See the Config seed page in the documentation.
CONFIG_SEED_RELOAD_SECONDS integer added in version 6.3.0	Default: 60	Config seed reload interval 0 or a number of seconds How often the config seed file is checked and re-applied when its content has changed, in seconds. This is what lets a seed edited in git take effect without restarting: on kubernetes a ConfigMap is remounted under the running pod within about a minute and the change is picked up from there. A reload that fails is never fatal, unlike the one at startup: the configuration already in force is kept and the Status page reports it. Set it to 0 to check only at startup, leaving POST /api/v2/config-seed/apply and SIGHUP. Ignored when CONFIG_SEED_PATH is empty.
ALLOW_ENV_EDIT boolean added in version 6.3.0	Default: 1	Allow editing these settings 0, 1 Whether the settings pages may write persistent/.env. Set it to 0 in a declarative deployment (kubernetes, docker-compose, ArgoCD): there the file is either ephemeral, so a save is silently lost at the next restart, or durable, so it drifts away from the manifest that is meant to be authoritative. With 0 every variable is shown with its value in force but cannot be changed, and the save endpoint refuses.
ENABLE_MCP boolean added in version 6.4.0	Default: 0	Enable the MCP server for AI agents 0, 1 Serves an MCP (Model Context Protocol) server on `/api/v2/mcp`, so an AI agent or an MCP client (a chat backend, an IDE) can list the forms a user may use, resolve their fields, launch jobs and follow them. Every request carries an AnsibleForms access token and runs as that user, with the same form roles and job visibility as in the browser. Changing it needs a restart. See the MCP page of the documentation.
ENABLE_CHAT boolean added in version 6.5.0	Default: 0	Enable the chat assistant 0, 1 Shows a chat button on every page. The assistant fills in a form with the user by talking, through the same form engine as the browser, and launches it only when the user clicks the Launch button on the exact payload it was shown. It also needs a model provider on the Chat assistant settings page (or in the config seed), forms with `enableForChat: true`, and users whose roles allow `allowChat` (the default). Form definitions and the values being filled in are sent to that provider ; passwords, credentials and job output never are. Changing it needs a restart. See the Chat assistant page of the documentation.
LAUNCH_VALIDATION string added in version 6.4.0	Choices: off (default) log enforce	Check the field values of every launch against the form's validation rules off, log, enforce Checks every launch from the browser or the REST API (`POST /api/v2/job`) on the server against the form’s validation rules - `required`, `regex`, `minValue`/`maxValue`, `minLength`/`maxLength`, `minSize`/`maxSize`, `sameAs`, `in`/`notIn`, `validIf`/`validIfNot`, valid YAML - with the same engine the browser and the MCP server use. The check runs the form’s expressions and queries again, as the user who launches, so it costs one extra evaluation of the form per launch. `off` (default) : no check, launches behave exactly as before. `log` : a launch that would be refused is logged as a warning and still runs. Use this first, to see in the log what enforcing would refuse. `log` also names the extravars keys where what the client sent differs from what the server builds (never their values). `enforce` : such a launch is refused with status 422 and the failing fields. A launch that sends no `rawFormData` (a REST call that leaves it out) is refused as well, because its values cannot be checked. A valid launch runs the extravars and credentials the SERVER builds from the checked values, not the ones the client sent : computed fields (expressions, queries) are the server’s evaluation, and a file field must point at a real upload in `UPLOAD_PATH`. Wizard forms cannot be checked yet and are refused. What the user saw is not always what runs. The server evaluates every computed field again at launch, a moment after the browser did, as the launching user. A value that depends on WHEN or WHERE it is evaluated can differ, and then the server’s value runs : time : `fn.fnTime()`, `new Date()`, a timestamp or a name built from it ; outside data : a query, `fnRestAdvanced` / `fnSsh` / `fnDnsResolve`, a file read if the data changed in between ; the browser’s own settings : a `runLocal` expression using the user’s timezone or locale (`toLocaleString`) runs with the server’s. The same goes for validation : a rule that reads such a field (`notIn` against a query’s result, `validIf` on a computed flag) is checked against the server’s value. Run `log` first : it names every extravars key where the client and the server differ, so you see which forms this affects before you enforce. The rows of a `list` field that were added or edited go through their subform on the server as well, with the form’s values as `__parent__` : its rules are checked and its computed fields evaluated. Rows the list’s own expression produced, and rows marked deleted, are sent as they are - as in the browser. At most 500 rows are resolved per launch. Applied without a restart. A form can be made stricter with its own `launchValidation` property ; the stricter of the two wins. See the Launch validation page of the documentation for the whole picture : what is checked, list rows, uploads, passwords and how to roll it out.
ENABLE_DB_QUERY_LOGGING number added in version 5.0.3	Choices: 0 (default) 1	Enable the database query logging 0, 1 When you want to see the database queries that are executed, you can enable this option by setting this variable to 1. introduced, due to massive amount of logging of database queries, which can be useful for debugging, but not for production.
ENABLE_CONFIG_IN_DATABASE number added in version 6.1.0	Choices: 0 (default) 1	Store the configuration in the database 0, 1 If you use git repositories to store the forms, you can choose to store the master config.yaml in git as well. Or, you can choose to have the config.yaml in the database instead. Having a clean separation: master config.yaml in database, and the actual forms in git. This gives the config.yaml in the database the highest priority in the loading order.
GIT_CLONE_COMMAND string added in version 6.0.2	Default: git clone	Git clone command a valid git clone command The command used to clone git repositories. Note that branch and repository will be auto added.
GIT_PULL_COMMAND string	Default: git pull	Git pull command a valid git pull command The command used to pull git repositories. Note that branch and repository will be auto added.
GIT_PUSH_COMMAND string	Default: git push	Git push command a valid git push command The command used to push git repositories (used by the designer’s sync to git feature). Note that `-u origin HEAD` will be auto added.
SHOW_DESIGNER number added in version 4.0.0	Choices: 0 1 (default)	Enable the internal designer 0, 1 Although we encourage you to use an editor such as Visual Studio Code to edit the config.yaml file, preferably with some form of source control. Ansible Forms comes with an internal yaml designer. And although only admins can see the designer, you might want to disable it completely by setting this variable to 0.
USE_YTT number added in version 5.0.2	Choices: 0 (default) 1	Enable the ytt interpreter 0, 1 https://github.com/carvel-dev/ytt is a tool for yaml templating. It can be activated by this variable.
YTT_ALLOW_SYMLINK_DESTINATIONS string added in version 5.0.8	Default:	ytt allowed symlink destinations valid paths Ytt disables templating with symlinks by default. If you want to allow symlink use on specific directories, this variable can be set to the path(s) where the symlinks are allowed (multiple paths separated by Node’s `path.delimiter`). Note: enabling this may come with some risks, see ytt FAQ for more info.
YTT_DANGEROUS_ALLOW_ALL_SYMLINK_DESTINATIONS number added in version 5.0.8	Choices: 0 (default) 1	ytt dangerous allow-all symlink destinations 0, 1 Ytt disables templating with symlinks by default. If you want to allow all symlink use EVERYWHERE, you can set this variable to 1. Note: enabling this comes with some risks (hence the ‘DANGEROUS’ part), see ytt FAQ for more info.
YTT_VARS_PREFIX string added in version 5.0.8	Default:	ytt vars prefix a valid prefix Environment variable prefix for ytt to get data values from. For example, when set to `MY_PREFIX`, `MY_PREFIX_my_var=value` results to the ytt data value `my_var=value`.
YTT_LIB_DATA_{dynamic} string added in version 5.0.8	Default:	ytt lib data a valid lib data value This is not a single variable but rather an infinite amount of variables. You can set as many as you want. The dynamic part is the name of the lib data. For example `YTT_LIB_DATA_MYLIB=values.yml` results in the contents of `values.yml` to be used by ytt in the `mylib` library.
AWX_API_PREFIX string added in version 5.0.9	Default: /api/v2	The prefix for the AWX API a relative url path Ansible Forms can connect to an AWX instance. This is the prefix of the API, which is typically `/api/v2`.