Service configuration fields

The Services page shows only settings supported for the selected App and service. A field absent from the page isn’t customer-editable. How a saved change reaches the running App is explained in How App configuration is applied.

Each card separates:

• Editable settings, which create customer-set values.
• Running configuration, which includes values from all four states below for troubleshooting.
• Version, when the current platform catalog offers customer selection.

Value sources and locks

Service badges and the running-configuration file use the same four labels:

Label	Meaning
customer-set	Your App has an override for the setting.
sized to plan	synsmarts calculates the value from the App’s purchased resources or a service reservation.
platform default	The platform baseline applies because the App has no override. Removing an override returns to this value.
locked	The value protects a platform path, port, recovery behavior, or operational guarantee and isn’t editable.

The catalog is default-open: a writable setting is customer-editable unless changing it would break platform operation or a guarantee. Those exceptions are locked.

Locked settings appear only in Running configuration. They never appear as editable fields.

PHP-FPM web service

This card has its own PHP version and extension pickers. The version is stored as a full x.y.z key at services.php_fpm.version; extensions are stored at services.php_fpm.extensions and are checked against that selected version. Your Magento version doesn’t restrict the picker: your own composer.json determines which Magento release is installed, so the PHP line is yours to pick. Check Adobe’s supported matrix before moving to a line your Magento release doesn’t support.

PHP-FPM and PHP-CLI are validated independently and may use different versions and extension lists.

Editable settings

Setting	Type and range	Default	Meaning
memory_limit	MiB, 64-8192	sized to plan	Maximum memory for one web request. The sized value is the default, not a cap.
max_execution_time	Integer seconds, 1-300	300	Maximum wall-clock request time.
max_input_time	Integer seconds, -1 to 600	WordPress 300; Magento -1	Time allowed to read request input. -1 uses the execution-time limit.
max_input_vars	Integer, 100-100000	WordPress 1000; Magento 10000	Maximum accepted request input variables.
post_max_size	MiB, 1-512	64	Maximum POST body size.
upload_max_filesize	MiB, 1-512	64	Maximum size of one uploaded file.
max_file_uploads	Integer, 1-1000	20	Maximum files in one request.
default_socket_timeout	Integer seconds, 1-600	60	Default timeout for socket-based streams.
disable_functions	String, maximum 4096 characters	exec,passthru,shell_exec,system,proc_terminate,proc_nice,putenv	PHP functions disabled for web requests. An empty value enables them inside the App’s container.
allow_url_include	Boolean	Off	Allows URL-aware wrappers to load PHP code.
log_errors	String, maximum 8 characters	On	Controls whether PHP writes errors to the managed error log.

post_max_size should be at least as large as upload_max_filesize for uploads to succeed.

For web requests, memory_limit, disable_functions, allow_url_include, and log_errors — and the platform’s locked values — are applied in the FPM pool as php_admin_value or php_admin_flag entries: your overrides render as php_admin_value[memory_limit], php_admin_value[disable_functions], and so on. Application code, .user.ini, and ini_set() can’t raise or override them. Other settings, and all scheduled-command settings, load as ordinary startup php.ini values.

Additional running values

These rows use the four labels in the running file. Values marked platform default can be overridden by an editable setting.

Setting	State	Effective behavior
error_reporting	platform default	E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors	platform default	Off; errors don’t render in customer responses.
log_errors	platform default	On
opcache.enable	platform default	1
opcache.max_accelerated_files	platform default	WordPress 10000; Magento 130000
opcache.validate_timestamps	platform default	Magento 0; WordPress code changes are detected according to the managed runtime policy.
opcache.revalidate_freq	platform default	WordPress 0; not used for Magento’s immutable code image.
realpath_cache_size	platform default	Magento 10 MiB
realpath_cache_ttl	platform default	Magento 7200 seconds
opcache.memory_consumption	sized to plan	Derived from the purchased shape.
php_admin_value[date.timezone]	locked	UTC; not customer-configurable. Application code may still set a per-request timezone at runtime.

