Configuration

The chart is configured through its values. Each one is described in values.yaml; Parameters says which page covers which group. This page covers the settings most sites change first.

WordPress settings

Parameter	Description	Default
wordpressUsername	WordPress admin username	user
wordpressPassword	WordPress admin password	random
wordpressEmail	WordPress admin email	user@example.com
wordpressBlogName	Blog name	User's Blog!
wordpressScheme	URL scheme (http/https)	http
wordpressExtraConfigContent	PHP statements the generated wp-config.php evaluates, for constants of your own	""
wordpressConfigureCache	Auto-configure W3 Total Cache	false
wordpressCacheInstanceId	W3 Total Cache instance id (cache key prefix)	derived from namespace and release
wordpressPreinstallPlugins	Plugins installed and activated on every start, see Preinstalled plugins	two-factor

WordPress is installed by the image, not by a value: on every start it checks the database, creates the site with the settings above where there is none, and leaves an existing one as it is.

The chart writes wp-config.php every time a pod starts, so a constant that a plugin adds to the file is gone with the next pod. Set constants of your own in wordpressExtraConfigContent, as PHP statements without an opening tag; the generated file evaluates them before it loads WordPress:

wordpressExtraConfigContent: |
  define('WP_POST_REVISIONS', 10);

The content reaches the container as the environment variable WORDPRESS_CONFIG_EXTRA. Released chart versions up to 7.1.408 do not read wordpressExtraConfigContent; there, set that variable yourself:

extraEnvVars:
  - name: WORDPRESS_CONFIG_EXTRA
    value: |
      define('WP_POST_REVISIONS', 10);

An extraEnvVars entry of that name still takes precedence over the value.

Persistence

The site's volume holds wp-content, the site's own nginx.conf and, with the search sidecar, its index. By default the chart requests a 10Gi ReadWriteOnce volume from the cluster's default storage class:

persistence:
  enabled: true
  storageClass: ""        # "" = the cluster's default
  accessModes:
    - ReadWriteOnce
  size: 10Gi
  existingClaim: ""       # use a claim that already exists

Resources

Resources can be set explicitly or via presets:

# Using a preset
resourcesPreset: "small"  # nano, micro, small, medium, large, xlarge, 2xlarge

# Or explicit resources (overrides preset)
resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1Gi

Preset	CPU Request	Memory Request
nano	100m	128Mi
micro	250m	256Mi
small	500m	512Mi
medium	500m	1Gi
large	1.0	2Gi
xlarge	2.0	4Gi
2xlarge	4.0	8Gi

The default is resourcesPreset: "micro".

Autoscaling

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPU: 60
  targetMemory: 70

When using multiple replicas, ensure the PVC access mode supports ReadWriteMany.

Security context

Both security contexts are off by default (enabled: false), so the containers run as the image defines. Switched on, they add what the image can run with:

podSecurityContext:
  enabled: true     # fsGroup 1001

containerSecurityContext:
  enabled: true     # no privilege escalation, seccomp profile RuntimeDefault

The image has to start as root: its init system refuses any other user and writes to the root filesystem while starting, and the init container sets the owner of the files it creates on the volume. containerSecurityContext therefore keeps runAsUser: 0, a writable root filesystem and the container runtime's default capabilities. What enabled: true adds is allowPrivilegeEscalation: false, privileged: false and the RuntimeDefault seccomp profile, for the WordPress container and the init container alike.

With runAsNonRoot: true, a runAsUser other than 0, readOnlyRootFilesystem: true or all capabilities dropped the pod does not start. A cluster that admits no root containers, such as OpenShift with its default security context constraints, cannot run the image.

Released chart versions up to 7.1.408

There the defaults of containerSecurityContext were those of the Bitnami chart (user 1001, runAsNonRoot, a read-only root filesystem, all capabilities dropped), and a pod with enabled: true did not start. On such a version, set runAsUser: 0, runAsGroup: 0, runAsNonRoot: false, readOnlyRootFilesystem: false and capabilities.drop: [] next to enabled: true.