Update an application's configuration.

The application's unique name (slug).

The application root, relative to the top of the source, for a source whose application does not live at the top level (for example, packages/web in a monorepo).

Pass an empty value to reset the root back to the source top.

Changing this value re-runs the preflight against the new root, which re-detects the application's framework and category and re-seeds the suggested build defaults (any value you pass explicitly in the same call takes precedence). When it changes, the response also carries the confidence and defaults from the re-detection.

This parameter must be a relative path inside the source.

Whether the scheduled health check may act on this application.

• 1 — The health check may restart or otherwise repair it.
• 0 — Leave the application alone entirely. It is not checked, so its health block stops being updated.

Pass an empty value to follow the server-wide setting, which is the default.

The command that builds the application.

Pass an empty value to clear it, so the deploy falls back to the detected default.

The application's database action.

• create — Provisions a new MySQL database and user, named from the application's slug.
• link — Attaches an existing, account-owned database (see db_name) by creating a new, dedicated MySQL user for it, granted ALL PRIVILEGES on the database — never by reusing an existing user, since MySQL keeps no retrievable password for one.
• remove — Clears the application's db record, and deletes the database and its user if it was created, or only the dbuser if it was linked — the linked database itself is never touched.

An application may have at most one linked database, so create or link on an application that already has one fails: use remove first. There is no replace action that does both in one call.

Warning: for a created database, remove destroys it and everything in it, and this cannot be undone. A linked database is never at risk from remove — only its dbuser is.

remove clears the db record even when the underlying drop itself fails (for example, a created database already dropped outside this API). The call succeeds and reports a warning, since clearing the record is the only way to make the application's database name usable again.

On a deployed application, the container is recreated so the new database settings take effect immediately, without a redeploy. A stopped application stays stopped, and picks the settings up when it next starts. If the change cannot be applied to the container, the call fails and the application and its database are left as they were.

All three actions require the account's mysql feature and the server's MySQLClient role.

The existing, account-owned database to attach. Required when db is link; ignored (and omittable) otherwise.

The name (slug) used to name the deployment. When omitted, the deployment is named after the application.

The domain to bind the application to: a new subdomain of a domain the account owns, or the application's own already-materialized domain. A domain already claimed by another application is always rejected. A domain the account already uses for something else — the main domain, an addon domain, a manually created subdomain — is rejected unless use_existing_domain confirms it. See the domain_in_use, domain_unavailable, and domain_temporary error_category values.

Pass an empty value to regenerate the application's default <name>.<main domain>.

A JSON-encoded object of the application's environment variables.

Warning: This replaces all existing environment variables with the set you provide.

The values are written to the application's own .env file, which the container reads at startup. That file lives in the application's source tree, so setting values is refused unless the repository keeps it out of version control — see the env_not_editable error_category and the env_editable field on the application. An empty object clears the environment, which is allowed even then, because a clear removes values rather than publishing them.

Database precedence: once a database is configured (create or link), its connection details are injected under DB_HOST, DB_NAME, DB_PORT, DB_USER, and DB_PASSWORD (see db.env_keys). If this parameter sets a variable with the same name, the database's value overrides it in the deployed container.

Limits: at most 16384 bytes of JSON and 64 variables. A name must match [A-Za-z_][A-Za-z0-9_]* and be at most 128 characters. A value must be a single value (not an object or a list), at most 4096 characters, and free of control characters. PORT is reserved by the system and is rejected.

The raw contents of a .env file, for a caller pasting a whole file rather than assembling an object. Mutually exclusive with env; passing both is an error.

Warning: This replaces all existing environment variables, exactly as env does.

The text is read the way podman's --env-file reads it, so what is accepted here is what the container would have loaded from the same bytes: leading whitespace is trimmed, blank lines and lines beginning with # are ignored, the first = separates the name from the value, and the rest of the line is taken verbatim — no quote stripping and no trimming, so A="b" has the value "b" including the quotes. A name repeated on a later line takes that later value. A line with no = is rejected rather than copied from the server's own environment.

The resulting variables are held to the same limits as env, and are refused for the same repository reasons. Text that yields no variables clears the environment, which is allowed even then, exactly as an empty env object is.

The run mode for server category applications.

The directory, relative to the application root, that the build writes its output to.

The runtime version tag to run the application under. Use WebApp::get_available to list the valid tags.

The command that starts the application's server process. Only meaningful for the server category.

Pass an empty value to clear it, so the deploy falls back to the adapter default. Clearing both this and build_command on a non-static application leaves it undeployable: the deploy then fails with a requires_build error_category.

Confirms that the application may be served at a domain the account already uses. The application is proxied over that domain, so whatever its document root serves — an existing website, and any files added to it later — stops being reachable until the application is deleted. Other configuration on a domain already in use (rewrites, handlers) may also take precedence and keep the application from being served, which is why a fresh, unused <name>.<domain> is the ideal target. See https://go.cpanel.net/docroot2proxy.

Only meaningful alongside domain, and only kept while that domain is unchanged: pointing the application at a different domain requires confirming again. Omitting the parameter does not withdraw a confirmation already given — it leaves the standing one in place, so resending domain to change something else needs no reconfirmation. There is no way to withdraw a confirmation for a domain that still exists (sending 0 is refused with domain_unavailable); point the application at a different domain instead, which releases the reverse-proxy include on the domain being left so it serves its own document root again.

It is recorded only when the domain already exists and the application did not create it; for one the application will create, or already created, the domain is the application's own, so there is nothing to take over and the application object reports 0. It does not allow a domain another application already has, nor a domain the system cannot create.