PHP-FPM pool

The process-manager settings are editable. Each one’s default is derived from PHP-FPM’s modeled share of unallocated App headroom after service reservations, platform costs, and workload floors. Leave a setting unset and it tracks that derivation as the shape or a service reservation changes; set it and your value is used exactly as written. PHP-FPM has no customer memory reservation or fixed memory limit.

Raising the worker count above what the shape’s memory supports is allowed and isn’t capped. Workers that exceed the available memory are stopped by the platform under pressure. Size increases against measurements from your own load testing rather than as a precaution. memory_limit behaves the same way: its sized to plan value is the default, not a ceiling, and a higher value is accepted up to the field’s stated maximum.

Setting	Effective behavior
pm	Editable. Process-manager mode; its sized to plan default is static.
pm.max_children	Editable. Worker limit; default derived after runtime and extension reservations.
pm.start_servers	Editable. Workers started in dynamic mode; default scales with the worker limit.
pm.min_spare_servers	Editable. Minimum idle workers in dynamic mode; default scales likewise.
pm.max_spare_servers	Editable. Maximum idle workers in dynamic mode; default scales likewise.
pm.max_requests	Editable. Requests a worker serves before respawning; 0 disables respawn.
pm.status_path	Editable. Default /status; the platform’s FPM metrics scrape follows your value.

Locked PHP-FPM values

These settings protect the FPM listener, tracing and logging paths, filesystem boundary, and session path. They appear in the running file with the locked label and aren’t editable.

Setting	App	Effective behavior
listen	All	0.0.0.0:9000 inside the App network.
catch_workers_output	All	yes; worker output reaches managed logs.
error_log	All	/dev/stderr, collected by the managed logging pipeline.
auto_prepend_file	All	/usr/local/share/synsmarts/otel/trace-gate.php, which loads the managed tracing gate.
php_admin_value[open_basedir]	WordPress	/var/www/html:/tmp:/etc/ssl/certs:/usr/local/share/synsmarts/otel:/usr/local/share/synsmarts/wordpress-plugins
php_admin_value[open_basedir]	Magento and Shopware	/var/www/html:/tmp:/etc/ssl/certs:/var/run/secrets/eks.amazonaws.com/serviceaccount/:/usr/local/share/synsmarts/otel
php_admin_value[session.save_path]	All	/tmp

PHP-CLI scheduled-jobs service

This card controls the PHP processes used by Scheduled Jobs. It has its own version picker and extension picker, stored at services.php_cli.version and services.php_cli.extensions. Both are validated against the PHP-CLI selection, independently of PHP-FPM.

Editable settings

Setting	Type and range	Default	Meaning
memory_limit	MiB, 128-384	384	Maximum memory for each scheduled PHP command.
default_socket_timeout	Integer seconds, 1-600	60	Default timeout for CLI socket streams.

Running configuration

The running file uses the four labels. error_log and date.timezone are locked; the other rows below are platform defaults with customer-editable registry entries.

Setting	State	Effective behavior
max_execution_time	platform default	0; the scheduler enforces the job timeout instead.
error_reporting	platform default	E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors	platform default	Off
log_errors	platform default	On
error_log	locked	/dev/stderr
date.timezone	locked	UTC; not customer-configurable. Scheduled code may still set its own timezone at runtime.

Applying a PHP-CLI change restarts scheduled-job execution while the web App remains online.

Nginx

Nginx version and platform security configuration are managed by synsmarts.

Editable settings

Setting	Type and limit	Meaning
server	Validated Nginx snippet, maximum 8000 characters	Additional directives in the managed server block.
location	Validated Nginx snippet, maximum 8000 characters	Additional directives in the managed location block.

Both slots use a safety allowlist. Unsafe, unsupported, or locked directives are rejected when saved. A valid Nginx parse is necessary but not sufficient; directives that would bypass routing, isolation, security, or resource controls remain unavailable.

Running configuration

