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. Through Cloudflare’s proxy a request ends at 100 s; see 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-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, session path, and clock. 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.
php_admin_value[auto_prepend_file]	Magento	/usr/local/share/synsmarts/otel/platform-prepend.php, which loads the Composer environment guard before the managed tracing gate.
php_admin_value[auto_prepend_file]	WordPress and Shopware	/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_admin_value[date.timezone]	All	UTC; not customer-configurable. Application code may still set a per-request timezone at runtime.

PHP-CLI scheduled-jobs service

This card controls the PHP processes used by Scheduled Jobs and the managed shell. 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-8192	Magento 4096; Shopware 2048; WordPress 512	Maximum memory for each scheduled or shell 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, and schedules can run in another zone (Choose a time zone for schedules).

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

The default reflects the App’s cron job memory budget. It doesn’t reserve that much memory; concurrent commands share available node capacity. A PHP memory-exhaustion fatal is written to stderr when log_errors is enabled, which it is by default.

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.

The panel also offers an Add setting picker over the Nginx 1.31 directive catalog. Each added directive renders into the block Nginx defines for it: http-only directives such as limit_req_zone, log_format, and map go into the http block, and tuning directives that Nginx accepts in a server block go into the managed server block ahead of the server snippet. Directives that Nginx accepts more than once per block take one value per line, and each line becomes its own directive in the order you enter it; different directives keep the panel’s alphabetical order. The repeatable directives are set_real_ip_from, allow, deny, error_page, limit_req_zone, limit_conn_zone, limit_req, limit_conn, proxy_set_header, proxy_hide_header, proxy_pass_header, proxy_cache_valid, fastcgi_param, fastcgi_hide_header, fastcgi_pass_header, fastcgi_cache_valid, uwsgi_param, scgi_param, grpc_set_header, add_trailer, sub_filter, set, rewrite, auth_request_set, and log_format. Every other directive, including the block-valued map, geo, and split_clients, takes one value; a second value is rejected when saved. A directive can carry at most 64 values, and its values together are limited to 8192 characters. Each value must form one complete directive, so quote an argument that contains # or spaces.

Nginx inherits fastcgi_param, proxy_set_header, and the *_hide_header and *_pass_header families as a set: a location that declares any of its own replaces the inherited ones. The platform’s PHP locations declare their own fastcgi_param entries, so a server-level fastcgi_param doesn’t reach PHP.

Client address

Requests reach Nginx through the platform’s ingress and the synsmarts WAF, so $remote_addr is the WAF’s in-cluster address and the visitor’s address arrives in X-Forwarded-For. To make $remote_addr (and PHP’s REMOTE_ADDR) the visitor’s address, add real_ip_header set to X-Forwarded-For, real_ip_recursive set to on, and one set_real_ip_from line per trusted network: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 cover the platform hops. When every domain on the App is Cloudflare-fronted, add Cloudflare’s published IP ranges as further set_real_ip_from lines so the walk continues past the Cloudflare edge to the visitor.

Caution

Trust only networks that sit in front of your App. With real_ip_recursive on, Nginx walks X-Forwarded-For from the right and stops at the first untrusted address; a range you trust that a visitor can reach directly lets that visitor choose the address your App sees. On a direct-to-origin domain, Cloudflare’s ranges are reachable by anyone, so leave them out there. The WAF and the platform’s rate limits resolve the client address on their own and are unaffected by these directives.

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 reads each requested value back from the running database. A value that doesn’t read back restores the previous settings, and the change reports failed. In both cases traffic and deferred jobs return once database health is confirmed; if it can’t be confirmed, maintenance stays on and our team is alerted.

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 memory the buffer pool leaves; a larger innodb_buffer_pool_size leaves fewer.
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).
activedefrag	platform default or customer-set	Cache roles default to yes; overridable through Add setting. Session and queue-lock roles retain the upstream default.
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.

Magento session locking

Magento Apps store shopper sessions in the session role with session locking off and a 5-second connection timeout, the values Adobe recommends for Redis and Valkey session storage. With locking off, a shopper’s parallel requests (cart, customer data, checkout steps) run side by side instead of waiting in line for one another.

Turn locking back on when two requests from the same shopper overwrite each other’s session changes, for example a lost cart message or checkout step. Set it in the App’s configuration file:

services:
  redis:
    session_locking: true

Field	Allowed values	Default	Applies to
services.redis.session_locking	true, false	false	Magento only

Saving the change replaces the store’s PHP-FPM pods through the usual blue/green rollout; the session role itself doesn’t restart, so shoppers stay signed in. The platform sets these values outside app/etc/env.php, so the session block in that file no longer controls locking or the connection timeout. Other app types reject the field.

OpenSearch

