Configure services

Open an App and select Services. The index lists the App’s service cards. When a service isn’t enabled, its card is greyed and says Not enabled for this app.

Only Team owners and admins can change service configuration or purge the Varnish cache.

Each configurable service card shows its role, technology, version when available, and either Using defaults or the number of customer overrides. Common cards include:

• PHP (PHP-FPM) for web requests.
• Cron (PHP CLI) for scheduled jobs.
• Web server (Nginx).
• Database (MariaDB), the App’s MySQL-compatible database.
• Cache (Valkey or Redis).
• Message broker (RabbitMQ).
• Search (OpenSearch).
• Page cache (Varnish).

Edit a service

1. Select the service.
2. Review the effective values and their source.
3. Change the service version when a version picker is available.
4. Change only registered settings exposed by the portal.
5. Review inline validation and the previewed apply impact before you save.
6. Select Save changes.
7. In Apply changes to service?, review the impact and confirm.
8. Follow the resulting operation until it completes.

synsmarts validates supported settings before committing them. Configuration that fails a service’s native validation is rejected instead of being applied to the running App.

Configure services through MCP

Use a Control connection with config.read and config.write:

1. Call get_site_configuration for an App returned by list_apps.
2. Retain the returned revision_token.
3. Call configure_services with the supported services, resources, or config fields you want to change.
4. Include the revision token, an idempotency key, and confirmation.
5. Follow the returned deployment ID with deploy_status.

get_site_configuration returns a bounded projection for automation. Core fields include the App and environment, purchased shape, resources, services, versions, configuration apply state, pending Vars or code, envelope status, bounds, and revision_token. service_config contains each effective parameter value without the portal’s registry form metadata.

The MCP response intentionally omits running_config, version_options, and other UI-only sections. Use the portal’s Running configuration section when you need the live readback described below.

A stale revision fails without committing the requested edit. Read the current configuration again, review any intervening change, and submit a new request with the new token.

Reapply committed configuration

Use a reapply when the committed configuration is already correct but the running services haven’t converged to it. This operation reads and validates the existing platform-managed file; it doesn’t edit that file and doesn’t require a revision token.

Through MCP, call reconcile_configuration with an idempotency key and confirmation. Set force to true when the recorded applied projection is already current but the running services still differ. Follow the returned deployment ID with deploy_status.

From a CLI configured with an admin-scope API key, run:

synsmarts deploy config-reconcile <app-id> --force --yes

Use the non-forced form first when the configuration state is already marked pending or degraded. A non-forced request returns without a deployment when the projection is already recorded as current.

Understand the available settings

The exact controls depend on the App and service:

• PHP-FPM has its own version and extensions pickers and can expose memory, request duration, upload, and socket settings for web requests.
• PHP-CLI has independent version and extensions pickers and can expose memory and socket settings for Scheduled Jobs.
• Nginx can expose validated server or location snippets.
• Database (MariaDB) can expose SQL mode, packet size, idle timeout, and slow-query threshold settings.
• Valkey or Redis can expose the cache eviction policy. Session storage remains platform-managed.
• OpenSearch shows its effective managed configuration.
• Varnish exposes its vetted 40-setting Varnish 7.7 catalog through Add setting, plus its existing cache controls and Purge cache action.

Settings that control platform security or reliability aren’t editable. Settings whose default is derived from your purchased resources are editable — the derived value is a starting point, not a ceiling.

Change a service version

PHP-FPM, PHP-CLI, the MySQL-compatible database, the Redis-compatible cache, and OpenSearch show a version picker when the App supports a customer-selectable version. PHP-FPM and PHP-CLI use full x.y.z versions, are validated independently, and may differ; each card also offers extensions compatible with its selected version. For example, 8.3.30 is a WordPress PHP catalog key and 8.4.23 is a Magento PHP catalog key. Selecting a cache version also selects its matching implementation, such as Valkey or Redis. Nginx remains platform-managed.

Changing a version redeploys that service. Review compatibility with the App before confirming the change.

Understand defaults

See Value sources and locks for the four labels shared by service badges and the running-configuration file.

An effective value can come from the platform default or an App override. Removing an override returns the setting to the current platform default; it doesn’t preserve the old default forever.

Each editable field is marked Default or Custom. When a concrete baseline exists, the field also shows Default: value. Shape-derived defaults can change when the App’s purchased resources change.

Select Reset to default beside a custom setting to remove its override. Review the resulting value before saving. Returning a field to its displayed default is still a change and must be saved to remove the old override.

Review the running configuration

The Running configuration section is read-only and can be copied for troubleshooting. It includes the effective values and their source while redacting sensitive data.

When a rollout is pending, the view can include the newly saved configuration before every running service has adopted it. Use the apply status as the source for rollout completion.

Understand apply impact

• PHP web-runtime and Nginx changes use a health-checked replacement. Traffic moves only after the replacement is healthy.
• Database and cache changes restart the stateful service behind a temporary maintenance page, usually for less than a minute. Scheduled jobs pause during the restart; they are deferred, not lost, and overdue jobs run after service health is confirmed.
• PHP command-line changes restart the scheduled-job runner while the serving App remains online. Scheduled jobs pause briefly and upcoming runs continue on schedule.
• Varnish parameter changes restart the stateless page-cache pod behind the temporary maintenance page. Existing cache contents are flushed and warm again from application traffic; the applied values are read back live before the operation completes.
• A no-change save doesn’t restart a service.

Verify an apply

The service page shows Saving… and Saved — applying your changes… while the operation runs. The form remains disabled until the apply finishes or the page presents a recovery action.

When complete, review the Running configuration view and test the App path affected by the change.

For a database or cache change, also confirm that scheduled jobs resume. For a PHP or Nginx change, test a request that exercises the changed setting.

Purge Varnish

For a Magento or Shopware App with Varnish enabled, select Purge cache to invalidate the full-page cache. The purge is a separate runtime action and doesn’t change the saved service configuration.

synsmarts configures the framework to use Varnish when the App is provisioned with it. Enabling Varnish later creates the reverse proxy but doesn’t rewrite Magento or Shopware configuration. Complete the matching setup under Varnish (page cache) before relying on cache invalidation.

Recover from a problem

If the service catalog is temporarily unavailable, the page says Configuration editing is temporarily unavailable. The App’s already-applied configuration continues to run. Wait for the catalog to recover before making new changes.

• Correct highlighted validation errors before saving.
• If the requested service says Service not found, return to Services. The App doesn’t currently have that configurable service.
• If the revision is stale, load the latest configuration and repeat the edit.
• If another operation is active, wait for it to finish.
• A rejected save applies nothing, including a version already selected in the form. Load the latest configuration before trying again.
• If an apply stepped aside for another App change, select Load the latest and review the current configuration.
• If an apply fails or its status can’t be confirmed, select Load the latest before retrying.
• If a Varnish purge fails, retry after the portal’s suggested delay. Contact support if the failure persists.

Danger

If a stateful-service apply fails while maintenance is active, contact support. Do not retry — the App stays in maintenance and Scheduled Jobs stay suspended until our team confirms service health.

See Service configuration fields for the customer-editable parameter catalog, exact ranges, defaults, and running-configuration states. For framework-specific compatibility and verification, see Operate WordPress or Operate Magento.