The running file marks these routing and security controls as locked.

Setting or block	Effective behavior
root	/var/www/html for WordPress and /var/www/html/pub for Magento.
index	Framework-appropriate PHP and HTML index files.
fastcgi_pass	Routes PHP requests to the active managed PHP-FPM slot.
fastcgi_read_timeout	Matches the maximum customer-selectable PHP execution-time ceiling.
try_files	Framework-specific front-controller routing.
Static asset caching	WordPress assets use a 30-day cache; Magento static and media paths use long-lived versioned cache.
Sensitive-file denials	Blocks dotfiles, logs, WordPress configuration, and PHP execution from upload paths as applicable.
Health endpoint	WordPress exposes the platform-managed /healthz route.
disable_symlinks	on for WordPress.

MySQL-compatible database

The version picker shows only database versions offered for the App. The current catalog can offer Percona Server and MariaDB lines; a fresh Magento App defaults to MariaDB 11.4.

You can move to a newer database release in place. Moving backward isn’t offered because the database reuses its live data volume.

Editable settings

Setting	Type and range	Default	Meaning
sql_mode	strict, traditional, ansi, or minimal	strict	Supported SQL-mode preset. Custom SQL-mode strings aren’t accepted.
max_allowed_packet	MiB, 1-1024	64	Largest query or result packet accepted by MySQL.
wait_timeout	Integer seconds, 60-86400	28800	Idle non-interactive connection lifetime.
long_query_time	Number of seconds, 0.1-60	10	Threshold for the slow-query log.
innodb_buffer_pool_size	MiB, 128 to a memory-safe ceiling	sized to plan	InnoDB buffer-pool size. The plan-sized value is the default; a larger value is accepted up to a ceiling that keeps the database inside its memory limit. Raising the database’s memory raises the ceiling.

On MariaDB 11.4 and Percona Server 8.4, the panel also offers an Add setting picker over the engine’s vetted parameter catalog. Search or filter by category (InnoDB, optimizer, logging, and so on), add a setting, and it appears below the table above as a typed control with the engine’s version-specific range and default. Removing an added setting restores the platform default. Settings that name a filesystem path or port, security-sensitive server controls such as local_infile, init_file, plugin_dir, and secure_file_priv, and settings for features the platform doesn’t run for your App aren’t offered. Clustering and replication-topology settings are examples of the last group.

Every effective MySQL parameter change currently rolls the single stateful service. synsmarts serves a temporary maintenance page, suspends scheduled jobs, waits for the new database generation and health check, then restores traffic and deferred jobs.

Running configuration

The running file labels each row with the applicable state.

Setting	Effective behavior
innodb_buffer_pool_chunk_size	Derived with the buffer-pool layout.
max_connections	Derived from the database container’s memory.
log_bin	binlog
binlog_format	ROW
binlog_row_image	FULL
sync_binlog	1
binlog_expire_logs_seconds	Derived from the managed point-in-time recovery retention.
slow_query_log	ON
slow_query_log_file	/var/lib/mysql/slow.log
log_slow_extra	ON
default_time_zone	+00:00; not customer-configurable. A client may still set its own session timezone at runtime.

Redis-compatible cache

The version picker shows the compatible cache lines offered for the App. Selecting a version also selects its matching implementation. Fresh Apps default to Valkey 9.1; Valkey 8.1 and Redis remain available for compatibility.

You can move to a newer cache release in place. Moving backward isn’t offered because the persistent cache format is forward-only.

Persistence and network binding are locked. Other tuning values use platform defaults and can be overridden when Add setting offers them.

Editable settings

Setting	Allowed values	Default	Meaning
maxmemory-policy	allkeys-lru, allkeys-lfu	allkeys-lru	Cache-key eviction policy when the cache is full.

This setting applies to the cache role. Session storage uses the locked noeviction policy. Every effective cache change currently rolls the stateful service behind the same temporary maintenance and scheduled-job suspension used for MySQL.

Running configuration

The running view separates cache and session roles when both are present.