OpenSearch is required for Magento and Shopware when the App is created and isn’t provisioned for WordPress. Fresh Magento and Shopware Apps currently default to OpenSearch 3.7.

Every offered OpenSearch version runs the OpenSearch minimal distribution with three plugins. analysis-phonetic and analysis-icu accept indexes that declare phonetic token filters or ICU analysis, such as those Smile ElasticSuite creates. The security plugin enforces the App’s search credential. Other plugins from the full upstream OpenSearch bundle aren’t installed. An App created before this image shipped gets it when its OpenSearch service is next updated, such as by a memory or version change. Before replacing the node, synsmarts checks the search node’s stored settings, mappings, pipelines, and plugin data for a plugin the minimal image doesn’t include. If it finds one, the change fails with the reason OpenSearch change refused before the search node was replaced, and the existing node keeps running unchanged. While the App is suspended, a change to an offered version fails with the reason OpenSearch change refused: the search node is suspended; repeat it after the App resumes.

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

Running configuration

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

Setting	Effective behavior
discovery.type	single-node
cluster.default_number_of_replicas	0. Indexes carry no replica copies, so every index is green on the single node. Existing indexes are set to 0 replicas when the node becomes ready.
node.processors	Derived from the App’s CPU: the CPU limit when one is set, otherwise the purchased core count. Search thread pools size from this value instead of the host’s cores.
Authentication	The security plugin is on. The App connects as the user app with a password generated for the App; the running view redacts it. The user can create, read, write, and manage indexes and read cluster health and state. It can’t change cluster or security settings.
Transport encryption	Port 9200 and node transport accept TLS only. Each App’s node has its own certificate from the platform’s private certificate authority, which the App’s pods trust.
Network access	Port 9200 accepts connections from the App’s own pods and the platform’s provisioning workers only. The node transport port isn’t reachable.
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.

Index rebuilds

OpenSearch keeps its index on the node’s temporary storage; the database is the source of truth for catalog data. A memory or version change replaces the node, which deletes the catalog index, and synsmarts then rebuilds it from the database. A rebuild usually takes minutes, and a catalog of several hundred thousand products can take up to about an hour. Enabling OpenSearch after it was disabled rebuilds the index the same way. On Magento 2.4.7 or later using Magento’s built-in OpenSearch search, category and search pages start empty and fill as the rebuild progresses. Other Magento setups, such as ElasticSuite or Magento older than 2.4.7, run a full rebuild, and their category and search pages return when it finishes. Shopware keeps serving from the database until the rebuild finishes. For a memory change, the Shape dialog on the Resources page states the deletion and rebuild before you apply.

The change completes only when the rebuild does. If the rebuild fails, the change reports failed, and the new memory size or version stays applied. On Magento 2.4.7 or later using Magento’s built-in OpenSearch search, a failed rebuild also pauses the catalog search indexer, so Magento’s cron doesn’t restart a rebuild that keeps failing; a successful rebuild resumes it. Other Magento setups don’t pause the indexer. Select Rebuild search index on the Search service page to run it again.

A search node that restarts outside a change, such as during node maintenance or when the index outgrows its storage, loses its index the same way. If search results or Magento category pages are empty afterward, select Rebuild search index.

Sizing

The JVM heap is 50% of the memory reservation; the rest is file cache for the index. A full rebuild is the node’s heaviest workload, and a rebuild that runs out of heap fails. Size the reservation from the catalog’s size rather than from everyday search traffic. On a large catalog, expect rebuilds beyond memory and version changes: Magento rebuilds the catalog search index whenever that index is invalidated, such as when a store view is added or removed, and some deploy migrations invalidate it.

Index storage follows the reservation too. It’s four times the memory reservation, with an 8 GiB minimum, which holds the live index and the replacement copy a full rebuild writes. An index that outgrows it restarts the node, which loses the index.

If a rebuild fails on a large catalog, raise the reservation on the Resources page; that change raises the heap and index storage and starts a new rebuild on its own.

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, 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 replaces the cache pod without the maintenance page. The old pod serves until the new one is ready, and the new pod starts with an empty cache. A parameter save also verifies every requested value with varnishadm param.show before completing; a value that doesn’t read back restores the previous settings, and the change reports failed. Turning Varnish on or off runs behind the temporary maintenance page until the cache is ready or removed. Purge cache remains a separate runtime action that doesn’t change saved configuration. Every Magento deploy also purges Varnish after promotion; the deploy reports Complete without waiting for the purge.

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. This also holds when the change fails.
• PHP-CLI changes restart scheduled-job execution without moving web traffic.
• OpenSearch memory and version changes replace the search node and rebuild the catalog index from the database; the change completes when the rebuild does. See Index rebuilds.
• 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.