Skip to content
How-to guide

Manage App Settings

Open an App and select Settings.

  • Team owners and admins can change the App avatar, name, and authoritative YAML.
  • Developers can view and download the authoritative YAML but can’t change it.
  • Billing members can view the App identity but don’t see the YAML.
  • The Transfer entry point is visible to Team members, but the transfer operation enforces its own role requirements.

Request tracing is a focused exception to general YAML editing permissions: owners, admins, and developers can change it from Diagnostics, while billing members can view its state. See Trace requests.

Under General:

  1. Select the current avatar.
  2. Upload the replacement.

The avatar is saved when the upload completes. It doesn’t depend on the Save changes action for the App name.

  1. Enter an App name of up to 100 characters.
  2. Select Save changes.

The portal derives the readable App URL from the name. Renaming the App can change that URL; an old App link redirects to the current URL.

Clearing the name restores the generated tenant-<id> name. There is no separate editable URL-slug field.

The Configuration section shows the complete authoritative App YAML at .synsmarts/<app-id>.yaml, its current state, and a shortened content revision.

The Settings page for an example App shows the General card with the App avatar and Storefront name. The Configuration card identifies the authoritative YAML, state synced, example revision a3f91c77b2e4, and an editor selecting wordpress:6.5-php8.3.

Select Download YAML to download the exact version currently shown. Secret values aren’t stored in this file; supported settings refer to secrets rather than containing them.

Team owners and admins can edit the YAML:

  1. Make the required change in the editor.
  2. Select Save changes.
  3. Review the warning that affected services may restart and the App may be briefly unavailable.
  4. Select Save and apply.
  5. Keep the page open until the operation reaches a final result.

The portal validates the YAML before saving it. Correct every reported field error before trying again.

The result can report:

  • the YAML already matched the authoritative configuration;
  • the YAML was saved and no runtime change was required;
  • the YAML was saved and applied;
  • the YAML was saved and is queued behind recovery or another App change;
  • the YAML was saved while a newer App change was already applying and will be applied automatically afterward;
  • the YAML was saved but couldn’t be applied; or
  • the YAML couldn’t be saved or applied, so authority is unchanged.

If status is temporarily unavailable, select Retry status before leaving the page.

The editor and uploaded restore file are tied to the revision that was loaded when editing began.

If another App change updates the authoritative YAML:

  • select Reset to latest before saving an edited draft; or
  • review the latest revision and choose the restore file again.

This prevents an older edit from silently overwriting a newer App change.

Restoring YAML replaces the current desired configuration with the uploaded file as a new authoritative revision.

  1. Under Restore a YAML version, select Choose file.
  2. Choose a complete .yaml or .yml file for this App.
  3. Select Restore YAML.
  4. Review the restart warning.
  5. Select Restore and apply.
  6. Keep the page open until the operation reaches a final result.

If validation fails, correct the uploaded file and choose it again. If the authoritative revision changed after file selection, load the latest revision before retrying.

Under Danger zone, select Transfer to hand App access and future billing to another Team. Review Transfer an App before continuing.