Setting	State	Effective behavior
maxmemory	sized to plan	Derived from that Valkey or Redis role’s customer memory reservation.
active-defrag-ignore-bytes	sized to plan	Derived from the role reservation (active-defrag trigger floor).
maxmemory-policy	Cache: platform default or customer-set; session: locked	Cache defaults to allkeys-lru; session storage uses noeviction.
appendonly	locked	Platform-selected by role.
maxmemory-samples	platform default	10; overridable through Add setting.
save	locked	""; snapshot persistence is disabled.
tcp-keepalive	platform default	300 seconds; overridable through Add setting.
timeout	platform default	300 seconds; overridable through Add setting.
lazyfree-lazy-eviction	platform default	yes; overridable through Add setting.
lazyfree-lazy-expire	platform default	yes; overridable through Add setting.
lazyfree-lazy-server-del	platform default	yes; overridable through Add setting.
loglevel	platform default	notice; overridable through Add setting.

OpenSearch

OpenSearch is required for Magento and isn’t provisioned for WordPress. Fresh Magento Apps currently default to OpenSearch 3.7.

The customer control is the offered Version picker. Cluster and network controls are locked; heap sizing is sized to plan.

Running configuration

The running file marks the single-node and network-policy controls as locked. Heap and container memory are sized to plan.

Setting	Effective behavior
discovery.type	single-node
DISABLE_SECURITY_PLUGIN	true; access remains limited by the App’s tenant network policy rather than public exposure.
OPENSEARCH_JAVA_OPTS	Reservation-derived equal initial and maximum JVM heap, sized at 50% of container memory.
Container memory	Customer-set reservation rendered request==limit; memory outside the heap supports file cache.

Review Magento and extension compatibility before changing the version. The confirmation dialog is the authority for the apply impact of the selected change.

RabbitMQ

RabbitMQ is an optional Magento message broker and is disabled by default. When enabled, its Version picker shows the compatible releases offered by the current platform catalog.

You can move to a newer RabbitMQ release in place. Moving backward isn’t offered because the broker reuses its durable queue volume.

Varnish (page cache)

Varnish is available for Magento and Shopware. New Shopware Apps enable it by default; Magento Apps can enable it as an optional full-page cache. Its base VCL, storage, listeners, and image version remain locked. The Varnish 7.7 catalog exposes 40 bounded runtime parameters through Add setting; unsafe compiler, filesystem, debug, pool-internal, and telemetry controls remain suppressed.

App endpoint

The App sends cache invalidation to this namespace-local Service endpoint:

tn<first-eight-characters-of-App-ID>-varnish:6081

For example, App ID 12345678-90ab-cdef-1234-567890abcdef uses tn12345678-varnish:6081. Magento stores that host-and-port form. Shopware uses the URL http://tn12345678-varnish:6081.

Invalidation uses the platform’s dedicated purge listener on port 6081. Serving traffic stays on port 80.

The short Service name resolves because the App and Varnish run in the same namespace. The endpoint is platform-owned and isn’t a field in the authoritative App YAML.

Framework configuration after enablement

When Varnish is enabled during provision, synsmarts writes the framework configuration below. Enabling Varnish later creates the reverse-proxy service but doesn’t rewrite framework configuration. Complete the matching App setup before relying on Varnish caching or invalidation.

Magento

Run these commands from the App root in the managed SSH shell, replacing the example host with the host derived from your App ID:

bin/magento setup:config:set --http-cache-hosts=tn12345678-varnish:6081
bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2

The first command writes http_cache_hosts to the existing app/etc/env.php. The second stores 2, Magento’s Varnish cache mode, in the database. Keep app/etc/env.php out of Git and deploy source; synsmarts created that runtime file during provision, and the managed shell updates it in place.

Verify both values without printing the rest of env.php:

php -r '$c = include "app/etc/env.php"; var_export($c["http_cache_hosts"] ?? null); echo PHP_EOL;'
bin/magento config:show system/full_page_cache/caching_application

The first command should show tn12345678-varnish:6081; the second should show 2.

Shopware 6.7

Add SHOPWARE_HTTP_CACHE_ENABLED=1 under Vars and secrets and apply the change. Then add this file to the Shopware project used for deploys:

config/packages/zzz-reverse-proxy.yaml

shopware:
  http_cache:
    reverse_proxy:
      enabled: true
      use_varnish_xkey: true
      hosts: ["http://tn12345678-varnish:6081"]
      max_parallel_invalidations: 3
    stale_while_revalidate: 300
    stale_if_error: 3600

Commit the file to the connected Git repository. For a Workspace deploy, add the same path to the Workspace source before deploying it. The framework file belongs to the Shopware project; don’t put the shopware.http_cache block in .synsmarts/<app-id>.yaml.

On Shopware 6.7, stale_while_revalidate and stale_if_error stay directly under shopware.http_cache, including when CACHE_REWORK is active. CACHE_REWORK doesn’t move them into http_cache.policies; that tree controls route policies. Verify the merged shape on your installed version:

bin/console debug:config shopware http_cache

Run the command against a warmed development-mode console. In production mode, Shopware’s compiled container can reject debug:config because it uses a frozen ParameterBag. Confirm that reverse_proxy.enabled is true, use_varnish_xkey is true, the host matches your App’s Varnish Service, and the two stale-response policies remain under http_cache.

Shopware 6.8 deprecates reverse_proxy.use_varnish_xkey, ban_method, ban_headers, and purge_all; xkey invalidation becomes the default. Keep use_varnish_xkey: true only while your App remains on the 6.7 configuration contract shown above.

Editable settings

Setting	Type and limit	Meaning
recv	Validated VCL snippet, maximum 8000 characters	Additional VCL run in vcl_recv, after the platform cache-key and cookie logic.
backend_response	Validated VCL snippet, maximum 8000 characters	Additional VCL run in vcl_backend_response, after platform tag registration.

Both slots use a safety allowlist and must compile with varnishd -C before a save is accepted. You can set your own custom response headers (X-*) and add conditional logic; the platform owns everything that decides caching. Statements that set cache lifetime (beresp.ttl, beresp.grace), repoint the backend, redefine subroutines, alter the cache key or cookies, trigger invalidation, or read sensitive request data (cookies, Authorization, client IP) are rejected when saved. To make a request bypass the cache, use a conditional return (pass) in the recv slot. Your VCL runs after the platform’s cache-key, cookie-strip, and purge logic and can’t override them.

The current Magento entry shape supports Varnish. Shopware includes Varnish in its default provisioned shape. Optional envelope consumers such as ChunkHound can require a larger shape.

Saving a runtime parameter or a VCL slot renders the change and restarts the stateless cache behind the temporary maintenance page. A parameter save also verifies every requested value with varnishadm param.show before completing. Purge cache remains a separate runtime action that doesn’t change saved configuration.

Defaults and overrides

Each editable field is either platform default or customer-set. Removing a customer-set value adopts the current platform default; it doesn’t freeze the previous default.

Values labeled sized to plan can change when purchased resources change. The portal’s displayed default for the current App is authoritative.

Effective values

The running view is read-only and redacts sensitive values. During an active apply, desired settings can be newer than every running service. Use operation status to determine when rollout has completed.

Validation

synsmarts validates type, range, enum membership, cross-field rules, purchased-shape caps, Nginx and Varnish VCL safety grammars, and service native configuration before committing a change.

Apply impact

• PHP-FPM and Nginx changes use a health-checked replacement.
• Database and cache changes restart the service behind a temporary maintenance response and suspend scheduled jobs until health is confirmed.
• PHP-CLI changes restart scheduled-job execution without moving web traffic.
• OpenSearch version changes use the impact stated in the confirmation dialog.
• Varnish purge is a runtime action, not a configuration apply.
• A no-change save doesn’t restart a service.

See Configure services for the operational procedure.